Your message dated Wed, 13 May 2026 16:19:43 +0000
with message-id <[email protected]>
and subject line Bug#1136392: fixed in redis 5:8.0.6-2
has caused the Debian Bug report #1136392,
regarding redis: incorrect return value in CVE-2026-21863 backport
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1136392: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1136392
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: redis
Version: 5:8.0.6-1
Severity: important
Tags: patch security
X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi,
The patch debian/patches/0009-CVE-2026-21863.patch was copied verbatim
from the Valkey commit. In Valkey those new bounds checks live inside
a dedicated function clusterIsValidPacket() that does not exist in Redis,
with the convention 0 = invalid, 1 = valid. In Redis the same checks sit inline
in clusterProcessPacket(), whose return value has a different meaning:
0 = link was freed, 1 = link is still alive.
The Valkey patch's two new exits return 0 on a malformed packet inside
clusterIsValidPacket(); no freeClusterLink() is ever called, so the
packet is discarded but the link stays alive.
Pasted into clusterProcessPacket() unchanged, those return 0 still
mitigate the oob-read CVE by returning before the unsafe deref.
But now they also tell the caller that the link is gone.
clusterReadHandler() then bails out without resetting link->rcvbuf_len,
which wedges the link: it stays open but no further packets from that
peer can ever be parsed, which is a new remote DoS against cluster
traffic.
Regards,
Aron
--- End Message ---
--- Begin Message ---
Source: redis
Source-Version: 5:8.0.6-2
Done: Chris Lamb <[email protected]>
We believe that the bug you reported is fixed in the latest version of
redis, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Chris Lamb <[email protected]> (supplier of updated redis package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Wed, 13 May 2026 08:41:58 -0700
Source: redis
Built-For-Profiles: nocheck
Architecture: source
Version: 5:8.0.6-2
Distribution: unstable
Urgency: medium
Maintainer: Chris Lamb <[email protected]>
Changed-By: Chris Lamb <[email protected]>
Closes: 1136392
Changes:
redis (5:8.0.6-2) unstable; urgency=medium
.
[ Chris Lamb ]
* Correct return values within CVE-2026-21863 bounds checking. Quoting Aron
Xu:
.
> The patch debian/patches/0009-CVE-2026-21863.patch was copied verbatim
> from the Valkey commit. In Valkey those new bounds checks live inside a
> dedicated function clusterIsValidPacket() that does not exist in Redis,
> with the convention 0 = invalid, 1 = valid. In Redis the same checks sit
> inline in clusterProcessPacket(), whose return value has a different
> meaning: 0 = link was freed, 1 = link is still alive.
>
> The Valkey patch's two new exits return 0 on a malformed packet inside
> clusterIsValidPacket(); no freeClusterLink() is ever called, so the
> packet is discarded but the link stays alive.
>
> Pasted into clusterProcessPacket() unchanged, those return 0 still
> mitigate the oob-read CVE by returning before the unsafe deref. But now
> they also tell the caller that the link is gone. clusterReadHandler()
> then bails out without resetting link->rcvbuf_len, which wedges the link:
> it stays open but no further packets from that peer can ever be parsed,
> which is a new remote DoS against cluster traffic.
.
(Closes: #1136392)
.
* Bump Standards-Version to 4.7.4.
.
[ Julien Lecomte ]
* Add default includes for configuration
Checksums-Sha1:
bd88e2699cc47ff1d801ab2daf0358e8c6114950 2228 redis_8.0.6-2.dsc
ac659023534af7202ddfde51d7eb97ff1b89e7eb 32820 redis_8.0.6-2.debian.tar.xz
d58af346c74e85a70a3da38857d0078ac0643330 7277 redis_8.0.6-2_amd64.buildinfo
Checksums-Sha256:
dcbaa4454be0e8fdbaa9fad87464283c4dfe15475bfeb62566bb2e86cc41507f 2228
redis_8.0.6-2.dsc
bc11b525c753e2e772e3bd36547d45908f7a83ee4919bd473c5f33afd4956bf3 32820
redis_8.0.6-2.debian.tar.xz
52aa32c30ac5de1121360e18983d8905851132a1d74de7cd36a6ff6247a06743 7277
redis_8.0.6-2_amd64.buildinfo
Files:
c912dad95f521b7f62dc889dd61806df 2228 database optional redis_8.0.6-2.dsc
64e84a1cf3cae90e0729da6918221562 32820 database optional
redis_8.0.6-2.debian.tar.xz
c76c05a7586190c7d9703caa9885a6b4 7277 database optional
redis_8.0.6-2_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEwv5L0nHBObhsUz5GHpU+J9QxHlgFAmoEn+EACgkQHpU+J9Qx
HlgwQQ/+I+QWIrdOD7SnhxLj0AUpgJZNS/ciY+wsubFU6DnZkuMEDsobmaOaCPdH
I1v6qvDcHR3ftcR7OZgG26WYM+3Wk6quSRHMCezF2rN6dw66AUu94u0l51b9rHL3
z5wchOLuARqEkDUaQFutEGHlNoYhjI4Axo/+Ve/Povuh+UzBi8TKUacKO/eDwoaP
odOcNMMtIHQT4SD1QdT0d4ebsax/VlSm71jygteZDk6OPz2uGZiHVzP0X3SYbRmx
+WFLj4tqr/nhlrbRgCrpMkiZkqUfzBp8jXc4s3BZ4/9BeV0O/a9uL/rZcRzhucjh
ddqXLLWUqF0/BXG0tdL0p0fcXhrBtpgfVaeEPkNGIPyIxIR/ZbZNgzD/V3LKWkDW
lwbBs0CtQo/VrFpt4fpsOe9uqWxe2M4sip2n7Xiue0Vaf1xBwiXV8P2qgpvHaAk3
9FmL1C8P4VCZI1vlOvcX4uoGQ4nXjiqrGIvk2EAu3khAQKAOUN8VgFhRQtrDhjjN
xy4eDmsoG7jHzPaRroZkbx8dDSTBn5DVpoqiveVqDQRDEONtgqlIaGXyZbHkhde1
zWB5O78NLC6xO4CTGbtr0AmkK4o8nH0053E4CJ9fP4FSt048h17TMohhP1CSnzlO
K1xMpBw7G96+xxUGBs91Yy7zrony/41o0d63HToX5WIStj42D9k=
=8JDf
-----END PGP SIGNATURE-----
pgpfsaMEoewhb.pgp
Description: PGP signature
--- End Message ---
