Debian Patches
Status for redis/5:8.0.2-3+deb13u3
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0021-Check-slotinfo-range-when-loading-RDB.patch | Check slotinfo range when loading RDB (#1541) Redis has a memory corruption bug in the RDB loader’s SLOT_INFO handling. A malicious RDB can provide invalid slot metadata that makes Redis use a slot id outside the normal cluster slot range while preparing per-slot dictionaries during load. With the right heap layout, that out-of-bounds slot lookup can be made to land on attacker-controlled data that was also loaded from the RDB. Redis then treats that data as a real dictionary structure The attacker can uses this to build a fake dictionary and fake callback table in memory, then reaches code execution as the Redis process. The cluster-bus INTERNALSECRET issue is used to get an internal Redis connection and make the target replicate from an attacker-controlled fake master. The fake master then serves the malicious SLOT_INFO RDB. The actual RCE primitive is the RDB-loader bug. Source review shows the same SLOT_INFO loader pattern in Redis 7.4.x through 8.8-m03; I verified full RCE on 8.6.2. The issue is that Redis trusts SLOT_INFO metadata from the RDB too much. During RDB load, Redis reads slot_id, slot_size, and expires_slot_size from the file, then passes the slot id directly into kvstore dictionary expansion. Just check the slot_id is in range. (cherry picked from commit e92a526973b660071f51078b81ee17aeab359f84) (cherry picked from commit b1030a2f66311d5a03c58ebdeb5ade77daf74fe5) |
Mincho Paskalev <minchopaskal@gmail.com> | no | 2026-07-21 | ||
| 0022-Fix-use-after-free-in-handleClientsBlockedOnKey.patch | Fix use-after-free in handleClientsBlockedOnKey (#15594) Fixes https://github.com/redis/redis/issues/15562. handleClientsBlockedOnKey() used a list iterator while reprocessing clients blocked on the same key. Reprocessing one client may trigger client eviction, which can remove another blocked client and free the node cached by the iterator, resulting in a use-after-free. Replace the iterator with a bounded head-to-tail traversal. Before reprocessing a client, move its node to the tail so the next waiter remains at the head while preserving FIFO order. Since reprocessing may remove all blocked clients and free the list, look up the list again before each iteration. (cherry picked from commit a8edcfc98c50bb01c850e5dab3998ce57807144d) (cherry picked from commit 009324be81f7105313ce6586ed4807f03c62c7fe) |
Yuan Wang <yuan.wang@redis.com> | no | 2026-08-06 | ||
| 0023-Fix-HGETEX-out-of-bounds-read-when-FIELDS-lacks-numfields.patch | Fix HGETEX out-of-bounds read when FIELDS option missing numfields argument When the HGETEX command is used with the FIELDS option but without the required numfields argument, the server would attempt to access an out-of-bounds argv index. This PR adds a check to ensure numfields is present before accessing it, returning an error if it is missing. Also includes a test case to cover this scenario. (cherry picked from commit 9342dda5717738e050116d4093f1202d56cb2286) |
sggeorgiev <s_ggeorgiev@yahoo.com> | no | 2025-08-24 | ||
| 0024-Fix-MurmurHash64A-overflow-in-HyperLogLog.patch | Fix MurmurHash64A overflow in HyperLogLog with 2GB+ entries The MurmurHash64A function in hyperloglog.c used an int parameter for length, causing integer overflow when processing PFADD entries larger than 2GB. This could lead to server crashes. Changed the len parameter from int to size_t to properly handle large inputs up to SIZE_MAX in HyperLogLog operations. Refer to the implementation in facebook/mcrouter@2dbee3d/mcrouter/lib/fbi/hash.c#L54 (cherry picked from commit 53666e9884f0bd71ee43a005f69ac625377b752a) |
"debing.sun" <debing.sun@redis.com> | no | 2025-08-13 | ||
| debian-packaging/0001-Set-Debian-configuration-defaults.patch | Set Debian configuration defaults | Chris Lamb <lamby@debian.org> | not-needed | 2017-10-10 | ||
| 0001-Fix-FTBFS-on-kFreeBSD.patch | Fix FTBFS on kFreeBSD | Chris Lamb <lamby@debian.org> | no | 2015-10-30 | ||
| 0002-Add-CPPFLAGS-to-upstream-makefiles.patch | Add CPPFLAGS and CXXFLAGS to upstream makefiles . |
Chris Lamb <lamby@debian.org> | no | 2015-10-30 | ||
| 0003-Use-get_current_dir_name-over-PATHMAX.patch | Use get_current_dir_name over PATHMAX, etc. | Chris Lamb <lamby@debian.org> | no | 2018-01-24 | ||
| 0004-Add-support-for-USE_SYSTEM_JEMALLOC-flag.patch | Add support for USE_SYSTEM_JEMALLOC flag. | Chris Lamb <lamby@debian.org> | yes | 2025-05-09 | ||
| 0005-CVE-2025-32023.patch | Fix out of bounds write in hyperloglog commands (CVE-2025-32023) | "debing.sun" <debing.sun@redis.com> | no | 2025-05-07 | ||
| 0006-CVE-2025-48367.patch | Retry accept() even if accepted connection reports an error (CVE-2025-48367) In case of accept4() returns an error, we should check errno value and decide if we should retry accept4() without waiting next event loop iteration. |
Ozan Tezcan <ozantezcan@gmail.com> | no | 2025-05-14 | ||
| 0007-Add-Redis-ver.-REDIS_VERSION-to-LOLWUT-8-output-as-a.patch | Add "Redis ver. $REDIS_VERSION" to LOLWUT 8 output as a some testsuites were relying on it. eg. python-redis (https://github.com/redis/redis-py/blob/master/tests/test_commands.py#L1092) |
Chris Lamb <lamby@debian.org> | yes | 2025-07-14 | ||
| 0008-CVE-2025-49844.patch | Lua script may lead to remote code execution (CVE-2025-49844) | Mincho Paskalev <minchopaskal@gmail.com> | no | 2025-06-23 | ||
| 0009-CVE-2025-46819.patch | LUA out-of-bound read (CVE-2025-46819) | Ozan Tezcan <ozantezcan@gmail.com> | no | 2025-06-23 | ||
| 0010-CVE-2025-46818.patch | Lua script can be executed in the context of another user (CVE-2025-46818) | Ozan Tezcan <ozantezcan@gmail.com> | no | 2025-06-23 | ||
| 0011-CVE-2025-46817.patch | Lua script may lead to integer overflow and potential RCE (CVE-2025-46817) | Ozan Tezcan <ozantezcan@gmail.com> | no | 2025-06-23 | ||
| 0012-CVE-2025-67733.patch | Strip CRLF from error and simple string replies (#826) Because in some cases, the client put \r\n in the command parameters. When Redis returns these parameters to the client via an error reply, the presence of \r\n in the middle can cause the client to only parse the portion before the \r\n when handling the error reply. This disrupts the protocol parsing and ultimately causes the connection to become stuck. [Backport from https://github.com/redis/redis/commit/6910256443c74057e0d83e08c61ea0021774fa6f] [Adapted for redis-8.0.2: - `addReplyErrorSdsSafe` already exists in redis-8.0.2 src/networking.c and src/server.h, so the networking.c hunk only adds the new `addReplyErrorSdsExSafe` and `addReplyStatusSafe` helpers and the addReplyStatusFormat CRLF-stripping, and the server.h hunk only adds declarations for the two new helpers (the existing `addReplyErrorSdsSafe` declaration is left in place). - Hunk offsets/context in src/functions.c, src/script_lua.c, src/module.c, tests/modules/reply.c, tests/unit/functions.tcl, tests/unit/moduleapi/reply.tcl and tests/unit/scripting.tcl adjusted for redis-8.0.2 line numbering. Fix logic byte-identical to upstream.] |
"debing.sun" <debing.sun@redis.com> | no | 2025-12-28 | ||
| 0013-CVE-2026-21863.patch | Fix for [CVE-2026-21863] Remote DoS with malformed Valkey Cluster bus message Backport from Valkey upstream commit: https://github.com/valkey-io/valkey/commit/416939303d2550aefff73ac180f41b84c12ba6c0 |
Roshan Khatri <rvkhatri@amazon.com> | no | 2026-02-23 | ||
| 0014-CVE-2026-25243.patch | Invalid Memory Access in Redis RESTORE Command (CVE-2026-25243) (cherry picked from commit defbf45b9adbbfb21a394786b7092d064a8c9b49) |
Sergei Georgiev <s_ggeorgiev@yahoo.com> | no | 2025-11-27 | ||
| 0015-CVE-2026-23631.patch | Fix use-after-free when fullsync happens while replica is running a timed out script (CVE-2026-23631) Fullsync triggers emptyData and scriptingReset which free the scripting/function engine. If a timed out script is still running on the replica, this causes a use-after-free. Delay fullsync processing in readSyncBulkPayload until the script finishes. (cherry picked from commit 5b2a5044d4413113c5213c7a2d5f455186d7d75c) |
Ozan Tezcan <ozantezcan@gmail.com> | no | 2026-04-14 | ||
| 0016-CVE-2026-23479.patch | Fix use-after-free when evicting blocked client during unblock (CVE-2026-23479) When re-executing a pending command after unblocking, check the return value of `processCommandAndResetClient` and exit if needed. (cherry picked from commit 252f4bd1370d25ee5627475a81ac8ba3c567be40) |
"debing.sun" <debing.sun@redis.com> | no | 2025-12-29 | ||
| 0017-CVE-2026-66373.patch | Reject corrupt stream RDB with shared NACK across consumers (#15081) **Summary** Detects and rejects corrupt stream RDB payloads where the same NACK (pending entry) is referenced by more than one consumer, which violates a stream data-structure. **Changes** - **`rdbLoadObject` (stream consumer PEL loading)**: Added a guard that checks `nack->consumer != NULL` before assigning the consumer pointer. When a second consumer's PEL references a NACK that was already claimed by a prior consumer, the loader now reports a corrupt RDB error and aborts instead of silently overwriting the pointer. Without this check, two consumers share the same `streamNACK`, and freeing the first consumer's PEL leaves the second with a dangling pointer. - **`corrupt-dump.tcl`**: Added a regression test that crafts a stream with two consumers (`consumerA`, `consumerB`) whose PELs both reference the same entry (`1-0`). The `RESTORE` command is expected to fail with `"Bad data format"`, and the server must remain responsive (`PING` succeeds). **Benefits** - **Fail-fast on corrupt data**: The invariant violation is caught at load time with a clear diagnostic message rather than manifesting as a crash later during normal operation. - **Regression coverage**: The crafted payload in the test ensures this class of corruption is permanently guarded against. (cherry picked from commit d8a624453db3ef39bf40f3e73c25aceee9fd8b76) |
sggeorgiev <s_ggeorgiev@yahoo.com> | no | 2026-04-23 | ||
| 0018-CVE-2026-81934.patch | Fix use-after-free in tlsProcessPendingData() pending-list iteration (#1391) `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 0678e5663aa87ef0bbe62837219a4c85f6f5c93c) |
Sergei Georgiev <s_ggeorgiev@yahoo.com> | no | 2026-06-09 | ||
| 0019-Fix-ACL-key-checks-for-SORT-GEORADIUS-XREAD.patch | Fix ACL key checks for SORT, GEORADIUS/GEORADIUSBYMEMBER, and XREAD/XREADGROUP (#15478) Several commands resolved ACL keys from a keyspec that didn't match the key the command actually operates on, allowing a permission bypass: - **`GEORADIUS`/`GEORADIUSBYMEMBER`**: the `STORE`/`STOREDIST` keyspec matches the **first** occurrence of the keyword, but the command uses **last-wins** semantics and writes to the **last** key. So `GEORADIUS ... STORE <permitted> STORE <forbidden>` passed ACL while writing to the forbidden key (same for `STOREDIST` and both commands). - **`SORT`**: `STORE` also uses last-wins semantics. The `STORE` keyspec is already `unknown`, so ACL falls back to `sortGetKeys()` — but that parser didn't skip the `STORE` argument. An earlier `STORE` value that looks like an option keyword (`BY`/`GET`/`LIMIT`) derailed the scan, so a permitted (or non-existent) first key masked a forbidden last key that the write actually landed on. - **`XREAD`/`XREADGROUP`**: the stream keys are the args after the `STREAMS` keyword, whose position is found by a static keyspec. A consumer/group named `STREAMS`, or options before `GROUP`/`STREAMS`, could shift the real `STREAMS` token so ACL validated the wrong argument and the read hit a forbidden key. Make ACL resolve keys via each command's `getKeys` function, which returns the effective keys with proper flags: - **`GEORADIUS`/`GEORADIUSBYMEMBER`**: mark the `STORE`/`STOREDIST` keyspecs `INCOMPLETE` so ACL falls back to `georadiusGetKeys()`, which returns the last key (`RO|ACCESS` source, `OW|UPDATE` store). - **`SORT`**: no keyspec change needed — the `STORE` keyspec is already `unknown`, so ACL already delegates to `sortGetKeys()`. Fixed the parser to skip the `STORE` argument (`i++`) so it isn't re-parsed as an option keyword; the last `STORE` still wins. - **`XREAD`/`XREADGROUP`**: mark the keyspecs `INCOMPLETE` and fall back to `xreadGetKeys()`, which now skips option arguments (`COUNT`, `MAXCOUNT`, `MAXSIZE`, `CLAIM`, `GROUP`, …) to locate the real `STREAMS` token and tags the resolved keys `RO|ACCESS`. Adds `acl-v2` tests for duplicate `STORE`/`STOREDIST` (`GEORADIUS`/`GEORADIUSBYMEMBER`, `SORT`) and for the `XREAD`/`XREADGROUP` `STREAMS`-keyword confusion. (cherry picked from commit ce2f04c3fd72978ab7c841a8074621363c11eee0) (cherry picked from commit 00ae4906c2c079c351bd63fd3fd42bd0c4b2c8d0) |
Sergei Georgiev <s_ggeorgiev@yahoo.com> | no | 2026-07-18 | ||
| 0020-Fix-ACL-OOB-for-wrong-arity-KEYNUM-commands.patch | Fix ACL OOB for wrong-arity KEYNUM commands (#14847) `luaRedisAclCheckCmdPermissionsCommand` and `RM_ACLCheckCommandPermissions` now call `commandCheckArity()` to check command arity before calling `ACLCheckAllUserCommandPerm`, matching the behavior of `processCommand`, `scriptCall`, and `RM_Call`. Without this, KEYNUM keyspec commands like EVAL with wrong arity cause out-of-bounds argv access during key extraction. Also fix KEYNUM index calculation (`first + keynumidx`) and add a bounds check in genericGetKeys(). Add scripting and module ACL tests for wrong-arity `EVAL` to lock in the non-crashing behavior. Fixes #14843 (cherry picked from commit c4d74587b55383354f53a5c61bd313ccf7867f4b) (cherry picked from commit 1812c6d02038d2dc7bdb9b2ed5e5f1ed1b1838cf) (cherry picked from commit a8eec43d9a6b5512e248c9c2b481ca485e56d19d) |
Zijie Zhao <zzjas98@gmail.com> | no | 2026-03-18 |
All known versions for source package 'redis'
- 5:8.6.3-1 (experimental)
- 5:8.0.6-3 (forky, sid)
- 5:8.0.2-3+deb13u3 (trixie-proposed-updates, trixie-security)
- 5:8.0.2-3+deb13u2 (trixie)
- 5:7.0.15-1~deb12u10 (bookworm-security)
- 5:7.0.15-1~deb12u7 (bookworm)