CVE-2024-56693: brd: defer automatic disk creation until module initialization succeeds
In the Linux kernel, the following vulnerability has been resolved:
brd: defer automatic disk creation until module initialization succeeds
My colleague Wupeng found the following problems during fault injection:
BUG: unable to handle page fault for address: fffffbfff809d073 PGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 5 UID: 0 PID: 755 Comm: modprobe Not tainted 6.12.0-rc3+ #17 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:asanload8+0x4c/0xa0 ... Call Trace: <TASK> blkdevputwhole+0x41/0x70 bdevrelease+0x1a3/0x250 blkdevrelease+0x11/0x20 fput+0x1d7/0x4a0 taskworkrun+0xfc/0x180 syscallexittousermode+0x1de/0x1f0 dosyscall64+0x6b/0x170 entrySYSCALL64afterhwframe+0x76/0x7e
loopinit() is calling loopadd() after registerblkdev() succeeds and is ignoring diskadd() failure from loopadd(), for loopadd() failure is not fatal and successfully created disks are already visible to bdevopen().
brdinit() is currently calling brdalloc() before registerblkdev() succeeds and is releasing successfully created disks when brdinit() returns an error. This can cause UAF for the latter two case:
case 1: T1: modprobe brd brdinit brdalloc(0) // success adddisk diskscanpartitions bdevfileopenbydev // alloc file fput // won't free until back to userspace brdalloc(1) // failed since mem alloc error inject // error path for modprobe will release code segment // back to userspace fput blkdevrelease bdevrelease blkdevputwhole bdev->bddisk->fops->release // fops is freed now, UAF!
case 2: T1: T2: modprobe brd brdinit brdalloc(0) // success open(/dev/ram0) brdalloc(1) // fail // error path for modprobe
close(/dev/ram0) ... / UAF! / bdev->bddisk->fops->release
Fix this problem by following what loopinit() does. Besides, reintroduce brddevicesmutex to help serialize modifications to brdlist.
Other sources
In the Linux kernel, the following vulnerability has been resolved:
brd: defer automatic disk creation until module initialization succeeds
My colleague Wupeng found the following problems during fault injection:
BUG: unable to handle page fault for address: fffffbfff809d073 PGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 5 UID: 0 PID: 755 Comm: modprobe Not tainted 6.12.0-rc3+ #17 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:asanload8+0x4c/0xa0 ... Call Trace: <TASK> blkdevputwhole+0x41/0x70 bdevrelease+0x1a3/0x250 blkdevrelease+0x11/0x20 fput+0x1d7/0x4a0 taskworkrun+0xfc/0x180 syscallexittousermode+0x1de/0x1f0 dosyscall64+0x6b/0x170 entrySYSCALL64afterhwframe+0x76/0x7e
loopinit() is calling loopadd() after registerblkdev() succeeds and is ignoring diskadd() failure from loopadd(), for loopadd() failure is not fatal and successfully created disks are already visible to bdevopen().
brdinit() is currently calling brdalloc() before registerblkdev() succeeds and is releasing successfully created disks when brdinit() returns an error. This can cause UAF for the latter two case:
case 1: T1: modprobe brd brdinit brdalloc(0) // success adddisk diskscanpartitions bdevfileopenbydev // alloc file fput // won't free until back to userspace brdalloc(1) // failed since mem alloc error inject // error path for modprobe will release code segment // back to userspace fput blkdevrelease bdevrelease blkdevputwhole bdev->bddisk->fops->release // fops is freed now, UAF!
case 2: T1: T2: modprobe brd brdinit brdalloc(0) // success open(/dev/ram0) brdalloc(1) // fail // error path for modprobe
close(/dev/ram0) ... / UAF! / bdev->bddisk->fops->release
Fix this problem by following what loopinit() does. Besides, reintroduce brddevicesmutex to help serialize modifications to brdlist.
— NVD
This CVE was automatically created from a reference found in an email or other text. If you are reading this, then this CVE entry is probably erroneous, since this text should be replaced by the official CVE description automatically.
— Launchpad
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 5.10.223-1Fixed in 5.10.234-1Fixed in 6.1.129-1Fixed in 6.1.135-1Fixed in 6.12.25-1Fixed in 6.12.27-1 - Upgrade
Upgrade
debian/linux-6.1to a version that resolves this vulnerability.Fixed in 6.1.129-1~deb11u1 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.12.0-rc3+ - Compensating control
Reintroduce brd_devices_mutex to serialize modifications to brd_list.
Event History
Frequently Asked Questions
What is the severity of CVE-2024-56693?
The severity of CVE-2024-56693 is categorized as moderate due to potential impacts on system stability.
How do I fix CVE-2024-56693?
To fix CVE-2024-56693, update the Linux kernel to the latest stable version that includes the patch.
What systems are affected by CVE-2024-56693?
CVE-2024-56693 affects the Linux kernel across various distributions.
What is the nature of the vulnerability in CVE-2024-56693?
CVE-2024-56693 involves a bug related to page fault handling during module initialization.
Is there any workaround for CVE-2024-56693?
Currently, there are no documented workarounds for CVE-2024-56693 other than applying the kernel update.