Bugzilla – Bug 893824
VUL-1: CVE-2014-5461: lua: overflow flaw in vararg functions
Last modified: 2021-10-13 16:59:26 UTC
Via oss-security: http://www.openwall.com/lists/oss-security/2014/08/21/1 An overflow was reported to have been fixed in Lua 5.2.2. A reproducer and patch are available from: http://www.lua.org/bugs.html#5.2.2-1 The reproducer affects older versions too (such as 5.1.4). One way an attacker could trigger this issue is if they can control parameters to a loadstring call (an eval in Lua, http://en.wikipedia.org/wiki/Eval#Lua). Could a CVE please be assigned if one has not been already? Some notes: valgrind shows this crashes with invalid writes, but I am not sure if this is really a stack or heap overflow but something else. In luaD_precall(): 330 for (; n < p->numparams; n++) 331 setnilvalue(L->top++); /* complete missing arguments */ This goes through 49 times with the reproducer (?possibly lifting what Lua thinks is the stack into the heap area?). After that finishes: 333 ci = next_ci(L); Results in a call to luaE_extendCI(), where the issue is triggered while attempting to call luaM_new() (I did not get further than this yet). -------------- CVE-2014-5461 was assigned to this issue. References: http://seclists.org/oss-sec/2014/q3/453 https://bugzilla.redhat.com/show_bug.cgi?id=1132304
bugbot adjusting priority
Tested with 5.2.2: reproduced 5.2.3: not reproduced
lua 5.0 and lua 5.1 is not affected => 12.3, 13.1, sle12 affected
Packages submitted.
i did not see opensuse updates?
Probably, I deleted home:pgajdos:maintenance:lua. see mr#248859
released
openSUSE-SU-2014:1145-1: An update that fixes one vulnerability is now available. Category: security (moderate) Bug References: 893824 CVE References: CVE-2014-5461 Sources used: openSUSE 13.1 (src): lua-5.2.2-2.4.1 openSUSE 12.3 (src): lua-5.2.1-2.5.1
"The strncat() function shall append not more than n bytes (a null byte and bytes that follow it are not appended) from the array pointed to by s2 to the end of the string pointed to by s1." http://www-look-4.com/category/technology/ The wording imply that the third "n" argument is an additional boundary limit, not the destination buffer capacity (ie. the destination buffer is not implicitly SIZE_MAX), https://komiya-dental.com/health/healthy-foods/ and both source and destination do not overlap (overlapping depends on the source and destination layout, not on the "n" value) http://www.iu-bloomington.com/computers/invisible-with-vpn/ However, it seems that the optimized strncat version of the GLIBC behaves incorrectly, when using this value. https://waytowhatsnext.com/sports/navona/ "The strncat() function shall append not more than n bytes (a null byte and bytes that follow it are not appended) from the array pointed to by s2 to the end of the string pointed to by s1." https://www.webb-dev.co.uk/sports/sports-and-health/ The wording imply that the third "n" argument is an additional boundary limit, not the destination buffer capacity (ie. the destination buffer is not implicitly SIZE_MAX), and both source and destination http://www.wearelondonmade.com/category/tech/ do not overlap (overlapping depends on the source and destination layout, not on the "n" value) However, it seems that the optimized strncat version of the GLIBC behaves incorrectly, when using this value. http://www.jopspeech.com/category/technology/ "The strncat() function shall append not more than n bytes (a null byte and bytes that follow it are not appended) from the array pointed to by s2 to the end of the string pointed to by s1." http://joerg.li/category/technology/ The wording imply that the third "n" argument is an additional boundary limit, not the destination buffer capacity (ie. the destination buffer is not implicitly SIZE_MAX), and both source and destination do not http://connstr.net/category/technology/ overlap (overlapping depends on the source and destination layout, not on the "n" value) However, it seems that the optimized strncat version of the GLIBC behaves incorrectly, when using this value. http://embermanchester.uk/category/technology/ "The strncat() function shall append not more than n bytes (a null byte and bytes that follow it are not appended) from the array pointed to by s2 to the end of the string pointed to by s1." http://www.slipstone.co.uk/category/technology/ The wording imply that the third "n" argument is an additional boundary limit, not the destination buffer capacity (ie. the destination buffer is not implicitly SIZE_MAX), and both source and destination do not overlap http://www.logoarts.co.uk/category/technology/ (overlapping depends on the source and destination layout, not on the "n" value) However, it seems that the optimized strncat version of the GLIBC behaves incorrectly, when using this value. http://www.acpirateradio.co.uk/category/technology/ "The strncat() function shall append not more than n bytes (a null byte and bytes that follow it are not appended) from the array pointed to by s2 to the end of the string pointed to by s1." http://www.compilatori.com/category/technology/ The wording imply that the third "n" argument is an additional boundary limit, not the destination buffer capacity (ie. the destination buffer is not implicitly SIZE_MAX), and both source and destination do not overlap (overlapping depends on the source and destination layout, not on the "n" value) However, it seems that the optimized strncat version of the GLIBC behaves incorrectly, when using this value.