https://raw.githubusercontent.com/antirez/redis/3.2/00-RELEASENOTES A ziplist bug that could cause data corruption, could crash the server and MAY ALSO HAVE SECURITY IMPLICATIONS was fixed. The bug looks complex to exploit, but attacks always get worse, never better (cit). The bug is very very hard to catch in practice, it required manual analysis of the ziplist code in order to be found. However it is also possible that rarely it happened in the wild. Upgrading is required if you use LINSERT and other in-the-middle list manipulation commands. Also, seems like we should block jemalloc 4.4.0 (from 3.2.8 changelog): Apparently Jemalloc 4.4.0 may contain a deadlock under particular conditions. See https://github.com/antirez/redis/issues/3799. We reverted back to the previously used Jemalloc versions and plan to upgrade Jemalloc again after having more info about the cause of the bug.
Maintainers this vulnerability is in Redis 3.2.7 which is not in the tree. Please evaluate if it effects previous versions in tree.
@ Maintainer(s): Please advise if you are ready for stabilization or call for stabilization yourself. If nothing in a week we will call =dev-db/redis-3.2.8-r2 for stabilization on June 11th.
@ Arches, please test and mark stable: =dev-db/redis-3.2.8-r2
x86 stable
amd64 stable
ppc stable
ppc64 stable
arm stable
Arches, please finish stabilizing hppa Gentoo Security Padawan ChrisADR
newer revision arm64 stable from bug 631002 (despite test failure)
hppa stable
GLSA Vote: No Cleanup will happen in 631002
