Bug 31809 - Redis new security issue CVE-2023-28856
Summary: Redis new security issue CVE-2023-28856
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 8
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
Whiteboard: MGA8-64-OK
Keywords: advisory, validated_update
Depends on:
Blocks: 31174
  Show dependency treegraph
Reported: 2023-04-17 21:44 CEST by Stig-Ørjan Smelror
Modified: 2023-04-24 03:46 CEST (History)
4 users (show)

See Also:
Source RPM:
CVE: CVE-2023-28856
Status comment:


Description Stig-Ørjan Smelror 2023-04-17 21:44:33 CEST
Upstream has released version 7.0.11 (Cauldron) and 6.0.19 (MGA8) to address CVE-2023-28856.
Stig-Ørjan Smelror 2023-04-17 21:45:05 CEST

Status comment: (none) => Fixed upstream in versions 6.0.19 and 7.0.11
CVE: (none) => CVE-2023-28856

Comment 1 Stig-Ørjan Smelror 2023-04-17 21:48:01 CEST
Update pushed for Cauldron.

Version: Cauldron => 8

Comment 2 Stig-Ørjan Smelror 2023-04-17 21:57:04 CEST

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.




Uploaded to core/updates_testing


from redis-6.0.19-1.mga8.src.rpm

Assignee: smelror => qa-bugs

David Walser 2023-04-18 04:09:34 CEST

Status comment: Fixed upstream in versions 6.0.19 and 7.0.11 => (none)

Comment 3 Len Lawrence 2023-04-18 16:29:45 CEST
Investigating this for Mageia8 wrt the HINCRBYFLOAT command.

CC: (none) => tarazed25

Comment 4 Len Lawrence 2023-04-18 18:01:00 CEST
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> 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> :set hints> help <tab>> 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
.....> 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:> GET server:name
"rapunzel"> ttl resource:lock
(integer) -1> lrange friends 1 2
1) "Sukie"
2) "Zack"> exit 

That demonstrates persistence between separate command-line sessions.
Logged out and in.
Checked that redis server was still running then
$ redis-cli> get server:name
"rapunzel"> lrange friends 0 -1
1) "Polly"
2) "Sukie"
3) "Zack"> 

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> ttl "Demo 2"
(integer) -2> lrange friends 0 2
1) "Polly"
2) "Sukie"
3) "Zack"> 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

Comment 5 Len Lawrence 2023-04-18 18:05:19 CEST
Umm.  There is an inconsistency in comment 4: not the resource:lock "Demo 2"> get resource:lock
"Demo 2"

My bad.
Comment 6 Thomas Andrews 2023-04-18 23:39:26 CEST
Validating. Advisory in Comment 2.

CC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => validated_update

Comment 7 David Walser 2023-04-18 23:53:26 CEST
We need to double check the advisory, since Stig-Orjan just closed two other redis bugs with different CVEs.
David Walser 2023-04-20 17:50:21 CEST

Blocks: (none) => 31174

Comment 8 David Walser 2023-04-20 17:52:18 CEST
Does this update fix CVE-2022-3647?
Comment 9 Dave Hodgins 2023-04-24 00:09:59 CEST
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

Comment 10 David Walser 2023-04-24 01:30:42 CEST
But does this update fix it?
Comment 11 Dave Hodgins 2023-04-24 02:17:35 CEST
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) {

        "Redis %s crashed by signal: %d, si_code: %d", REDIS_VERSION, sig, info->si_code);
    if (sig == SIGSEGV || sig == SIGBUS) {
        "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.
Comment 12 Mageia Robot 2023-04-24 02:22:02 CEST
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

Comment 13 Dave Hodgins 2023-04-24 02:43:44 CEST
Found it at https://github.com/redis/redis/commit/0bf90d944313919eb8e63d3588bf63a367f020a3

It changes
    return (void*) uc->uc_mcontext.gregs[16]; /* Linux 64 */
    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
Comment 14 David Walser 2023-04-24 03:46:47 CEST

Note You need to log in before you can comment on or make changes to this bug.