{"uuid": "d294869f-3622-4f5d-aebc-313d7d0b892a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56693", "type": "seen", "source": "https://t.me/cvedetector/13842", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-56693 - Linux Kernel - Linux brd/fdisk UAF Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-56693 \nPublished : Dec. 28, 2024, 10:15 a.m. | 45\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbrd: defer automatic disk creation until module initialization succeeds  \n  \nMy colleague Wupeng found the following problems during fault injection:  \n  \nBUG: unable to handle page fault for address: fffffbfff809d073  \nPGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0  \nOops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI  \nCPU: 5 UID: 0 PID: 755 Comm: modprobe Not tainted 6.12.0-rc3+ #17  \nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS  \n1.16.1-2.fc37 04/01/2014  \nRIP: 0010:__asan_load8+0x4c/0xa0  \n...  \nCall Trace:  \n   \n blkdev_put_whole+0x41/0x70  \n bdev_release+0x1a3/0x250  \n blkdev_release+0x11/0x20  \n __fput+0x1d7/0x4a0  \n task_work_run+0xfc/0x180  \n syscall_exit_to_user_mode+0x1de/0x1f0  \n do_syscall_64+0x6b/0x170  \n entry_SYSCALL_64_after_hwframe+0x76/0x7e  \n  \nloop_init() is calling loop_add() after __register_blkdev() succeeds and  \nis ignoring disk_add() failure from loop_add(), for loop_add() failure  \nis not fatal and successfully created disks are already visible to  \nbdev_open().  \n  \nbrd_init() is currently calling brd_alloc() before __register_blkdev()  \nsucceeds and is releasing successfully created disks when brd_init()  \nreturns an error. This can cause UAF for the latter two case:  \n  \ncase 1:  \n    T1:  \nmodprobe brd  \n  brd_init  \n    brd_alloc(0) // success  \n      add_disk  \n        disk_scan_partitions  \n          bdev_file_open_by_dev // alloc file  \n          fput // won't free until back to userspace  \n    brd_alloc(1) // failed since mem alloc error inject  \n  // error path for modprobe will release code segment  \n  // back to userspace  \n  __fput  \n    blkdev_release  \n      bdev_release  \n        blkdev_put_whole  \n          bdev->bd_disk->fops->release // fops is freed now, UAF!  \n  \ncase 2:  \n    T1:                            T2:  \nmodprobe brd  \n  brd_init  \n    brd_alloc(0) // success  \n                                   open(/dev/ram0)  \n    brd_alloc(1) // fail  \n  // error path for modprobe  \n  \n                                   close(/dev/ram0)  \n                                   ...  \n                                   /* UAF! */  \n                                   bdev->bd_disk->fops->release  \n  \nFix this problem by following what loop_init() does. Besides,  \nreintroduce brd_devices_mutex to help serialize modifications to  \nbrd_list. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"28 Dec 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-12-28T12:06:10.000000Z"}