Re: CVE-2024-35876: x86/mce: Make sure to grab mce_sysfs_mutex in set_bank()

Re: CVE-2024-35876: x86/mce: Make sure to grab mce_sysfs_mutex in set_bank()

[Nikolay Borisov]

On 19.05.24 г. 11:34 ч., Greg Kroah-Hartman wrote:
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> x86/mce: Make sure to grab mce_sysfs_mutex in set_bank()
> 
> Modifying a MCA bank's MCA_CTL bits which control which error types to
> be reported is done over
> 
>    /sys/devices/system/machinecheck/
>    ├── machinecheck0
>    │   ├── bank0
>    │   ├── bank1
>    │   ├── bank10
>    │   ├── bank11
>    ...
> 
> sysfs nodes by writing the new bit mask of events to enable.
> 
> When the write is accepted, the kernel deletes all current timers and
> reinits all banks.
> 
> Doing that in parallel can lead to initializing a timer which is already
> armed and in the timer wheel, i.e., in use already:
> 
>    ODEBUG: init active (active state 0) object: ffff888063a28000 object
>    type: timer_list hint: mce_timer_fn+0x0/0x240 arch/x86/kernel/cpu/mce/core.c:2642
>    WARNING: CPU: 0 PID: 8120 at lib/debugobjects.c:514
>    debug_print_object+0x1a0/0x2a0 lib/debugobjects.c:514
> 
> Fix that by grabbing the sysfs mutex as the rest of the MCA sysfs code
> does.
> 
> Reported by: Yue Sun <samsun1006219@gmail.com>
> Reported by: xingwei lee <xrivendell7@gmail.com>
> 
> The Linux kernel CVE team has assigned CVE-2024-35876 to this issue.


I'd like to dispute the CVE for this issue. Those sysfs entries are 
owned by root and can only be written by it. There are innumerable ways 
in which root can corrupt/crash the state of the machine and I don't see 
why this is anything special.


> 
> 
> Affected and fixed versions
> ===========================
> 
> 	Fixed in 5.4.274 with commit 976b1b2680fb
> 	Fixed in 5.10.215 with commit f5e65b782f3e
> 	Fixed in 5.15.154 with commit f860595512ff
> 	Fixed in 6.1.85 with commit 20a915154ccb
> 	Fixed in 6.6.26 with commit 5a02df3e9247
> 	Fixed in 6.8.5 with commit 32223b0b60d5
> 	Fixed in 6.9 with commit 3ddf944b32f8
> 
> 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-35876
> 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:
> 	arch/x86/kernel/cpu/mce/core.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/976b1b2680fb4c01aaf05a0623288d87619a6c93
> 	https://git.kernel.org/stable/c/f5e65b782f3e07324b9a8fa3cdaee422f057c758
> 	https://git.kernel.org/stable/c/f860595512ff5c05a29fa4d64169c3fd1186b8cf
> 	https://git.kernel.org/stable/c/20a915154ccb88da08986ab6c9fc4c1cf6259de2
> 	https://git.kernel.org/stable/c/5a02df3e92470efd589712925b5c722e730276a0
> 	https://git.kernel.org/stable/c/32223b0b60d53f49567fc501f91ca076ae96be6b
> 	https://git.kernel.org/stable/c/3ddf944b32f88741c303f0b21459dbb3872b8bc5

Re: CVE-2024-35876: x86/mce: Make sure to grab mce_sysfs_mutex in set_bank()

[Greg Kroah-Hartman]

On Thu, May 23, 2024 at 01:24:33PM +0300, Nikolay Borisov wrote:
> 
> 
> On 19.05.24 г. 11:34 ч., Greg Kroah-Hartman wrote:
> > Description
> > ===========
> > 
> > In the Linux kernel, the following vulnerability has been resolved:
> > 
> > x86/mce: Make sure to grab mce_sysfs_mutex in set_bank()
> > 
> > Modifying a MCA bank's MCA_CTL bits which control which error types to
> > be reported is done over
> > 
> >    /sys/devices/system/machinecheck/
> >    ├── machinecheck0
> >    │   ├── bank0
> >    │   ├── bank1
> >    │   ├── bank10
> >    │   ├── bank11
> >    ...
> > 
> > sysfs nodes by writing the new bit mask of events to enable.
> > 
> > When the write is accepted, the kernel deletes all current timers and
> > reinits all banks.
> > 
> > Doing that in parallel can lead to initializing a timer which is already
> > armed and in the timer wheel, i.e., in use already:
> > 
> >    ODEBUG: init active (active state 0) object: ffff888063a28000 object
> >    type: timer_list hint: mce_timer_fn+0x0/0x240 arch/x86/kernel/cpu/mce/core.c:2642
> >    WARNING: CPU: 0 PID: 8120 at lib/debugobjects.c:514
> >    debug_print_object+0x1a0/0x2a0 lib/debugobjects.c:514
> > 
> > Fix that by grabbing the sysfs mutex as the rest of the MCA sysfs code
> > does.
> > 
> > Reported by: Yue Sun <samsun1006219@gmail.com>
> > Reported by: xingwei lee <xrivendell7@gmail.com>
> > 
> > The Linux kernel CVE team has assigned CVE-2024-35876 to this issue.
> 
> 
> I'd like to dispute the CVE for this issue. Those sysfs entries are owned by
> root and can only be written by it. There are innumerable ways in which root
> can corrupt/crash the state of the machine and I don't see why this is
> anything special.

Good catch, now rejected, thanks!

greg k-h

Re: CVE-2024-35876: x86/mce: Make sure to grab mce_sysfs_mutex in set_bank()

[Vegard Nossum]

