From ${URL} : It was found that getnum() function in lua_struct.c is vulnerable to integer overflow that can be used to trigger stack-based buffer overflow. getnum() can be tricked into an integer wraparound with a large size number as input, thus returning a negative value. Affected versions of redis are 2.8 and 3.0. Vulnerable code: static int getnum (const char **fmt, int df) { if (!isdigit(**fmt)) /* no number? */ return df; /* return default value */ else { int a = 0; do { a = a*10 + *((*fmt)++) - '0'; } while (isdigit(**fmt)); return a; } } static size_t optsize (lua_State *L, char opt, const char **fmt) { switch (opt) { [...] case 'c': return getnum(fmt, 1); case 'i': case 'I': { int sz = getnum(fmt, sizeof(int)); if (sz > MAXINTSIZE) luaL_error(L, "integral size %d is larger than limit of %d", sz, MAXINTSIZE); return sz; } default: return 0; /* other cases do not need alignment */ } } Upstream bug report (including reproducer): https://github.com/antirez/redis/issues/2855 CVE assignment: http://seclists.org/oss-sec/2015/q4/231 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
@ Maintainers: As of today, the latest 2.8.x version in tree (2.8.23) is still vulnerable. Please bump to 2.8.24 or drop the 2.8.x. For 3.0.x branch, this was fixed with v3.0.6 (https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-db/redis?id=7ffd92f12385548bb62e749cf7d79a7e7f68f32f). Please call for stabilization (probably =dev-db/redis-3.0.7) after deciding how to process with v2.8.x branch.
I'd like to drop 2.8.x tbh Robin, would you agree ?
@arches please stabilize: =dev-db/redis-3.0.7
*** Bug 586968 has been marked as a duplicate of this bug. ***
amd64 stable
x86 stable
arm stable
Stable for HPPA PPC64.
No ACE/RCE, downgraded to B3. GLSA Vote: No @ Maintainer(s): Please cleanup and drop <dev-db/redis-3.0.7!
Cleanup done
Because we have to create a GLSA for another vulnerability in redis we will add this vulnerability to the same request.
This issue was resolved and addressed in GLSA 201702-16 at https://security.gentoo.org/glsa/201702-16 by GLSA coordinator Thomas Deutschmann (whissi).
