On 24.02.24 15:57, Greg Kroah-Hartman wrote:
> Description
> ===========
>
> In the Linux kernel, the following vulnerability has been resolved:
>
> sched/membarrier: reduce the ability to hammer on sys_membarrier
>
> On some systems, sys_membarrier can be very expensive, causing overall
> slowdowns for everything. So put a lock on the path in order to
> serialize the accesses to prevent the ability for this to be called at
> too high of a frequency and saturate the machine.
>
> The Linux kernel CVE team has assigned CVE-2024-26602 to this issue.
>
>
> Affected and fixed versions
> ===========================
>
> Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 4.19.307 with commit 3cd139875e9a
> Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 5.4.269 with commit 2441a64070b8
> Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 5.10.210 with commit db896bbe4a9c
> Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 5.15.149 with commit 50fb4e17df31
> Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 6.1.79 with commit 24ec7504a08a
> Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 6.6.18 with commit b6a2a9cbb675
> Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 6.7.6 with commit c5b2063c65d0
>
> Please see [...]
Greg, JFYI, I noticed that this announcement did not refer to the fix in
mainline (944d5fe50f3f03 ("sched/membarrier: reduce the ability to
hammer on sys_membarrier")) while most of the others do that. I don't
care at all, just noticed this by chance and wanted to let you know in
case it's due to a bug in a script or something. I hope there is not a
good reason for that difference I just failed to spot... (if that's the
case: apologies in advance for the noise!).
Ciao, Thorsten
On Sun, Feb 25, 2024 at 10:31:19AM +0100, Thorsten Leemhuis wrote:
> On 24.02.24 15:57, Greg Kroah-Hartman wrote:
> > Description
> > ===========
> >
> > In the Linux kernel, the following vulnerability has been resolved:
> >
> > sched/membarrier: reduce the ability to hammer on sys_membarrier
> >
> > On some systems, sys_membarrier can be very expensive, causing overall
> > slowdowns for everything. So put a lock on the path in order to
> > serialize the accesses to prevent the ability for this to be called at
> > too high of a frequency and saturate the machine.
> >
> > The Linux kernel CVE team has assigned CVE-2024-26602 to this issue.
> >
> >
> > Affected and fixed versions
> > ===========================
> >
> > Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 4.19.307 with commit 3cd139875e9a
> > Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 5.4.269 with commit 2441a64070b8
> > Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 5.10.210 with commit db896bbe4a9c
> > Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 5.15.149 with commit 50fb4e17df31
> > Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 6.1.79 with commit 24ec7504a08a
> > Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 6.6.18 with commit b6a2a9cbb675
> > Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 6.7.6 with commit c5b2063c65d0
> >
> > Please see [...]
> Greg, JFYI, I noticed that this announcement did not refer to the fix in
> mainline (944d5fe50f3f03 ("sched/membarrier: reduce the ability to
> hammer on sys_membarrier")) while most of the others do that. I don't
> care at all, just noticed this by chance and wanted to let you know in
> case it's due to a bug in a script or something. I hope there is not a
> good reason for that difference I just failed to spot... (if that's the
> case: apologies in advance for the noise!).
The json entry will be updated when the commit shows up in a tagged
release (i.e. the next -rc release), and then when the real release
happens from Linus (i.e. 6.8), it will be updated then as well.
But for now, the mainline commit is not in any "real" release so we
can't reference it here in the message or in the json record as per the
rules from CVE.
hope this helps explain things better,
greg k-h
On 25.02.24 10:47, Greg Kroah-Hartman wrote:
> On Sun, Feb 25, 2024 at 10:31:19AM +0100, Thorsten Leemhuis wrote:
>> On 24.02.24 15:57, Greg Kroah-Hartman wrote:
> [...]
>>> Affected and fixed versions
>>> ===========================
>>>
>>> Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 4.19.307 with commit 3cd139875e9a
>>> Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 5.4.269 with commit 2441a64070b8
>>> Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 5.10.210 with commit db896bbe4a9c
>>> Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 5.15.149 with commit 50fb4e17df31
>>> Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 6.1.79 with commit 24ec7504a08a
>>> Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 6.6.18 with commit b6a2a9cbb675
>>> Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 6.7.6 with commit c5b2063c65d0
>>>
>>> Please see [...]
>> Greg, JFYI, I noticed that this announcement did not refer to the fix in
>> mainline (944d5fe50f3f03 ("sched/membarrier: reduce the ability to
>> hammer on sys_membarrier")) while most of the others do that. I don't
>> care at all, just noticed this by chance and wanted to let you know in
>> case it's due to a bug in a script or something. I hope there is not a
>> good reason for that difference I just failed to spot... (if that's the
>> case: apologies in advance for the noise!).
>
> The json entry will be updated when the commit shows up in a tagged
> release (i.e. the next -rc release), and then when the real release
> happens from Linus (i.e. 6.8), it will be updated then as well.
>
> But for now, the mainline commit is not in any "real" release so we
> can't reference it here in the message or in the json record as per the
> rules from CVE.
Ohh, interesting and somewhat understandable.
Thx for your answer!
Ciao, Thorsten
On Sun, Feb 25, 2024 at 10:47:28AM +0100, Greg Kroah-Hartman wrote:
> On Sun, Feb 25, 2024 at 10:31:19AM +0100, Thorsten Leemhuis wrote:
> > On 24.02.24 15:57, Greg Kroah-Hartman wrote:
> > > Description
> > > ===========
> > >
> > > In the Linux kernel, the following vulnerability has been resolved:
> > >
> > > sched/membarrier: reduce the ability to hammer on sys_membarrier
> > >
> > > On some systems, sys_membarrier can be very expensive, causing overall
> > > slowdowns for everything. So put a lock on the path in order to
> > > serialize the accesses to prevent the ability for this to be called at
> > > too high of a frequency and saturate the machine.
> > >
> > > The Linux kernel CVE team has assigned CVE-2024-26602 to this issue.
> > >
> > >
> > > Affected and fixed versions
> > > ===========================
> > >
> > > Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 4.19.307 with commit 3cd139875e9a
> > > Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 5.4.269 with commit 2441a64070b8
> > > Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 5.10.210 with commit db896bbe4a9c
> > > Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 5.15.149 with commit 50fb4e17df31
> > > Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 6.1.79 with commit 24ec7504a08a
> > > Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 6.6.18 with commit b6a2a9cbb675
> > > Issue introduced in 4.14 with commit c5f58bd58f43 and fixed in 6.7.6 with commit c5b2063c65d0
> > >
> > > Please see [...]
> > Greg, JFYI, I noticed that this announcement did not refer to the fix in
> > mainline (944d5fe50f3f03 ("sched/membarrier: reduce the ability to
> > hammer on sys_membarrier")) while most of the others do that. I don't
> > care at all, just noticed this by chance and wanted to let you know in
> > case it's due to a bug in a script or something. I hope there is not a
> > good reason for that difference I just failed to spot... (if that's the
> > case: apologies in advance for the noise!).
>
> The json entry will be updated when the commit shows up in a tagged
> release (i.e. the next -rc release), and then when the real release
> happens from Linus (i.e. 6.8), it will be updated then as well.
It is now updated on the cve.org website at:
https://www.cve.org/CVERecord/?id=CVE-2024-26602
and in the cve git repo record as well:
https://git.kernel.org/pub/scm/linux/security/vulns.git/diff/cve/published/2024/CVE-2024-26602.mbox
thanks,
greg k-h