Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
for user fonts. Note the later 'if' is now protected by 'old_userfont' and not 'old_data' as the latter is always set now. (And it is supposed to be non-NULL. Otherwise we would see the bug above again.) Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/20a4b5214f7bee13c897477168c77bbf79683c3d - https://git.kernel.org/stable/c/2f91a96b892fab2f2543b4a55740c5bee36b1a6b - https://git.kernel.org/stable/c/73a6bd68a1342f3a44cac9dffad81ad6a003e520 - https://git.kernel.org/stable/c/a2c881413dcc5d801bdc9535e51270cc88cb9cd8 - https://git.kernel.org/stable/c/00d6a284fcf3fad1b7e1b5bc3cd87cbfb60ce03f
CVE ID: CVE-2024-26799 State: PUBLISHED Published: 2024-04-04T08:20:27.888Z Last Updated: 2025-05-04T08:56:49.479Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix uninitialized pointer dmactl In the case where __lpass_get_dmactl_handle is called and the driver id dai_id is invalid the pointer dmactl is not being assigned a value, and dmactl contains a garbage value since it has not been initialized and so the null check may not work. Fix this to initialize dmactl to NULL. One could argue that modern compilers will set this to zero, but it is useful to keep this initialized as per the same way in functions __lpass
dern compilers will set this to zero, but it is useful to keep this initialized as per the same way in functions __lpass_platform_codec_intf_init and lpass_cdc_dma_daiops_hw_params. Cleans up clang scan build warning: sound/soc/qcom/lpass-cdc-dma.c:275:7: warning: Branch condition evaluates to a garbage value [core.uninitialized.Branch] Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/99adc8b4d2f38bf0d06483ec845bc48f60c3f8cf - https://git.kernel.org/stable/c/d5a7726e6ea62d447b79ab5baeb537ea6bdb225b - https://git.kernel.org/stable/c/1382d8b55129875b2e07c4d2a7ebc790183769ee
CVE ID: CVE-2024-26800 State: PUBLISHED Published: 2024-04-04T08:20:28.554Z Last Updated: 2025-05-04T12:54:45.649Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tls: fix use-after-free on failed backlog decryption When the decrypt request goes to the backlog and crypto_aead_decrypt returns -EBUSY, tls_do_decryption will wait until all async decryptions have completed. If one of them fails, tls_do_decryption will return -EBADMSG and tls_decrypt_sg jumps to the error path, releasing all the pages. But the pages have been passed to the async callback, and have already been released by tls_decrypt_done. The only true async case is
have been passed to the async callback, and have already been released by tls_decrypt_done. The only true async case is when crypto_aead_decrypt returns -EINPROGRESS. With -EBUSY, we already waited so we can tell tls_sw_recvmsg that the data is available for immediate copy, but we need to notify tls_decrypt_sg (via the new ->async_done flag) that the memory has already been released. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/f2b85a4cc763841843de693bbd7308fe9a2c4c89 - https://git.kernel.org/stable/c/81be85353b0f5a7b660635634b655329b429eefe - https://git.kernel.org/stable/c/1ac9fb84bc7ecd4bc6428118301d9d864d2a58d1
le/c/81be85353b0f5a7b660635634b655329b429eefe - https://git.kernel.org/stable/c/1ac9fb84bc7ecd4bc6428118301d9d864d2a58d1 - https://git.kernel.org/stable/c/13114dc5543069f7b97991e3b79937b6da05f5b0
CVE ID: CVE-2024-26801 State: PUBLISHED Published: 2024-04-04T08:20:29.211Z Last Updated: 2025-05-04T08:56:52.344Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Avoid potential use-after-free in hci_error_reset While handling the HCI_EV_HARDWARE_ERROR event, if the underlying BT controller is not responding, the GPIO reset mechanism would free the hci_dev and lead to a use-after-free in hci_error_reset. Here's the call trace observed on a ChromeOS device with Intel AX201: queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>] ? init_wait_entry+0x31/0x31 __hci_cmd_sync+0x16/0x20 [bluetooth <HA
hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>] ? init_wait_entry+0x31/0x31 __hci_cmd_sync+0x16/0x20 [bluetooth <HASH:3b4a 6>] hci_error_reset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>] process_one_work+0x1d8/0x33f worker_thread+0x21b/0x373 kthread+0x13a/0x152 ? pr_cont_work+0x54/0x54 ? kthread_blkcg+0x31/0x31 ret_from_fork+0x1f/0x30 This patch holds the reference count on the hci_dev while processing a HCI_EV_HARDWARE_ERROR event to avoid potential crash. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/e0b278650f07acf2e0932149183458468a731c03 - https://git.kernel.org/stable/c/98fb98fd37e42fd4ce13ff657ea64503e24b6090 - h
/e0b278650f07acf2e0932149183458468a731c03 - https://git.kernel.org/stable/c/98fb98fd37e42fd4ce13ff657ea64503e24b6090 - https://git.kernel.org/stable/c/6dd0a9dfa99f8990a08eb8fdd8e79bee31c7d8e2 - https://git.kernel.org/stable/c/da4569d450b193e39e87119fd316c0291b585d14 - https://git.kernel.org/stable/c/45085686b9559bfbe3a4f41d3d695a520668f5e1 - https://git.kernel.org/stable/c/2ab9a19d896f5a0dd386e1f001c5309bc35f433b - https://git.kernel.org/stable/c/dd594cdc24f2e48dab441732e6dfcafd6b0711d1 - https://git.kernel.org/stable/c/2449007d3f73b2842c9734f45f0aadb522daf592
CVE ID: CVE-2024-26802 State: PUBLISHED Published: 2024-04-04T08:20:29.919Z Last Updated: 2025-05-04T08:56:53.704Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: stmmac: Clear variable when destroying workqueue Currently when suspending driver and stopping workqueue it is checked whether workqueue is not NULL and if so, it is destroyed. Function destroy_workqueue() does drain queue and does clear variable, but it does not set workqueue variable to NULL. This can cause kernel/module panic if code attempts to clear workqueue that was not initialized. This scenario is possible when resuming suspended driver in stmmac_resume(), bec
ear workqueue that was not initialized. This scenario is possible when resuming suspended driver in stmmac_resume(), because there is no handling for failed stmmac_hw_setup(), which can fail and return if DMA engine has failed to initialize, and workqueue is initialized after DMA engine. Should DMA engine fail to initialize, resume will proceed normally, but interface won't work and TX queue will eventually timeout, causing 'Reset adapter' error. This then does destroy workqueue during reset process. And since workqueue is initialized after DMA engine and can be skipped, it will cause kernel/module panic. To secure against this possible crash, set workqueue variable to NULL when destroying w
will cause kernel/module panic. To secure against this possible crash, set workqueue variable to NULL when destroying workqueue. Log/backtrace from crash goes as follows: [88.031977]------------[ cut here ]------------ [88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out [88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398 <Skipping backtrace for watchdog timeout> [88.032251]---[ end trace e70de432e4d5c2c0 ]--- [88.032282]sxgmac 16d88000.ethernet eth0: Reset adapter. [88.036359]------------[ cut here ]------------ [88.036519]Call trace: [88.036523] flush_workqueue+0x3e4/0x430 [88.036528] drain_workqueue+0xc4/0x160 [88.036533] destroy_wor
36519]Call trace: [88.036523] flush_workqueue+0x3e4/0x430 [88.036528] drain_workqueue+0xc4/0x160 [88.036533] destroy_workqueue+0x40/0x270 [88.036537] stmmac_fpe_stop_wq+0x4c/0x70 [88.036541] stmmac_release+0x278/0x280 [88.036546] __dev_close_many+0xcc/0x158 [88.036551] dev_close_many+0xbc/0x190 [88.036555] dev_close.part.0+0x70/0xc0 [88.036560] dev_close+0x24/0x30 [88.036564] stmmac_service_task+0x110/0x140 [88.036569] process_one_work+0x1d8/0x4a0 [88.036573] worker_thread+0x54/0x408 [88.036578] kthread+0x164/0x170 [88.036583] ret_from_fork+0x10/0x20 [88.036588]---[ end trace e70de432e4d5c2c1 ]--- [88.036597]Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004
ce e70de432e4d5c2c1 ]--- [88.036597]Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/8e99556301172465c8fe33c7f78c39a3d4ce8462 - https://git.kernel.org/stable/c/17ccd9798fe0beda3db212cfa3ebe373f605cbd6 - https://git.kernel.org/stable/c/699b103e48ce32d03fc86c35b37ee8ae4288c7e3 - https://git.kernel.org/stable/c/f72cf22dccc94038cbbaa1029cb575bf52e5cbc8 - https://git.kernel.org/stable/c/8af411bbba1f457c33734795f024d0ef26d0963f
CVE ID: CVE-2024-26803 State: PUBLISHED Published: 2024-04-04T08:20:30.656Z Last Updated: 2025-05-04T08:56:55.180Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: veth: clear GRO when clearing XDP even when down veth sets NETIF_F_GRO automatically when XDP is enabled, because both features use the same NAPI machinery. The logic to clear NETIF_F_GRO sits in veth_disable_xdp() which is called both on ndo_stop and when XDP is turned off. To avoid the flag from being cleared when the device is brought down, the clearing is skipped when IFF_UP is not set. Bringing the device down should indeed not modify its features. Unfortunat
e clearing is skipped when IFF_UP is not set. Bringing the device down should indeed not modify its features. Unfortunately, this means that clearing is also skipped when XDP is disabled _while_ the device is down. And there's nothing on the open path to bring the device features back into sync. IOW if user enables XDP, disables it and then brings the device up we'll end up with a stray GRO flag set but no NAPI instances. We don't depend on the GRO flag on the datapath, so the datapath won't crash. We will crash (or hang), however, next time features are sync'ed (either by user via ethtool or peer changing its config). The GRO flag will go away, and veth will try to disable the NAPIs. But th
user via ethtool or peer changing its config). The GRO flag will go away, and veth will try to disable the NAPIs. But the open path never created them since XDP was off, the GRO flag was a stray. If NAPI was initialized before we'll hang in napi_disable(). If it never was we'll crash trying to stop uninitialized hrtimer. Move the GRO flag updates to the XDP enable / disable paths, instead of mixing them with the ndo_open / ndo_close paths. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f011c103e654d83dc85f057a7d1bd0960d02831c - https://git.kernel.org/stable/c/7985d73961bbb4e726c1be7b9cd26becc7be8325 - https://git.kern
3dc85f057a7d1bd0960d02831c - https://git.kernel.org/stable/c/7985d73961bbb4e726c1be7b9cd26becc7be8325 - https://git.kernel.org/stable/c/16edf51f33f52dff70ed455bc40a6cc443c04664 - https://git.kernel.org/stable/c/8f7a3894e58e6f5d5815533cfde60e3838947941 - https://git.kernel.org/stable/c/fe9f801355f0b47668419f30f1fac1cf4539e736
CVE ID: CVE-2024-26804 State: PUBLISHED Published: 2024-04-04T08:20:31.305Z Last Updated: 2025-05-04T12:54:46.707Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: prevent perpetual headroom growth syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissecto
_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/
x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ... The splat occurs because skb->data points past skb->head allocated area. Thi
rt_xmit+0x13d/0x6d0 net/core/dev.c:3564 ... The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb)); ... but skb_network_offset() returns a negative offset and __skb_pull() arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value. The negative value is returned because skb->head and skb->data distance is more than 64k and skb->network_header (u16) has wrapped around. The bug is in the ip_tunnel infrastructure, which can cause dev->needed_headroom to increment ad infinitum. The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets poin
The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device. This results in the following pattern: 1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0. 2). ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future output device, rt.dev->needed_headroom (ipip0). 3). ip output / start_xmit moves skb on to ipip0. which runs the same code path again (xmit recursion). 4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet. tunl0->needed_headroom
for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet. tunl0->needed_headroom is then incremented based on the (already bumped) gre0 device headroom. This repeats for every future packet: gre0->needed_headroom gets inflated because previous packets' ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 needed_headroom was increased. For each subsequent packet, gre/ipip0->needed_headroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k. Once that happens, skb->network_header (u16) wraps around when pskb_expand_head tries to make sure that skb_network_offset() is unchanged aft
b->network_header (u16) wraps around when pskb_expand_head tries to make sure that skb_network_offset() is unchanged after the headroom expansion/reallocation. After this skb_network_offset(skb) returns a different (and negative) result post headroom expansion. The next trip to neigh layer (or anything else that would __skb_pull the network header) makes skb->data point to a memory location outside skb->head area. v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/f81e9
nal Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/f81e94d2dcd2397137edcb8b85f4c5bed5d22383 - https://git.kernel.org/stable/c/2e95350fe9db9d53c701075060ac8ac883b68aee - https://git.kernel.org/stable/c/afec0c5cd2ed71ca95a8b36a5e6d03333bf34282 - https://git.kernel.org/stable/c/ab63de24ebea36fe73ac7121738595d704b66d96 - https://git.kernel.org/stable/c/a0a1db40b23e8ff86dea2786c5ea1470bb23ecb9 - https://git.kernel.org/stable/c/049d7989c67e8dd50f07a2096dbafdb41331fb9b - https://git.kernel.org/stable/c/5ae1e9922bbdbaeb9cfbe91085ab75927488ac0f
CVE ID: CVE-2024-26805 State: PUBLISHED Published: 2024-04-04T08:20:32.250Z Last Updated: 2025-05-04T12:54:47.795Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter syzbot reported the following uninit-value access issue [1]: netlink_to_full_skb() creates a new `skb` and puts the `skb->data` passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data size is specified as `len` and passed to skb_put_data(). This `len` is based on `skb->end` that is not data offset but buffer offset. The `skb->end` contains data and tailroom. Since the tailroom is not initializ
hat is not data offset but buffer offset. The `skb->end` contains data and tailroom. Since the tailroom is not initialized when the new `skb` created, KMSAN detects uninitialized memory area when copying the data. This patch resolved this issue by correct the len from `skb->end` to `skb->len`, which is the actual data offset. BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter
clude/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [inline] simple
v_iter.h:271 [inline] _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [inline] simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline] packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg net/socket.c:1066 [inline] sock_read_iter+0x467/0x580 net/socket.c:1136 call_read_iter include/linux/fs.h:2014 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0 fs/read_write.c:61
sync_read fs/read_write.c:389 [inline] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x93/0xd0 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was stored to memory at: skb_put_data include/linux/skbuff.h:2622 [inline] netlink_to_full_skb net/netlink/af_netlink.c:181 [inline] __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline] __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_n
tlink.c:298 [inline] __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 [inline] netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline] netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64
net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: free_pages_prepare mm/page_alloc.c:1087 [inline] free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533 release_pages+0x23d3/0x2410 mm/swap.c:1042 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316 tlb_batch_pages ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: Refe
e.c:316 tlb_batch_pages ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/ec343a55b687a452f5e87f3b52bf9f155864df65 - https://git.kernel.org/stable/c/9ae51361da43270f4ba0eb924427a07e87e48777 - https://git.kernel.org/stable/c/f19d1f98e60e68b11fc60839105dd02a30ec0d77 - https://git.kernel.org/stable/c/c71ed29d15b1a1ed6c464f8c3536996963046285 - https://git.kernel.org/stable/c/0b27bf4c494d61e5663baa34c3edd7ccebf0ea44 - https://git.kernel.org/stable/c/d3ada42e534a83b618bbc1e490d23bf0fdae4736 - https://git.kernel.org/stable/c/59fc3e3d049e39e7d0d271f20dd5fb47c57faf1d - https://git.kernel.org/stable/c/661779e1fcafe
https://git.kernel.org/stable/c/59fc3e3d049e39e7d0d271f20dd5fb47c57faf1d - https://git.kernel.org/stable/c/661779e1fcafe1b74b3f3fe8e980c1e207fea1fd
CVE ID: CVE-2024-26806 State: PUBLISHED Published: 2024-04-04T08:20:33.512Z Last Updated: 2025-05-04T08:56:58.797Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: spi: cadence-qspi: remove system-wide suspend helper calls from runtime PM hooks The ->runtime_suspend() and ->runtime_resume() callbacks are not expected to call spi_controller_suspend() and spi_controller_resume(). Remove calls to those in the cadence-qspi driver. Those helpers have two roles currently: - They stop/start the queue, including dealing with the kworker. - They toggle the SPI controller SPI_CONTROLLER_SUSPENDED flag. It requires acquiring ctlr->bus_lock_
with the kworker. - They toggle the SPI controller SPI_CONTROLLER_SUSPENDED flag. It requires acquiring ctlr->bus_lock_mutex. Step one is irrelevant because cadence-qspi is not queued. Step two however has two implications: - A deadlock occurs, because ->runtime_resume() is called in a context where the lock is already taken (in the ->exec_op() callback, where the usage count is incremented). - It would disallow all operations once the device is auto-suspended. Here is a brief call tree highlighting the mutex deadlock: spi_mem_exec_op() ... spi_mem_access_start() mutex_lock(&ctlr->bus_lock_mutex) cqspi_exec_mem_op() pm_runtime_resume_and_get() cqspi_resume() spi_controller_resume() mutex_lo