From $URL :
Michael Scherer in the following Red Hat bugzilla:
pointed out, Redis, a persistent key-value database of version 2.4
to be prone to temporary file use in src/redis.c:
server.vm_swap_file = zstrdup("/tmp/redis-%p.vm");
Note: This problem was fix by the patch  below.
When searching for a patch, that corrected the issue 
above, found out it was patch
 https://github.com/antirez/redis/commit/697af434fbeb2e3ba2ba9687cd283ed1a2734fa5 ,
but it also introduced another insecure temporary flaw in
776 + server.ds_path = zstrdup("/tmp/redis.ds");
Note: Issue #2 is also fixed in recent upstream 2.6.7 / 2.6.8
versions. If you want me to find exact patch, which
corrected the second problem, let me know and i will
provide the commit id.
1: Since we only have newer than 2.6.7 in tree, I'm therefore assuming that 2.6 is safe (from a gentoo perspective)?
2: Just checked the 2.4 branch, and this code at least still seems to be in there. Here's the following commit to the offending line in unstable/2.6 branch: https://github.com/antirez/redis/commit/4ab988238f7418d018bf4412c6c956845ffbeab9
The two branches are diverging and neither patches will apply cleanly to a 2.4. Has this been reported upstream?
Johan, can you look for upstream reports for 2.4.x/report it upstream?
fwiw, I emailed upstream at January 25th. No response yet.
Johan, any news here? Is this still relevant?
Unfortunately no. I don't think upstream has officially "accepted" it. Haven't really found that any other distros seems to carry a patch for it. I could partly be blamed for not searching enough though.
As of today, v2.4 branch is still affected: https://github.com/antirez/redis/blob/2.4/src/redis.c#L847. In other words we can expect that CVE-2013-0178 will be never fixed.
CVE-2013-0180 which was assigned for the same problem in v2.6 branch and got fixed according to "git log -S "/tmp" src/redis.c" (command must be run in 2.6 branch) when upstream removed diskstore via https://github.com/antirez/redis/commit/c9d0c3623a7714bd41a35237f4ba927206a7adb6.
$ git tag --contains c9d0c3623a7714bd41a35237f4ba927206a7adb6 | sort
...so I don't understand why a CVE was ever assigned for v2.6.0 because no v2.6 release ever tagged created something in /tmp.
Anyways, v2.6.7 was the first version which appeared in Gentoo repository not containing the flaw, see https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-db/redis/redis-2.6.7.ebuild?hideattic=0&view=log
As of today the first stable redis version in Gentoo repository is =dev-db/redis-2.8.17-r1 and no vulnerable versions left. So nothing left to do for us.
@ Security: Please vote!
GLSA Vote: No