From 7.0.5 release notes: """ (CVE-2022-35951) Executing a XAUTOCLAIM command on a stream key in a specific state, with a specially crafted COUNT argument, may cause an integer overflow, a subsequent heap overflow, and potentially lead to remote code execution. The problem affects Redis versions 7.0.0 or newer [reported by Xion (SeungHyun Lee) of KAIST GoN]. """ It only affects 7.x, not sure how we'll handle making it the <fixed versions once committed. I guess just <7.0.5.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=59e3ca6dd662210e3168d7d090a4cf03ff42e81d commit 59e3ca6dd662210e3168d7d090a4cf03ff42e81d Author: Sam James <sam@gentoo.org> AuthorDate: 2022-09-22 04:36:51 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-09-22 05:47:50 +0000 dev-db/redis: add 7.0.5 Bug: https://bugs.gentoo.org/872278 Signed-off-by: Sam James <sam@gentoo.org> dev-db/redis/Manifest | 1 + dev-db/redis/redis-7.0.5.ebuild | 187 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 188 insertions(+)
I have been testing version 7.0.5 extensively and it suffers with the same issue reported in bug 860372 (subjectively, it happens more often than in version 7.0.4). However, the upstream fix was not present in this release line. PR #27408 backports it to 7.0.4 and 7.0.5.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fd92a504228d5932eaaf750ea469e8ed63b3fd04 commit fd92a504228d5932eaaf750ea469e8ed63b3fd04 Author: Petr Vaněk <arkamar@atlas.cz> AuthorDate: 2022-09-23 07:53:56 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-09-25 01:20:27 +0000 dev-db/redis: fix sometime failing tests due to bgsaveerr issue This change backports patch from upstream PR #11043 in order to properly solve bug #872278 reported for version 7.0.4 which affects version 7.0.5 as well. In upstream, the fix is not part of 7.0 branch, it is only present in unstable branch. Upstream-PR: https://github.com/redis/redis/pull/11043 Bug: https://bugs.gentoo.org/860372 Bug: https://bugs.gentoo.org/872278 Signed-off-by: Petr Vaněk <arkamar@atlas.cz> Signed-off-by: Sam James <sam@gentoo.org> .../files/redis-7.0.4-replica-tests-fix.patch | 61 ++++++++++++++++++++++ dev-db/redis/redis-7.0.4.ebuild | 1 + dev-db/redis/redis-7.0.5.ebuild | 1 + 3 files changed, 63 insertions(+)
(In reply to Petr Vaněk from comment #2) > I have been testing version 7.0.5 extensively and it suffers with the same > issue reported in bug 860372 (subjectively, it happens more often than in > version 7.0.4). However, the upstream fix was not present in this release > line. PR #27408 backports it to 7.0.4 and 7.0.5. Thank you!
GLSA request filed
I don't think that bug 873091 blocks any currently open security bug. All known CVEs related to =dev-db/redis-7* are specific to that major version, they don't affect any older version. At least as I understand those descriptions. This means that version dev-db/redis-6.2.7 should be ok and it is not candidate for cleanup, at least for now.
(In reply to Petr Vaněk from comment #6) > I don't think that bug 873091 blocks any currently open security bug. All > known CVEs related to =dev-db/redis-7* are specific to that major version, > they don't affect any older version. At least as I understand those > descriptions. This means that version dev-db/redis-6.2.7 should be ok and it > is not candidate for cleanup, at least for now. Which is what I meant in https://bugs.gentoo.org/803302#c13
I see, sorry, I missed that.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=46c3048bbb93d8bf616ecdd50c972b92cdbc31aa commit 46c3048bbb93d8bf616ecdd50c972b92cdbc31aa Author: Petr Vaněk <arkamar@atlas.cz> AuthorDate: 2022-09-26 18:33:14 +0000 Commit: Arthur Zamarin <arthurzam@gentoo.org> CommitDate: 2022-09-27 07:40:39 +0000 dev-db/redis: drop 7.0.4 Bug: https://bugs.gentoo.org/872278 Signed-off-by: Petr Vaněk <arkamar@atlas.cz> Closes: https://github.com/gentoo/gentoo/pull/27479 Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org> dev-db/redis/Manifest | 1 - dev-db/redis/redis-7.0.4.ebuild | 188 ---------------------------------------- 2 files changed, 189 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/glsa.git/commit/?id=3b83b8330073185fb5605b449ed900293d014aeb commit 3b83b8330073185fb5605b449ed900293d014aeb Author: GLSAMaker <glsamaker@gentoo.org> AuthorDate: 2022-09-29 14:21:49 +0000 Commit: John Helmert III <ajak@gentoo.org> CommitDate: 2022-09-29 14:47:59 +0000 [ GLSA 202209-17 ] Redis: Multiple Vulnerabilities Bug: https://bugs.gentoo.org/803302 Bug: https://bugs.gentoo.org/816282 Bug: https://bugs.gentoo.org/841404 Bug: https://bugs.gentoo.org/856040 Bug: https://bugs.gentoo.org/859181 Bug: https://bugs.gentoo.org/872278 Signed-off-by: GLSAMaker <glsamaker@gentoo.org> Signed-off-by: John Helmert III <ajak@gentoo.org> glsa-202209-17.xml | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+)
GLSA released, all done!
According to the release notes, only 7.x is affected: "The problem affects Redis versions 7.0.0 or newer" However, the GLSA also matches systems with redis-6.
(In reply to Tomáš Mózes from comment #12) > According to the release notes, only 7.x is affected: > "The problem affects Redis versions 7.0.0 or newer" > > However, the GLSA also matches systems with redis-6. Ugh, you're right, I meant to not release the Redis GLSA due to this. We're not able to make a GLSA target a set of package versions with a lower *and* upper bound, so the only way that I see to rectify this at this point is to remove the GLSA.
(In reply to John Helmert III from comment #13) > (In reply to Tomáš Mózes from comment #12) > > According to the release notes, only 7.x is affected: > > "The problem affects Redis versions 7.0.0 or newer" > > > > However, the GLSA also matches systems with redis-6. > > Ugh, you're right, I meant to not release the Redis GLSA due to this. We're > not able to make a GLSA target a set of package versions with a lower *and* > upper bound, so the only way that I see to rectify this at this point is to > remove the GLSA. My opinion on this is that this CVE is part of GLSA with bigger bundle of other CVEs, where some of them affect redis-7 only and others older versions only. Still, I think it is better to preserve this GLSA but we can change it to: Affected versions: <6.2.7 <7.0.5 Unaffected versions: >=6.2.7 >=7.0.5 in similar fashion to other bugs, or: Affected versions: <7.0.5 Unaffected versions: >=6.2.7 >=7.0.5 which I also have seen to be used, but I don't know what exactly is a difference between them. Anyway, I preffer to inform users, some of those CVEs are RCE with high score.
(In reply to Petr Vaněk from comment #14) > (In reply to John Helmert III from comment #13) > > (In reply to Tomáš Mózes from comment #12) > > > According to the release notes, only 7.x is affected: > > > "The problem affects Redis versions 7.0.0 or newer" > > > > > > However, the GLSA also matches systems with redis-6. > > > > Ugh, you're right, I meant to not release the Redis GLSA due to this. We're > > not able to make a GLSA target a set of package versions with a lower *and* > > upper bound, so the only way that I see to rectify this at this point is to > > remove the GLSA. > > My opinion on this is that this CVE is part of GLSA with bigger bundle of > other CVEs, where some of them affect redis-7 only and others older versions > only. Still, I think it is better to preserve this GLSA but we can change it > to: > > Affected versions: <6.2.7 > <7.0.5 > > Unaffected versions: >=6.2.7 > >=7.0.5 > > in similar fashion to other bugs, or: > > Affected versions: <7.0.5 > > Unaffected versions: >=6.2.7 > >=7.0.5 Seems like both of these mark everything as both unaffected and affected? > which I also have seen to be used, but I don't know what exactly is a > difference between them. These have indeed been used in the past, but they they incorrectly convey the affected versions. > Anyway, I preffer to inform users, some of those CVEs are RCE with high > score.
(In reply to John Helmert III from comment #15) > (In reply to Petr Vaněk from comment #14) > > My opinion on this is that this CVE is part of GLSA with bigger bundle of > > other CVEs, where some of them affect redis-7 only and others older versions > > only. Still, I think it is better to preserve this GLSA but we can change it > > to: > > > > Affected versions: <6.2.7 > > <7.0.5 > > > > Unaffected versions: >=6.2.7 > > >=7.0.5 > > > > in similar fashion to other bugs, or: > > > > Affected versions: <7.0.5 > > > > Unaffected versions: >=6.2.7 > > >=7.0.5 > > Seems like both of these mark everything as both unaffected and affected? > > > which I also have seen to be used, but I don't know what exactly is a > > difference between them. > > These have indeed been used in the past, but they they incorrectly convey > the affected versions. > > > Anyway, I preffer to inform users, some of those CVEs are RCE with high > > score. Ok, in that case, according to our wiki [1] (when I follow "more complex case" example) we can define: Vulnerable: <7.0.5 Unaffected: <=7.0.0 >=7.0.5 for version 7.0 and for version 6.2: Vulnerable: <6.2.7 Unaffected: >=6.2.7 I am not sure if it would be needed to split it to two GLEPs. [1] https://wiki.gentoo.org/wiki/Project:Security/GLSA_Coordinator_Guide#Unaffected.2C_Vulnerable_packages
(In reply to Petr Vaněk from comment #16) > (In reply to John Helmert III from comment #15) > > (In reply to Petr Vaněk from comment #14) > > > My opinion on this is that this CVE is part of GLSA with bigger bundle of > > > other CVEs, where some of them affect redis-7 only and others older versions > > > only. Still, I think it is better to preserve this GLSA but we can change it > > > to: > > > > > > Affected versions: <6.2.7 > > > <7.0.5 > > > > > > Unaffected versions: >=6.2.7 > > > >=7.0.5 > > > > > > in similar fashion to other bugs, or: > > > > > > Affected versions: <7.0.5 > > > > > > Unaffected versions: >=6.2.7 > > > >=7.0.5 > > > > Seems like both of these mark everything as both unaffected and affected? > > > > > which I also have seen to be used, but I don't know what exactly is a > > > difference between them. > > > > These have indeed been used in the past, but they they incorrectly convey > > the affected versions. > > > > > Anyway, I preffer to inform users, some of those CVEs are RCE with high > > > score. > > Ok, in that case, according to our wiki [1] (when I follow "more complex > case" example) we can define: > > Vulnerable: <7.0.5 > Unaffected: <=7.0.0 >=7.0.5 <=7.0.0 includes all of 6.x, but there are vulnerable 6.x versions. > for version 7.0 and for version 6.2: > > Vulnerable: <6.2.7 > Unaffected: >=6.2.7 >=6.2.7 includes 7.x, but there's vulnerable 7.x versions. > I am not sure if it would be needed to split it to two GLEPs. I don't see how splitting it up into multiple GLSAs could help, seems like it would just spread the inaccuracy across multiple GLSAs. I totally get that this is wrong, but there's really not much we can do here. I'm planning on reworking the GLSA format to accomodate this properly > [1] > https://wiki.gentoo.org/wiki/Project:Security/ > GLSA_Coordinator_Guide#Unaffected.2C_Vulnerable_packages
