redis: fix CVE-2023-41056

Redis is an in-memory database that persists on disk.
Redis incorrectly handles resizing of memory buffers
which can result in integer overflow that leads to heap
overflow and potential remote code execution. This
issue has been patched in version 7.0.15 and 7.2.4.

Reference:
https://nvd.nist.gov/vuln/detail/CVE-2023-41056

Upstream-patch:
e351099e11

Signed-off-by: Divya Chellam <divya.chellam@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
This commit is contained in:
Divya Chellam 2025-01-31 12:50:56 +00:00 committed by Armin Kuster
parent 2a486ee7cd
commit 6bd4846b0b
2 changed files with 64 additions and 0 deletions

View File

@ -0,0 +1,63 @@
From e351099e1119fb89496be578f5232c61ce300224 Mon Sep 17 00:00:00 2001
From: Oran Agra <oran@redislabs.com>
Date: Sun, 7 Jan 2024 12:32:44 +0200
Subject: [PATCH] Fix possible corruption in sdsResize (CVE-2023-41056)
#11766 introduced a bug in sdsResize where it could forget to update
the sds type in the sds header and then cause an overflow in sdsalloc.
it looks like the only implication of that is a possible assertion in HLL,
but it's hard to rule out possible heap corruption issues with clientsCronResizeQueryBuffer
CVE: CVE-2023-41056
Upstream-Status: Backport [https://github.com/redis/redis/commit/e351099e1119fb89496be578f5232c61ce300224]
Signed-off-by: Divya Chellam <divya.chellam@windriver.com>
---
src/sds.c | 30 ++++++++++++++++--------------
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/src/sds.c b/src/sds.c
index 8e5863a..71490d5 100644
--- a/src/sds.c
+++ b/src/sds.c
@@ -348,20 +348,22 @@ sds sdsResize(sds s, size_t size, int would_regrow) {
* type. */
int use_realloc = (oldtype==type || (type < oldtype && type > SDS_TYPE_8));
size_t newlen = use_realloc ? oldhdrlen+size+1 : hdrlen+size+1;
- int alloc_already_optimal = 0;
- #if defined(USE_JEMALLOC)
- /* je_nallocx returns the expected allocation size for the newlen.
- * We aim to avoid calling realloc() when using Jemalloc if there is no
- * change in the allocation size, as it incurs a cost even if the
- * allocation size stays the same. */
- alloc_already_optimal = (je_nallocx(newlen, 0) == zmalloc_size(sh));
- #endif
-
- if (use_realloc && !alloc_already_optimal) {
- newsh = s_realloc(sh, newlen);
- if (newsh == NULL) return NULL;
- s = (char*)newsh+oldhdrlen;
- } else if (!alloc_already_optimal) {
+
+ if (use_realloc) {
+ int alloc_already_optimal = 0;
+ #if defined(USE_JEMALLOC)
+ /* je_nallocx returns the expected allocation size for the newlen.
+ * We aim to avoid calling realloc() when using Jemalloc if there is no
+ * change in the allocation size, as it incurs a cost even if the
+ * allocation size stays the same. */
+ alloc_already_optimal = (je_nallocx(newlen, 0) == zmalloc_size(sh));
+ #endif
+ if (!alloc_already_optimal) {
+ newsh = s_realloc(sh, newlen);
+ if (newsh == NULL) return NULL;
+ s = (char*)newsh+oldhdrlen;
+ }
+ } else {
newsh = s_malloc(newlen);
if (newsh == NULL) return NULL;
memcpy((char*)newsh+hdrlen, s, len);
--
2.40.0

View File

@ -16,6 +16,7 @@ SRC_URI = "http://download.redis.io/releases/${BP}.tar.gz \
file://0001-src-Do-not-reset-FINAL_LIBS.patch \
file://GNU_SOURCE-7.patch \
file://0006-Define-correct-gregs-for-RISCV32.patch \
file://CVE-2023-41056.patch \
"
SRC_URI[sha256sum] = "97065774d5fb8388eb0d8913458decfcb167d356e40d31dd01cd30c1cc391673"