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

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-bugs
Keywords: (none) => validated_update

We need to double check the advisory, since Stig-Orjan just closed two other redis bugs with different CVEs.

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) => advisory
CC: (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 => RESOLVED
Resolution: (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!