From b23291be831f0f740fe303293ed30301aefcd419 Mon Sep 17 00:00:00 2001 From: Ankur Tyagi Date: Thu, 24 Sep 2026 16:32:53 +1200 Subject: [PATCH] redis: patch CVE-2026-81934 Details: https://nvd.nist.gov/vuln/detail/cve-2026-81934 Signed-off-by: Ankur Tyagi Signed-off-by: Anuj Mittal --- .../redis/redis-8.0.6/CVE-2026-81934.patch | 53 +++++++++++++++++++ meta-oe/recipes-extended/redis/redis_8.0.6.bb | 1 + 2 files changed, 54 insertions(+) create mode 100644 meta-oe/recipes-extended/redis/redis-8.0.6/CVE-2026-81934.patch diff --git a/meta-oe/recipes-extended/redis/redis-8.0.6/CVE-2026-81934.patch b/meta-oe/recipes-extended/redis/redis-8.0.6/CVE-2026-81934.patch new file mode 100644 index 0000000000..80a9118d92 --- /dev/null +++ b/meta-oe/recipes-extended/redis/redis-8.0.6/CVE-2026-81934.patch @@ -0,0 +1,53 @@ +From 83b6dda66e69bdaf7927140d70666f838b33cbf0 Mon Sep 17 00:00:00 2001 +From: Sergei Georgiev +Date: Tue, 9 Jun 2026 14:22:50 +0300 +Subject: [PATCH] Fix use-after-free in tlsProcessPendingData() pending-list + iteration (#1391) +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +`tlsProcessPendingData()` iterates `pending_list` using a `listIter`, which pre-caches the `next` node pointer on every `listNext()` call. This cached pointer can dangle and be dereferenced after the node it points to has been freed, causing a use-after-free and a server crash (SIGSEGV). + +The issue occurs because `tlsHandleEvent()` runs the connection's read handler, which can execute a command (e.g. `CLIENT KILL`) that closes a *different* pending TLS connection. That close path goes through `freeClient()` → `connClose()` → `connTLSClose()`, which calls `listDelNode()` and frees the victim connection's `pending_list` node. If the iterator's cached `next` pointer referenced that node, the following `listNext()` reads freed memory. The `listNext()` contract only permits removing the *current* node, not arbitrary other nodes. + +Replace the `listIter`-based iteration with a detach-from-head, bounded drain so that no list node pointer is ever held across a handler call: + +- Re-read `listFirst()` on each iteration instead of relying on a pre-cached `next` pointer +- Detach the head via `tlsPendingRemove()` *before* calling `tlsHandleEvent()`, so the loop always makes forward progress +- Semantics are preserved: in the common case each connection is handled exactly once per cycle, in order + +(cherry picked from commit 98ff29b2828bf3245167b416ee23e6797f551a37) +(cherry picked from commit 6d088c335d5c3ec49a6c28486140b498e70b7834) + +CVE: CVE-2026-81934 +Upstream-Status: Backport [https://github.com/redis/redis/commit/6d088c335d5c3ec49a6c28486140b498e70b7834] +Signed-off-by: Ankur Tyagi +--- + src/tls.c | 9 ++++----- + 1 file changed, 4 insertions(+), 5 deletions(-) + +diff --git a/src/tls.c b/src/tls.c +index a0733a4b6..0fa468cfc 100644 +--- a/src/tls.c ++++ b/src/tls.c +@@ -1098,15 +1098,14 @@ static int tlsHasPendingData(struct aeEventLoop *el) { + } + + static int tlsProcessPendingData(struct aeEventLoop *el) { +- listIter li; +- listNode *ln; +- + list *pending_list = el->privdata[1]; + if (!pending_list) return 0; + int processed = listLength(pending_list); +- listRewind(pending_list,&li); +- while((ln = listNext(&li))) { ++ for (int i = 0; i < processed; i++) { ++ listNode *ln = listFirst(pending_list); ++ if (!ln) break; + tls_connection *conn = listNodeValue(ln); ++ tlsPendingRemove(conn); + tlsHandleEvent(conn, AE_READABLE); + } + return processed; diff --git a/meta-oe/recipes-extended/redis/redis_8.0.6.bb b/meta-oe/recipes-extended/redis/redis_8.0.6.bb index fe31033328..67126c9fcf 100644 --- a/meta-oe/recipes-extended/redis/redis_8.0.6.bb +++ b/meta-oe/recipes-extended/redis/redis_8.0.6.bb @@ -15,6 +15,7 @@ SRC_URI = "http://download.redis.io/releases/${BP}.tar.gz \ file://0003-hack-to-force-use-of-libc-malloc.patch \ file://0004-src-Do-not-reset-FINAL_LIBS.patch \ file://0005-Define-_GNU_SOURCE-to-get-PTHREAD_MUTEX_INITIALIZER.patch \ + file://CVE-2026-81934.patch \ " SRC_URI[sha256sum] = "6d0a9913887a4972536f9da226f1575859c34d86354129163260a5f9c6bd4229"