Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
usually hang the whole system. To avoid the issue use pm_runtime_get_if_active() to check if the device is enabled and prevent suspending it when we handle irq until the end of irq. Additionally use synchronize_irq() in suspend References: - https://git.kernel.org/stable/c/ed4524c87249edc3104f6bb28ab11325bed3d536 - https://git.kernel.org/stable/c/57241487a3648515c9aa6fa89e31f2414eccfdbc - https://git.kernel.org/stable/c/1429826883bb18847092b2e04c6598ef34bae1d4
CVE ID: CVE-2024-56681 State: PUBLISHED Published: 2024-12-28T09:46:09.675Z Last Updated: 2025-11-03T20:52:28.536Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: bcm - add error check in the ahash_hmac_init function The ahash_init functions may return fails. The ahash_hmac_init should not return ok when ahash_init returns error. For an example, ahash_init will return -ENOMEM when allocation memory is error. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/8f1a9a960b1107bd0e0ec3736055f5ed0e717edf - https://git.kernel.org/stable/c/75e1e38e5d80d6d9011b7322698ffba3dd3db30a - h
/8f1a9a960b1107bd0e0ec3736055f5ed0e717edf - https://git.kernel.org/stable/c/75e1e38e5d80d6d9011b7322698ffba3dd3db30a - https://git.kernel.org/stable/c/28f8ffa945f7d7150463e15097ea73b19529d6f5 - https://git.kernel.org/stable/c/4ea3e3b761e371102bb1486778e2f8dbc9e37413 - https://git.kernel.org/stable/c/05f0a3f5477ecaa1cf46448504afe9e7c2e96fcc - https://git.kernel.org/stable/c/ae5253313e0ea5f00c06176074592b7f493c8546 - https://git.kernel.org/stable/c/ee36db8e8203420e6d5c42eb9428920c2fc36532 - https://git.kernel.org/stable/c/bba9e38c5ad41d0a88b22a59e5b6dd3e31825118 - https://git.kernel.org/stable/c/19630cf57233e845b6ac57c9c969a4888925467b
CVE ID: CVE-2024-56682 State: PUBLISHED Published: 2024-12-28T09:46:10.418Z Last Updated: 2025-10-01T20:07:08.664Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: irqchip/riscv-aplic: Prevent crash when MSI domain is missing If the APLIC driver is probed before the IMSIC driver, the parent MSI domain will be missing, which causes a NULL pointer dereference in msi_create_device_irq_domain(). Avoid this by deferring probe until the parent MSI domain is available. Use dev_err_probe() to avoid printing an error message when returning -EPROBE_DEFER. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.o
sage when returning -EPROBE_DEFER. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/285a07810ab3bcedc2bd380ebacbf6b4942a889a - https://git.kernel.org/stable/c/1f181d1cda56c2fbe379c5ace1aa1fac6306669e
CVE ID: CVE-2024-56683 State: PUBLISHED Published: 2024-12-28T09:46:11.183Z Last Updated: 2025-11-03T20:52:29.934Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hdmi: Avoid hang with debug registers when suspended Trying to read /sys/kernel/debug/dri/1/hdmi1_regs when the hdmi is disconnected results in a fatal system hang. This is due to the pm suspend code disabling the dvp clock. That is just a gate of the 108MHz clock in DVP_HT_RPI_MISC_CONFIG, which results in accesses hanging AXI bus. Protect against this. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/0ea29bd7d9
gainst this. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/0ea29bd7d9400d3629683244d609358ed1b12075 - https://git.kernel.org/stable/c/c7d474974954d9af7e0092021223d58f2de128df - https://git.kernel.org/stable/c/16f351adf733a182224ad24916d7673aa6df02df - https://git.kernel.org/stable/c/74f21be9990a42dc2357bcf87a13e16c6998b90e - https://git.kernel.org/stable/c/223ee2567a55e4f80315c768d2969e6a3b9fb23d
CVE ID: CVE-2024-56684 State: PUBLISHED Published: 2024-12-28T09:46:11.932Z Last Updated: 2025-05-04T10:02:18.465Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mailbox: mtk-cmdq: fix wrong use of sizeof in cmdq_get_clocks() It should be size of the struct clk_bulk_data, not data pointer pass to devm_kcalloc(). References: - https://git.kernel.org/stable/c/31986fad0cfdda8d8893230da04f5eb0774854d9 - https://git.kernel.org/stable/c/a9c7cb960fc6e056ebecebd136a127612b15630d - https://git.kernel.org/stable/c/271ee263cc8771982809185007181ca10346fe73
CVE ID: CVE-2024-56685 State: PUBLISHED Published: 2024-12-28T09:46:12.686Z Last Updated: 2025-05-04T10:02:19.739Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe Following commit 13f58267cda3 ("ASoC: soc.h: don't create dummy Component via COMP_DUMMY()"), COMP_DUMMY() became an array with zero length, and only gets populated with the dummy struct after the card is registered. Since the sound card driver's probe happens before the card registration, accessing any of the members of a dummy component during probe will result in undefined behavior. This can be
istration, accessing any of the members of a dummy component during probe will result in undefined behavior. This can be observed in the mt8188 and mt8195 machine sound drivers. By omitting a dai link subnode in the sound card's node in the Devicetree, the default uninitialized dummy codec is used, and when its dai_name pointer gets passed to strcmp() it results in a null pointer dereference and a kernel panic. In addition to that, set_card_codec_info() in the generic helpers file, mtk-soundcard-driver.c, will populate a dai link with a dummy codec when a dai link node is present in DT but with no codec property. The result is that at probe time, a dummy codec can either be uninitialized wit
resent in DT but with no codec property. The result is that at probe time, a dummy codec can either be uninitialized with num_codecs = 0, or be an initialized dummy codec, with num_codecs = 1 and dai_name = "snd-soc-dummy-dai". In order to accommodate for both situations, check that num_codecs is not zero before accessing the codecs' fields but still check for the codec's dai name against "snd-soc-dummy-dai" as needed. While at it, also drop the check that dai_name is not null in the mt8192 driver, introduced in commit 4d4e1b6319e5 ("ASoC: mediatek: mt8192: Check existence of dai_name before dereferencing"), as it is actually redundant given the preceding num_codecs != 0 check. References: -
of dai_name before dereferencing"), as it is actually redundant given the preceding num_codecs != 0 check. References: - https://git.kernel.org/stable/c/376f4800f34a28def026ff5c5d4fc5e54e1744ff - https://git.kernel.org/stable/c/550279449ff54c5aa28cfca5c567308cbfb145f0 - https://git.kernel.org/stable/c/2f2020327cc8561d7c520d2f2d9acea84fa7b3a3
CVE ID: CVE-2024-56686 State: REJECTED Published: 2024-12-28T09:46:13.429Z Last Updated: 2025-01-07T08:47:17.142Z Description: No description available.
CVE ID: CVE-2024-56687 State: PUBLISHED Published: 2024-12-28T09:46:14.197Z Last Updated: 2025-11-03T20:52:31.337Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: musb: Fix hardware lockup on first Rx endpoint request There is a possibility that a request's callback could be invoked from usb_ep_queue() (call trace below, supplemented with missing calls): req->complete from usb_gadget_giveback_request (drivers/usb/gadget/udc/core.c:999) usb_gadget_giveback_request from musb_g_giveback (drivers/usb/musb/musb_gadget.c:147) musb_g_giveback from rxstate (drivers/usb/musb/musb_gadget.c:784) rxstate from musb_ep_restart (drivers/u
_gadget.c:147) musb_g_giveback from rxstate (drivers/usb/musb/musb_gadget.c:784) rxstate from musb_ep_restart (drivers/usb/musb/musb_gadget.c:1169) musb_ep_restart from musb_ep_restart_resume_work (drivers/usb/musb/musb_gadget.c:1176) musb_ep_restart_resume_work from musb_queue_resume_work (drivers/usb/musb/musb_core.c:2279) musb_queue_resume_work from musb_gadget_queue (drivers/usb/musb/musb_gadget.c:1241) musb_gadget_queue from usb_ep_queue (drivers/usb/gadget/udc/core.c:300) According to the docstring of usb_ep_queue(), this should not happen: "Note that @req's ->complete() callback must never be called from within usb_ep_queue() as that can create deadlock situations." In fact, a hardwar
e() callback must never be called from within usb_ep_queue() as that can create deadlock situations." In fact, a hardware lockup might occur in the following sequence: 1. The gadget is initialized using musb_gadget_enable(). 2. Meanwhile, a packet arrives, and the RXPKTRDY flag is set, raising an interrupt. 3. If IRQs are enabled, the interrupt is handled, but musb_g_rx() finds an empty queue (next_request() returns NULL). The interrupt flag has already been cleared by the glue layer handler, but the RXPKTRDY flag remains set. 4. The first request is enqueued using usb_ep_queue(), leading to the call of req->complete(), as shown in the call trace above. 5. If the callback enables IRQs and an
ueue(), leading to the call of req->complete(), as shown in the call trace above. 5. If the callback enables IRQs and another packet is waiting, step (3) repeats. The request queue is empty because usb_g_giveback() removes the request before invoking the callback. 6. The endpoint remains locked up, as the interrupt triggered by hardware setting the RXPKTRDY flag has been handled, but the flag itself remains set. For this scenario to occur, it is only necessary for IRQs to be enabled at some point during the complete callback. This happens with the USB Ethernet gadget, whose rx_complete() callback calls netif_rx(). If called in the task context, netif_rx() disables the bottom halves (BHs). Wh
rx_complete() callback calls netif_rx(). If called in the task context, netif_rx() disables the bottom halves (BHs). When the BHs are re-enabled, IRQs are also enabled to allow soft IRQs to be processed. The gadget itself is initialized at module load (or at boot if built-in), but the first request is enqueued when the network interface is brought up, triggering rx_complete() in the task context via ioctl(). If a packet arrives while the interface is down, it can prevent the interface from receiving any further packets from the USB host. The situation is quite complicated with many parties involved. This particular issue can be resolved in several possible ways: 1. Ensure that callbacks nev
with many parties involved. This particular issue can be resolved in several possible ways: 1. Ensure that callbacks never enable IRQs. This would be difficult to enforce, as discovering how netif_rx() interacts with interrupts was already quite challenging and u_ether is not the only function driver. Similar "bugs" could be hidden in other drivers as well. 2. Disable MUSB interrupts in musb_g_giveback() before calling the callback and re-enable them afterwars (by calling musb_{dis,en}able_interrupts(), for example). This would ensure that MUSB interrupts are not handled during the callback, even if IRQs are enabled. In fact, it would allow IRQs to be enabled when releasing the lock. However
ring the callback, even if IRQs are enabled. In fact, it would allow IRQs to be enabled when releasing the lock. However, this feels like an inelegant hack. 3. Modify the interrupt handler to clear the RXPKTRDY flag if the request queue is empty. While this approach also feels like a hack, it wastes CPU time by attempting to handle incoming packets when the software is not ready to process them. 4. Flush the Rx FIFO instead of calling rxstate() in musb_ep_restart(). This ensures that the hardware can receive packets when there is at least one request in the queue. Once I ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kern
-truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/c749500b28cae67410792096133ee7f282439c51 - https://git.kernel.org/stable/c/5906ee3693674d734177df13a519a21bb03f730d - https://git.kernel.org/stable/c/f05ad9755bb294328c3d0f429164ac6d4d08c548 - https://git.kernel.org/stable/c/0c89445e6d475b78d37b64ae520831cd43af7db4 - https://git.kernel.org/stable/c/3fc137386c4620305bbc2a216868c53f9245670a
CVE ID: CVE-2024-56688 State: PUBLISHED Published: 2024-12-28T09:46:14.905Z Last Updated: 2025-11-03T20:52:34.192Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport Since transport->sock has been set to NULL during reset transport, XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request() to dereference the transport->sock that has been set to NULL. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/cc91d59d34ff6a6fee1c0b48612081a
ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/cc91d59d34ff6a6fee1c0b48612081a451e05e9a - https://git.kernel.org/stable/c/86a1f9fa24804cd7f9d7dd3f24af84fc7f8ec02e - https://git.kernel.org/stable/c/fe6cbf0b2ac3cf4e21824a44eaa336564ed5e960 - https://git.kernel.org/stable/c/87a95ee34a48dfad198a2002e4966e1d63d53f2b - https://git.kernel.org/stable/c/3811172e8c98ceebd12fe526ca6cb37a1263c964 - https://git.kernel.org/stable/c/638a8fa5a7e641f9401346c57e236f02379a0c40 - https://git.kernel.org/stable/c/66d11ca91bf5100ae2e6b5efad97e58d8448843a - https://git.kernel.org/stable/c/4db9ad82a6c823094da27de4825af693a3475d51
CVE ID: CVE-2024-56689 State: PUBLISHED Published: 2024-12-28T09:46:15.587Z Last Updated: 2025-10-01T20:17:07.256Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio' If platform_get_resource_byname() fails and returns NULL because DT lacks an 'mmio' property for the MHI endpoint, dereferencing res->start will cause a NULL pointer access. Add a check to prevent it. [kwilczynski: error message update per the review feedback] [bhelgaas: commit log] Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/242ee2b0ad9b23f47084904fce
itional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/242ee2b0ad9b23f47084904fce3f9f228068a1f9 - https://git.kernel.org/stable/c/c8b9d6b7d62a444e0bca5b9ae28f9f2b0f52feef - https://git.kernel.org/stable/c/0e6d92e3b973de78eb7015154cf1197af9fac5c9 - https://git.kernel.org/stable/c/5089b3d874e9933d9842e90410d3af1520494757
CVE ID: CVE-2024-56690 State: PUBLISHED Published: 2024-12-28T09:46:16.246Z Last Updated: 2025-11-03T20:52:36.988Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATA_RESET"), the pcrypt encryption and decryption operations return -EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is generated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns -EAGAIN, the unnecessary panic will occur when panic_on_warn set 1. Fix this issue by calling crypto layer directly
rns -EAGAIN, the unnecessary panic will occur when panic_on_warn set 1. Fix this issue by calling crypto layer directly without parallelization in that case. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/dd8bf8eb5beba1e7c3b11a9a5a58ccbf345a69e6 - https://git.kernel.org/stable/c/fca8aed12218f96b38e374ff264d78ea1fbd23cc - https://git.kernel.org/stable/c/a92ccd3618e42333ac6f150ecdac14dca298bc7a - https://git.kernel.org/stable/c/96001f52ae8c70e2c736d3e1e5dc53d5b521e5ca - https://git.kernel.org/stable/c/92834692a539b5b7f409e467a14667d64713b732 - https://git.kernel.org/stable/c/5edae7a9a35606017ee6e05911c290acee9fee5a - https://git.kernel.org/stab
14667d64713b732 - https://git.kernel.org/stable/c/5edae7a9a35606017ee6e05911c290acee9fee5a - https://git.kernel.org/stable/c/a8e0074ffb38c9a5964a221bb998034d016c93a2 - https://git.kernel.org/stable/c/7ddab756f2de5b7b43c122ebebdf37f400fb2b6f - https://git.kernel.org/stable/c/662f2f13e66d3883b9238b0b96b17886179e60e2
CVE ID: CVE-2024-56691 State: PUBLISHED Published: 2024-12-28T09:46:16.892Z Last Updated: 2025-11-03T20:52:39.759Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them. Ad
driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/0997e77c51330c2866a4f39480e762cca92ad953 - https://git.kernel.org/stable/c/0b648968bfa4f5c9c4983bca9f2de17626ed6fb6 - https://git.kernel.org/stable/c/23230ac3c5ca3f154b64849d1cf50583b4e6b98c - https://git.kernel.org/stable/c/c310e6916c0b297011d0fec03f168a6b24e9e984 - https://git.kernel.org/stable/c/e1ef62e8d262e3f27446d26742208c1c81e9ee18 - https://git.kernel.org/stable/c/518e414d24e7037d6cc7198e942bf47fe6f5e8e1 - https://git.kernel.org/stable/c/87a07a5b0b296e489c606ca95ffc16c1882
/stable/c/518e414d24e7037d6cc7198e942bf47fe6f5e8e1 - https://git.kernel.org/stable/c/87a07a5b0b296e489c606ca95ffc16c18821975b - https://git.kernel.org/stable/c/686fb77712a4bc94b76a0c5ae74c60118b7a0d79
CVE ID: CVE-2024-56692 State: PUBLISHED Published: 2024-12-28T09:46:17.539Z Last Updated: 2025-10-01T20:07:08.292Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on node blkaddr in truncate_node() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2534! RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 Call Trace: truncate_node+0x1ae/0x8c0 fs/f2fs/node.c:909 f2fs_remove_inode_page+0x5c2/0x870 fs/f2fs/node.c:1288 f2fs_evict_inode+0x879/0x15c0 fs/f2fs/inode.c:856 evict+0x4e8/0x9b0 fs/inode.c:723 f2fs_handle_failed_inode+0x271/0x2e
8 f2fs_evict_inode+0x879/0x15c0 fs/f2fs/inode.c:856 evict+0x4e8/0x9b0 fs/inode.c:723 f2fs_handle_failed_inode+0x271/0x2e0 fs/f2fs/inode.c:986 f2fs_create+0x357/0x530 fs/f2fs/namei.c:394 lookup_open fs/namei.c:3595 [inline] open_last_lookups fs/namei.c:3694 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3930 do_filp_open+0x235/0x490 fs/namei.c:3960 do_sys_openat2+0x13e/0x1d0 fs/open.c:1415 do_sys_open fs/open.c:1430 [inline] __do_sys_openat fs/open.c:1446 [inline] __se_sys_openat fs/open.c:1441 [inline] __x64_sys_openat+0x247/0x2a0 fs/open.c:1441 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP:
/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 The root cause is: on a fuzzed image, blkaddr in nat entry may be corrupted, then it will cause system panic when using it in f2fs_invalidate_blocks(), to avoid this, let's add sanity check on nat blkaddr in truncate_node(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/27d6e7eff07f8cce8e83b162d8f21a07458c860d - https://git.kernel.org/stable/c/c1077078ce4589b5e5387f6b0aaa0d4534b9eb57 - https://git.kernel.org/stable/c/0a5c8b3fbf6200f1c66062d307c9a52084917788 - ht
c1077078ce4589b5e5387f6b0aaa0d4534b9eb57 - https://git.kernel.org/stable/c/0a5c8b3fbf6200f1c66062d307c9a52084917788 - https://git.kernel.org/stable/c/6babe00ccd34fc65b78ef8b99754e32b4385f23d
CVE ID: CVE-2024-56693 State: PUBLISHED Published: 2024-12-28T09:46:18.203Z Last Updated: 2025-11-03T20:52:41.179Z Vendors: Linux Products: Linux Description: 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: 00
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:__asan_load8+0x4c/0xa0 ... Call Trace: <TASK> blkdev_put_whole+0x41/0x70 bdev_release+0x1a3/0x250 blkdev_release+0x11/0x20 __fput+0x1d7/0x4a0 task_work_run+0xfc/0x180 syscall_exit_to_user_mode+0x1de/0x1f0 do_syscall_64+0x6b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e loop_init() is calling loop_add() after __register_blkdev() succeeds and is ignoring disk_add() failure from loop_add(), for loop_add() failure is not fatal and successfully created disks are already visible to bdev_open(). brd_init() is currently calling brd_alloc() before __register_blkdev() succeeds an
s are already visible to bdev_open(). brd_init() is currently calling brd_alloc() before __register_blkdev() succeeds and is releasing successfully created disks when brd_init() returns an error. This can cause UAF for the latter two case: case 1: T1: modprobe brd brd_init brd_alloc(0) // success add_disk disk_scan_partitions bdev_file_open_by_dev // alloc file fput // won't free until back to userspace brd_alloc(1) // failed since mem alloc error inject // error path for modprobe will release code segment // back to userspace __fput blkdev_release bdev_release blkdev_put_whole bdev->bd_disk->fops->release // fops is freed now, UAF! case 2: T1: T2: modprobe brd brd_init brd_alloc(0) // succe
hole bdev->bd_disk->fops->release // fops is freed now, UAF! case 2: T1: T2: modprobe brd brd_init brd_alloc(0) // success open(/dev/ram0) brd_alloc(1) // fail // error path for modprobe close(/dev/ram0) ... /* UAF! */ bdev->bd_disk->fops->release Fix this problem by following what loop_init() does. Besides, reintroduce brd_devices_mutex to help serialize modifications to brd_list. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/41219c147df8bbd6591f59af5d695fb6c9a1cbff - https://git.kernel.org/stable/c/259bf925583ec9e3781df778cadf00594095090d - https://git.kernel.org/stable/c/410896624db639500f24f46478b4bfa05c76bf56 -
c/259bf925583ec9e3781df778cadf00594095090d - https://git.kernel.org/stable/c/410896624db639500f24f46478b4bfa05c76bf56 - https://git.kernel.org/stable/c/c0c2744cd2939ec5999c51dbaf2af16886548b7b - https://git.kernel.org/stable/c/63dfd728b30f79495dacc886127695a379805152 - https://git.kernel.org/stable/c/826cc42adf44930a633d11a5993676d85ddb0842
CVE ID: CVE-2024-56694 State: PUBLISHED Published: 2024-12-28T09:46:18.826Z Last Updated: 2025-11-03T20:52:43.997Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: fix recursive lock when verdict program return SK_PASS When the stream_verdict program returns SK_PASS, it places the received skb into its own receive queue, but a recursive lock eventually occurs, leading to an operating system deadlock. This issue has been present since v6.9. ''' sk_psock_strp_data_ready write_lock_bh(&sk->sk_callback_lock) strp_data_ready strp_read_sock read_sock -> tcp_read_sock strp_recv cb.rcv_msg -> sk_psock_strp_read # now stream_verdict