This and couple of others are all having the same pattern. Adding
READ_ONCE for an integer value with a claim that this might race with
sysctl updates. While the claim about the race is correct I fail to see
how this could have any security consequences. Even if a partial write
was observed which sounds _more_ than theoretical these all are merely
timeouts and delays.
Is there anything I am missing?
On Fri 17-05-24 14:02:29, Greg KH wrote:
> Description
> ===========
>
> In the Linux kernel, the following vulnerability has been resolved:
>
> netrom: Fix a data-race around sysctl_netrom_obsolescence_count_initialiser
>
> We need to protect the reader reading the sysctl value
> because the value can be changed concurrently.
>
> The Linux kernel CVE team has assigned CVE-2024-27429 to this issue.
>
>
> Affected and fixed versions
> ===========================
>
> Issue introduced in 2.6.12 with commit 1da177e4c3f4 and fixed in 4.19.310 with commit e3a3718b1723
> Issue introduced in 2.6.12 with commit 1da177e4c3f4 and fixed in 5.4.272 with commit 1e84b108f2a7
> Issue introduced in 2.6.12 with commit 1da177e4c3f4 and fixed in 5.10.213 with commit 18c95d11c347
> Issue introduced in 2.6.12 with commit 1da177e4c3f4 and fixed in 5.15.152 with commit b3f0bc3a315c
> Issue introduced in 2.6.12 with commit 1da177e4c3f4 and fixed in 6.1.82 with commit e439607291c0
> Issue introduced in 2.6.12 with commit 1da177e4c3f4 and fixed in 6.6.22 with commit 7e1e25891f09
> Issue introduced in 2.6.12 with commit 1da177e4c3f4 and fixed in 6.7.10 with commit 591192c3a9fc
> Issue introduced in 2.6.12 with commit 1da177e4c3f4 and fixed in 6.8 with commit cfd9f4a740f7
>
> Please see https://www.kernel.org for a full list of currently supported
> kernel versions by the kernel community.
>
> Unaffected versions might change over time as fixes are backported to
> older supported kernel versions. The official CVE entry at
> https://cve.org/CVERecord/?id=CVE-2024-27429
> will be updated if fixes are backported, please check that for the most
> up to date information about this issue.
>
>
> Affected files
> ==============
>
> The file(s) affected by this issue are:
> net/netrom/nr_route.c
>
>
> Mitigation
> ==========
>
> The Linux kernel CVE team recommends that you update to the latest
> stable kernel version for this, and many other bugfixes. Individual
> changes are never tested alone, but rather are part of a larger kernel
> release. Cherry-picking individual commits is not recommended or
> supported by the Linux kernel community at all. If however, updating to
> the latest release is impossible, the individual changes to resolve this
> issue can be found at these commits:
> https://git.kernel.org/stable/c/e3a3718b1723253d4f068e88e81d880d71f1a1e9
> https://git.kernel.org/stable/c/1e84b108f2a71daa8d04032e4d2096522376debb
> https://git.kernel.org/stable/c/18c95d11c347a12e5c31df1325cef6b995d14ecf
> https://git.kernel.org/stable/c/b3f0bc3a315cf1af03673a0163c08fe037587acd
> https://git.kernel.org/stable/c/e439607291c082332e1e35baf8faf8552e6bcb4a
> https://git.kernel.org/stable/c/7e1e25891f090e24a871451c9403abac63cb45dd
> https://git.kernel.org/stable/c/591192c3a9fc728a0af7b9dd50bf121220062293
> https://git.kernel.org/stable/c/cfd9f4a740f772298308b2e6070d2c744fb5cf79
--
Michal Hocko
SUSE Labs
On Tue, May 21, 2024 at 10:39:04AM +0200, Michal Hocko wrote:
> This and couple of others are all having the same pattern. Adding
> READ_ONCE for an integer value with a claim that this might race with
> sysctl updates. While the claim about the race is correct I fail to see
> how this could have any security consequences. Even if a partial write
> was observed which sounds _more_ than theoretical these all are merely
> timeouts and delays.
>
> Is there anything I am missing?
Nope, you are right, our fault, I'll go revoke this now.
Thanks for the review, it's much appreciated!
greg k-h
On Tue 21-05-24 16:40:24, Greg KH wrote:
> On Tue, May 21, 2024 at 10:39:04AM +0200, Michal Hocko wrote:
> > This and couple of others are all having the same pattern. Adding
> > READ_ONCE for an integer value with a claim that this might race with
> > sysctl updates. While the claim about the race is correct I fail to see
> > how this could have any security consequences. Even if a partial write
> > was observed which sounds _more_ than theoretical these all are merely
> > timeouts and delays.
> >
> > Is there anything I am missing?
>
> Nope, you are right, our fault, I'll go revoke this now.
please also revoke all others touching the same function.
--
Michal Hocko
SUSE Labs
On Tue, May 21, 2024 at 06:05:03PM +0200, Michal Hocko wrote:
> On Tue 21-05-24 16:40:24, Greg KH wrote:
> > On Tue, May 21, 2024 at 10:39:04AM +0200, Michal Hocko wrote:
> > > This and couple of others are all having the same pattern. Adding
> > > READ_ONCE for an integer value with a claim that this might race with
> > > sysctl updates. While the claim about the race is correct I fail to see
> > > how this could have any security consequences. Even if a partial write
> > > was observed which sounds _more_ than theoretical these all are merely
> > > timeouts and delays.
> > >
> > > Is there anything I am missing?
> >
> > Nope, you are right, our fault, I'll go revoke this now.
>
> please also revoke all others touching the same function.
I don't see any other CVEs that reference that function, but I do see
some that reference the same type of issue in the same file:
CVE-2024-27420
CVE-2024-27421
CVE-2024-27430
are those what you are referring to? If not, which ones do you think
also should be revoked?
thanks,
greg k-h
On 22/05/24 07:11, Greg Kroah-Hartman wrote:
> On Tue, May 21, 2024 at 06:05:03PM +0200, Michal Hocko wrote:
>> On Tue 21-05-24 16:40:24, Greg KH wrote:
>>> On Tue, May 21, 2024 at 10:39:04AM +0200, Michal Hocko wrote:
>>>> This and couple of others are all having the same pattern. Adding
>>>> READ_ONCE for an integer value with a claim that this might race with
>>>> sysctl updates. While the claim about the race is correct I fail to see
>>>> how this could have any security consequences. Even if a partial write
>>>> was observed which sounds _more_ than theoretical these all are merely
>>>> timeouts and delays.
>>>>
>>>> Is there anything I am missing?
>>>
>>> Nope, you are right, our fault, I'll go revoke this now.
>>
>> please also revoke all others touching the same function.
>
> I don't see any other CVEs that reference that function, but I do see
> some that reference the same type of issue in the same file:
> CVE-2024-27420
> CVE-2024-27421
> CVE-2024-27430
> are those what you are referring to? If not, which ones do you think
> also should be revoked?
It seems all the CVEs in the range [CVE-2024-27420, CVE-2024-27430] are of the same kind.
Shouldn't all be revoked?
Thanks
Davide Benini
On Wed 22-05-24 12:21:54, Davide Benini wrote:
> On 22/05/24 07:11, Greg Kroah-Hartman wrote:
> > On Tue, May 21, 2024 at 06:05:03PM +0200, Michal Hocko wrote:
> > > On Tue 21-05-24 16:40:24, Greg KH wrote:
> > > > On Tue, May 21, 2024 at 10:39:04AM +0200, Michal Hocko wrote:
> > > > > This and couple of others are all having the same pattern. Adding
> > > > > READ_ONCE for an integer value with a claim that this might race with
> > > > > sysctl updates. While the claim about the race is correct I fail to see
> > > > > how this could have any security consequences. Even if a partial write
> > > > > was observed which sounds _more_ than theoretical these all are merely
> > > > > timeouts and delays.
> > > > >
> > > > > Is there anything I am missing?
> > > >
> > > > Nope, you are right, our fault, I'll go revoke this now.
> > >
> > > please also revoke all others touching the same function.
> >
> > I don't see any other CVEs that reference that function, but I do see
> > some that reference the same type of issue in the same file:
> > CVE-2024-27420
> > CVE-2024-27421
> > CVE-2024-27430
> > are those what you are referring to? If not, which ones do you think
> > also should be revoked?
>
> It seems all the CVEs in the range [CVE-2024-27420, CVE-2024-27430] are of the same kind.
> Shouldn't all be revoked?
Yes all these
bc76645ebdd0 ("netrom: Fix a data-race around sysctl_netrom_link_fails_count")
b5dffcb8f71b ("netrom: Fix a data-race around sysctl_netrom_routing_control")
f99b494b4043 ("netrom: Fix a data-race around sysctl_netrom_transport_no_activity_timeout")
a2e706841488 ("netrom: Fix a data-race around sysctl_netrom_transport_requested_window_size")
43547d869943 ("netrom: Fix a data-race around sysctl_netrom_transport_busy_delay")
806f462ba902 ("netrom: Fix a data-race around sysctl_netrom_transport_acknowledge_delay")
e799299aafed ("netrom: Fix a data-race around sysctl_netrom_transport_maximum_tries")
60a7a152abd4 ("netrom: Fix a data-race around sysctl_netrom_transport_timeout")
119cae5ea3f9 ("netrom: Fix data-races around sysctl_netrom_network_ttl_initialiser")
cfd9f4a740f7 ("netrom: Fix a data-race around sysctl_netrom_obsolescence_count_initialiser")
958d6145a6d9 ("netrom: Fix a data-race around sysctl_netrom_default_path_quality")
--
Michal Hocko
SUSE Labs
On Fri, May 24, 2024 at 01:27:19PM +0200, Michal Hocko wrote:
> On Wed 22-05-24 12:21:54, Davide Benini wrote:
> > On 22/05/24 07:11, Greg Kroah-Hartman wrote:
> > > On Tue, May 21, 2024 at 06:05:03PM +0200, Michal Hocko wrote:
> > > > On Tue 21-05-24 16:40:24, Greg KH wrote:
> > > > > On Tue, May 21, 2024 at 10:39:04AM +0200, Michal Hocko wrote:
> > > > > > This and couple of others are all having the same pattern. Adding
> > > > > > READ_ONCE for an integer value with a claim that this might race with
> > > > > > sysctl updates. While the claim about the race is correct I fail to see
> > > > > > how this could have any security consequences. Even if a partial write
> > > > > > was observed which sounds _more_ than theoretical these all are merely
> > > > > > timeouts and delays.
> > > > > >
> > > > > > Is there anything I am missing?
> > > > >
> > > > > Nope, you are right, our fault, I'll go revoke this now.
> > > >
> > > > please also revoke all others touching the same function.
> > >
> > > I don't see any other CVEs that reference that function, but I do see
> > > some that reference the same type of issue in the same file:
> > > CVE-2024-27420
> > > CVE-2024-27421
> > > CVE-2024-27430
> > > are those what you are referring to? If not, which ones do you think
> > > also should be revoked?
> >
> > It seems all the CVEs in the range [CVE-2024-27420, CVE-2024-27430] are of the same kind.
> > Shouldn't all be revoked?
>
> Yes all these
> bc76645ebdd0 ("netrom: Fix a data-race around sysctl_netrom_link_fails_count")
> b5dffcb8f71b ("netrom: Fix a data-race around sysctl_netrom_routing_control")
> f99b494b4043 ("netrom: Fix a data-race around sysctl_netrom_transport_no_activity_timeout")
> a2e706841488 ("netrom: Fix a data-race around sysctl_netrom_transport_requested_window_size")
> 43547d869943 ("netrom: Fix a data-race around sysctl_netrom_transport_busy_delay")
> 806f462ba902 ("netrom: Fix a data-race around sysctl_netrom_transport_acknowledge_delay")
> e799299aafed ("netrom: Fix a data-race around sysctl_netrom_transport_maximum_tries")
> 60a7a152abd4 ("netrom: Fix a data-race around sysctl_netrom_transport_timeout")
> 119cae5ea3f9 ("netrom: Fix data-races around sysctl_netrom_network_ttl_initialiser")
> cfd9f4a740f7 ("netrom: Fix a data-race around sysctl_netrom_obsolescence_count_initialiser")
> 958d6145a6d9 ("netrom: Fix a data-race around sysctl_netrom_default_path_quality")
All now revoked, thanks.
greg k-h