Upstream has released version 7.0.11 (Cauldron) and 6.0.19 (MGA8) to address CVE-2023-28856. https://github.com/redis/redis/releases/tag/7.0.11 https://github.com/redis/redis/releases/tag/6.0.19
Status comment: (none) => Fixed upstream in versions 6.0.19 and 7.0.11CVE: (none) => CVE-2023-28856
Update pushed for Cauldron.
Version: Cauldron => 8
Advisory ======== Upstream has released version 6.0.19 to fix CVE-2023-28856. CVE-2023-28856: Authenticated users can use the HINCRBYFLOAT command to create an invalid hash field that will crash Redis on access. References ========== https://github.com/redis/redis/releases/tag/6.0.19 Files ===== Uploaded to core/updates_testing redis-6.0.19-1.mga8 from redis-6.0.19-1.mga8.src.rpm
Assignee: smelror => qa-bugs
Status comment: Fixed upstream in versions 6.0.19 and 7.0.11 => (none)
Investigating this for Mageia8 wrt the HINCRBYFLOAT command.
CC: (none) => tarazed25
Mageia8, x86_64 * Before updating * Started redis server. Ran the tutorial script: $ redis-cli < tutorial which established a server called rapunzel and a resource "Redis Demo 1" which expired later and another called "Demo 2". $ redis-cli 127.0.0.1:6379> help HINCRBYFLOAT HINCRBYFLOAT key field increment summary: Increment the float value of a hash field by the given amount since: 2.6.0 group: hash 127.0.0.1:6379> :set hints 127.0.0.1:6379> help <tab> 127.0.0.1:6379> help @generic DEL key [key ...] summary: Delete a key since: 1.0.0 ..... EXPIRE key seconds summary: Set a key's time to live in seconds since: 1.0.0 ..... 127.0.0.1:6379> help ttl TTL key summary: Get the time to live for a key since: 1.0.0 group: generic There is a lot of commands, many of which have no help at present. Continuing with the session: 127.0.0.1:6379> GET server:name "rapunzel" 127.0.0.1:6379> ttl resource:lock (integer) -1 127.0.0.1:6379> lrange friends 1 2 1) "Sukie" 2) "Zack" 127.0.0.1:6379> exit That demonstrates persistence between separate command-line sessions. Logged out and in. Checked that redis server was still running then $ redis-cli 127.0.0.1:6379> get server:name "rapunzel" 127.0.0.1:6379> lrange friends 0 -1 1) "Polly" 2) "Sukie" 3) "Zack" 127.0.0.1:6379> Database still in memory. Could not find any information to test the vulnerability. Updated redis. Restarted the redis server and repeated the earlier tests without running the tutorial script. rapunzel was still there but not the resource:lock "Demo 2" which had no expiry time. $ redis-cli 127.0.0.1:6379> ttl "Demo 2" (integer) -2 127.0.0.1:6379> lrange friends 0 2 1) "Polly" 2) "Sukie" 3) "Zack" 127.0.0.1:6379> get resource:lock "Demo 2" Note that the hints setting was still in play as well - supplying help information on arguments to commands. Not taking this any further. No regressions so far and persistence is demonstrated.
Whiteboard: (none) => MGA8-64-OK
Umm. There is an inconsistency in comment 4: not the resource:lock "Demo 2" 127.0.0.1:6379> get resource:lock "Demo 2" My bad.
Validating. Advisory in Comment 2.
CC: (none) => andrewsfarm, sysadmin-bugsKeywords: (none) => validated_update
We need to double check the advisory, since Stig-Orjan just closed two other redis bugs with different CVEs.
Blocks: (none) => 31174
Does this update fix CVE-2022-3647?
I agree that CVE-2022-3647 is an invalid cve. A crash in the crash handler can not be considered a denial of service, just a bug that may cause crash info not to be available. Advisory as per comment 2 committed to svn.
Keywords: (none) => advisoryCC: (none) => davidwhodgins
But does this update fix it?
That's not clear from the source code or the redis.iso website. cve.org lists a patch id, but the download-able source code has any patches already applied. I can't find such a patch anywhere. The code in question has ... void sigsegvHandler(int sig, siginfo_t *info, void *secret) { UNUSED(secret); UNUSED(info); bugReportStart(); serverLog(LL_WARNING, "Redis %s crashed by signal: %d, si_code: %d", REDIS_VERSION, sig, info->si_code); if (sig == SIGSEGV || sig == SIGBUS) { serverLog(LL_WARNING, "Accessing address: %p", (void*)info->si_addr); } if (info->si_code == SI_USER && info->si_pid != -1) { serverLog(LL_WARNING, "Killed by PID: %ld, UID: %d", (long) info->si_pid, info->si_uid); } I have no idea if that still has the problem or not, or how we can tell without finding some other way to trigger a crash so that the crash handler gets invoked. I did not include CVE-2022-3647 in the svn advisory.
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2023-0156.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
Found it at https://github.com/redis/redis/commit/0bf90d944313919eb8e63d3588bf63a367f020a3 It changes return (void*) uc->uc_mcontext.gregs[16]; /* Linux 64 */ to GET_SET_RETURN(uc->uc_mcontext.gregs[16], eip); which is what's in the download-able tar file for 6.0.19 so it has been fixed.
Thanks!