On 23/05/2024 12:24, Nikolay Borisov wrote:
> On 19.05.24 г. 11:34 ч., Greg Kroah-Hartman wrote:
>> Description
>> ===========
>>
>> In the Linux kernel, the following vulnerability has been resolved:
>>
>> x86/mce: Make sure to grab mce_sysfs_mutex in set_bank()
>>
>> Modifying a MCA bank's MCA_CTL bits which control which error types to
>> be reported is done over
>>
>>    /sys/devices/system/machinecheck/
>>    ├── machinecheck0
>>    │   ├── bank0
>>    │   ├── bank1
>>    │   ├── bank10
>>    │   ├── bank11
>>    ...
>>
>> sysfs nodes by writing the new bit mask of events to enable.
>>
>> When the write is accepted, the kernel deletes all current timers and
>> reinits all banks.
>>
>> Doing that in parallel can lead to initializing a timer which is already
>> armed and in the timer wheel, i.e., in use already:
>>
>>    ODEBUG: init active (active state 0) object: ffff888063a28000 object
>>    type: timer_list hint: mce_timer_fn+0x0/0x240 
>> arch/x86/kernel/cpu/mce/core.c:2642
>>    WARNING: CPU: 0 PID: 8120 at lib/debugobjects.c:514
>>    debug_print_object+0x1a0/0x2a0 lib/debugobjects.c:514
>>
>> Fix that by grabbing the sysfs mutex as the rest of the MCA sysfs code
>> does.
>>
>> Reported by: Yue Sun <samsun1006219@gmail.com>
>> Reported by: xingwei lee <xrivendell7@gmail.com>
>>
>> The Linux kernel CVE team has assigned CVE-2024-35876 to this issue.
> 
> 
> I'd like to dispute the CVE for this issue. Those sysfs entries are 
> owned by root and can only be written by it. There are innumerable ways 
> in which root can corrupt/crash the state of the machine and I don't see 
> why this is anything special.

I haven't looked at the issue in detail but it sounds like this
potentially breaks lockdown (which is arguably a security feature) so
"requires root" to reach is not really an argument against this having a
CVE assigned.


Vegard

Re: CVE-2024-35876: x86/mce: Make sure to grab mce_sysfs_mutex in set_bank()

[Nikolay Borisov]

On 23.05.24 г. 16:54 ч., Vegard Nossum wrote:
> 
> On 23/05/2024 12:24, Nikolay Borisov wrote:
>> On 19.05.24 г. 11:34 ч., Greg Kroah-Hartman wrote:
>>> Description
>>> ===========
>>>
>>> In the Linux kernel, the following vulnerability has been resolved:
>>>
>>> x86/mce: Make sure to grab mce_sysfs_mutex in set_bank()
>>>
>>> Modifying a MCA bank's MCA_CTL bits which control which error types to
>>> be reported is done over
>>>
>>>    /sys/devices/system/machinecheck/
>>>    ├── machinecheck0
>>>    │   ├── bank0
>>>    │   ├── bank1
>>>    │   ├── bank10
>>>    │   ├── bank11
>>>    ...
>>>
>>> sysfs nodes by writing the new bit mask of events to enable.
>>>
>>> When the write is accepted, the kernel deletes all current timers and
>>> reinits all banks.
>>>
>>> Doing that in parallel can lead to initializing a timer which is already
>>> armed and in the timer wheel, i.e., in use already:
>>>
>>>    ODEBUG: init active (active state 0) object: ffff888063a28000 object
>>>    type: timer_list hint: mce_timer_fn+0x0/0x240 
>>> arch/x86/kernel/cpu/mce/core.c:2642
>>>    WARNING: CPU: 0 PID: 8120 at lib/debugobjects.c:514
>>>    debug_print_object+0x1a0/0x2a0 lib/debugobjects.c:514
>>>
>>> Fix that by grabbing the sysfs mutex as the rest of the MCA sysfs code
>>> does.
>>>
>>> Reported by: Yue Sun <samsun1006219@gmail.com>
>>> Reported by: xingwei lee <xrivendell7@gmail.com>
>>>
>>> The Linux kernel CVE team has assigned CVE-2024-35876 to this issue.
>>
>>
>> I'd like to dispute the CVE for this issue. Those sysfs entries are 
>> owned by root and can only be written by it. There are innumerable 
>> ways in which root can corrupt/crash the state of the machine and I 
>> don't see why this is anything special.
> 
> I haven't looked at the issue in detail but it sounds like this
> potentially breaks lockdown (which is arguably a security feature) so

How exactly does it break lockdown ?

> "requires root" to reach is not really an argument against this having a
> CVE assigned.
> 
> 
> Vegard

Re: CVE-2024-35876: x86/mce: Make sure to grab mce_sysfs_mutex in set_bank()

[Vegard Nossum]

On 23/05/2024 15:58, Nikolay Borisov wrote:
> On 23.05.24 г. 16:54 ч., Vegard Nossum wrote:
>> On 23/05/2024 12:24, Nikolay Borisov wrote:
>>> I'd like to dispute the CVE for this issue. Those sysfs entries are 
>>> owned by root and can only be written by it. There are innumerable 
>>> ways in which root can corrupt/crash the state of the machine and I 
>>> don't see why this is anything special.
>>
>> I haven't looked at the issue in detail but it sounds like this
>> potentially breaks lockdown (which is arguably a security feature) so
> 
> How exactly does it break lockdown ?

Well, I don't have an exploit and it looks difficult as there isn't any
user-provided input involved.

But generally lockdown prevents anybody (including root) from inspecting
and modifying the running kernel. So if this bug would allow that, then
it breaks lockdown.

Glancing over the code it doesn't look like a use-after-free, just some
unspecified concurrent access. I can't tell if it's exploitable. I'm
just remarking that "requires root access" is not by itself a reason to
reject the CVE.


Vegard