Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
e flushed in one shoot with SCALE#3 and NUM#31. The macro TLBI_RANGE_MASK is dropped since no one uses it any more. The comments are also adjusted accordingly. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/ac4ad513de4fba18b4ac0ace132777d0910e8cfa - https://git.kernel.org/stable/c/944db7b536baaf49d7e576af36a94f4719552b07 - https://git.kernel.org/stable/c/e3ba51ab24fddef79fc212f9840de54db8fd1685
CVE ID: CVE-2024-35981 State: PUBLISHED Published: 2024-05-20T09:42:05.722Z Last Updated: 2025-05-04T09:09:47.538Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: virtio_net: Do not send RSS key if it is not supported There is a bug when setting the RSS options in virtio_net that can break the whole machine, getting the kernel into an infinite loop. Running the following command in any QEMU virtual machine with virtionet will reproduce this problem: # ethtool -X eth0 hfunc toeplitz This is how the problem happens: 1) ethtool_set_rxfh() calls virtnet_set_rxfh() 2) virtnet_set_rxfh() calls virtnet_commit_rss_command() 3) virtnet_c
ns: 1) ethtool_set_rxfh() calls virtnet_set_rxfh() 2) virtnet_set_rxfh() calls virtnet_commit_rss_command() 3) virtnet_commit_rss_command() populates 4 entries for the rss scatter-gather 4) Since the command above does not have a key, then the last scatter-gatter entry will be zeroed, since rss_key_size == 0. sg_buf_size = vi->rss_key_size; 5) This buffer is passed to qemu, but qemu is not happy with a buffer with zero length, and do the following in virtqueue_map_desc() (QEMU function): if (!sz) { virtio_error(vdev, "virtio: zero sized buffers are not allowed"); 6) virtio_error() (also QEMU function) set the device as broken vdev->broken = true; 7) Qemu bails out, and do not repond this cra
error() (also QEMU function) set the device as broken vdev->broken = true; 7) Qemu bails out, and do not repond this crazy kernel. 8) The kernel is waiting for the response to come back (function virtnet_send_command()) 9) The kernel is waiting doing the following : while (!virtqueue_get_buf(vi->cvq, &tmp) && !virtqueue_is_broken(vi->cvq)) cpu_relax(); 10) None of the following functions above is true, thus, the kernel loops here forever. Keeping in mind that virtqueue_is_broken() does not look at the qemu `vdev->broken`, so, it never realizes that the vitio is broken at QEMU side. Fix it by not sending RSS commands if the feature is not available in the device. Additional Analyst Notes: - C
MU side. Fix it by not sending RSS commands if the feature is not available in the device. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/539a2b995a4ed93125cb0efae0f793b00ab2158b - https://git.kernel.org/stable/c/43a71c1b4b3a6d4db857b1435d271540279fc7de - https://git.kernel.org/stable/c/28e9a64638cd16bc1ecac9ff74ffeacb9fb652de - https://git.kernel.org/stable/c/059a49aa2e25c58f90b50151f109dd3c4cdb3a47
CVE ID: CVE-2024-35982 State: PUBLISHED Published: 2024-05-20T09:42:06.397Z Last Updated: 2025-05-04T09:09:48.633Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: batman-adv: Avoid infinite loop trying to resize local TT If the MTU of one of an attached interface becomes too small to transmit the local translation table then it must be resized to fit inside all fragments (when enabled) or a single packet. But if the MTU becomes too low to transmit even the header + the VLAN specific part then the resizing of the local TT will never succeed. This can for example happen when the usable space is 110 bytes and 11 VLANs are on top of
e local TT will never succeed. This can for example happen when the usable space is 110 bytes and 11 VLANs are on top of batman-adv. In this case, at least 116 byte would be needed. There will just be an endless spam of batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110) in the log but the function will never finish. Problem here is that the timeout will be halved all the time and will then stagnate at 0 and therefore never be able to reduce the table even more. There are other scenarios possible with a similar result. The number of BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too high to fit inside a packet. Such a scenario can
ATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too high to fit inside a packet. Such a scenario can therefore happen also with only a single VLAN + 7 non-purgable addresses - requiring at least 120 bytes. While this should be handled proactively when: * interface with too low MTU is added * VLAN is added * non-purgeable local mac is added * MTU of an attached interface is reduced * fragmentation setting gets disabled (which most likely requires dropping attached interfaces) not all of these scenarios can be prevented because batman-adv is only consuming events without the the possibility to prevent these actions (non-purgable MAC address added, MTU of an attached interfac
events without the the possibility to prevent these actions (non-purgable MAC address added, MTU of an attached interface is reduced). It is therefore necessary to also make sure that the code is able to handle also the situations when there were already incompatible system configuration are present. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/04720ea2e6c64459a90ca28570ea78335eccd924 - https://git.kernel.org/stable/c/b3ddf6904073990492454b1dd1c10a24be8c74c6 - https://git.kernel.org/stable/c/70a8be9dc2fb65d67f8c1e0c88c587e08e2e575d - https://git.kernel.org/stable/c/87b6af1a7683e021710c08fc0551fc078346032f - https://
9dc2fb65d67f8c1e0c88c587e08e2e575d - https://git.kernel.org/stable/c/87b6af1a7683e021710c08fc0551fc078346032f - https://git.kernel.org/stable/c/3fe79b2c83461edbbf86ed8a6f3924820ff89259 - https://git.kernel.org/stable/c/4ca2a5fb54ea2cc43edea614207fcede562d91c2 - https://git.kernel.org/stable/c/ca54e2671548616ad34885f90d4f26f7adb088f0 - https://git.kernel.org/stable/c/b1f532a3b1e6d2e5559c7ace49322922637a28aa
CVE ID: CVE-2024-35983 State: PUBLISHED Published: 2024-05-20T09:47:51.079Z Last Updated: 2025-05-04T12:56:10.604Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bounds: Use the right number of bits for power-of-two CONFIG_NR_CPUS bits_per() rounds up to the next power of two when passed a power of two. This causes crashes on some machines and configurations. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/d34a516f2635090d36a306f84573e8de3d7374ce - https://git.kernel.org/stable/c/66297b2ceda841f809637731d287bda3a93b49d8 - https://git.kernel.org/stable/c/9
e3d7374ce - https://git.kernel.org/stable/c/66297b2ceda841f809637731d287bda3a93b49d8 - https://git.kernel.org/stable/c/93ba36238db6a74a82feb3dc476e25ea424ad630 - https://git.kernel.org/stable/c/9b7c5004d7c5ae062134052a85290869a015814c - https://git.kernel.org/stable/c/15aa09d6d84629eb5296de30ac0aa19a33512f16 - https://git.kernel.org/stable/c/ebfe41889b762f1933c6762f6624b9724a25bee0 - https://git.kernel.org/stable/c/5af385f5f4cddf908f663974847a4083b2ff2c79
CVE ID: CVE-2024-35984 State: PUBLISHED Published: 2024-05-20T09:47:51.738Z Last Updated: 2025-05-04T09:09:50.767Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: fix NULL function pointer dereference Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in __i2c_transfer. [wsa: dropped the simplification in core-smbus to avoid theoretical regressions] Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stabl
] Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/40f1d79f07b49c8a64a861706e5163f2db4bd95d - https://git.kernel.org/stable/c/ad3c3ac7a03be3697114f781193dd3e9d97e6e23 - https://git.kernel.org/stable/c/5fd72404587d7db4acb2d241fd8c387afb0a7aec - https://git.kernel.org/stable/c/5a09eae9a7db597fe0c1fc91636205b4a25d2620 - https://git.kernel.org/stable/c/4e75e222d397c6752b229ed72fc4644c8c36ecde - https://git.kernel.org/stable/c/e3425674ff68dc521c57c6eabad0cbd20a027d85 - https://git.kernel.org/stable/c/357c64ef1ef39b1e7cd91ab6bdd304d043702c83 - https://git.kernel.org/stable/c/91811a31b68d3765b3065f4bb6d7d6d84a7cfc9f
CVE ID: CVE-2024-35985 State: PUBLISHED Published: 2024-05-20T09:47:52.389Z Last Updated: 2025-05-04T09:09:51.817Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sched/eevdf: Prevent vlag from going out of bounds in reweight_eevdf() It was possible to have pick_eevdf() return NULL, which then causes a NULL-deref. This turned out to be due to entity_eligible() returning falsely negative because of a s64 multiplcation overflow. Specifically, reweight_eevdf() computes the vlag without considering the limit placed upon vlag as update_entity_lag() does, and then the scaling multiplication (remember that weight is 20bit fixed point)
upon vlag as update_entity_lag() does, and then the scaling multiplication (remember that weight is 20bit fixed point) can overflow. This then leads to the new vruntime being weird which then causes the above entity_eligible() to go side-ways and claim nothing is eligible. Thus limit the range of vlag accordingly. All this was quite rare, but fatal when it does happen. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/470d347b14b0ecffa9b39cf8f644fa2351db3efb - https://git.kernel.org/stable/c/06f27e6d7bf0abf54488259ef36bbf0e1fccb35c - https://git.kernel.org/stable/c/1560d1f6eb6b398bddd80c16676776c0325fe5fe
CVE ID: CVE-2024-35986 State: PUBLISHED Published: 2024-05-20T09:47:53.074Z Last Updated: 2025-05-04T09:09:52.824Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: phy: ti: tusb1210: Resolve charger-det crash if charger psy is unregistered The power_supply frame-work is not really designed for there to be long living in kernel references to power_supply devices. Specifically unregistering a power_supply while some other code has a reference to it triggers a WARN in power_supply_unregister(): WARN_ON(atomic_dec_return(&psy->use_cnt)); Folllowed by the power_supply still getting removed and the backing data freed anyway, leaving th
eturn(&psy->use_cnt)); Folllowed by the power_supply still getting removed and the backing data freed anyway, leaving the tusb1210 charger-detect code with a dangling reference, resulting in a crash the next time tusb1210_get_online() is called. Fix this by only holding the reference in tusb1210_get_online() freeing it at the end of the function. Note this still leaves a theoretical race window, but it avoids the issue when manually rmmod-ing the charger chip driver during development. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/25b3498485ac281e5851700e33b97f12c9533fd8 - https://git.kernel.org/stable/c/73224a5d2180
https://git.kernel.org/stable/c/25b3498485ac281e5851700e33b97f12c9533fd8 - https://git.kernel.org/stable/c/73224a5d2180066c7fe05b4656647601ba08d588 - https://git.kernel.org/stable/c/9827caa5105fb16d1fae2e75c8d0e4662014b3ca - https://git.kernel.org/stable/c/bf6e4ee5c43690e4c5a8a057bbcd4ff986bed052
CVE ID: CVE-2024-35987 State: PUBLISHED Published: 2024-05-20T09:47:53.717Z Last Updated: 2025-05-04T09:09:58.905Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: riscv: Fix loading 64-bit NOMMU kernels past the start of RAM commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping") added logic to allow using RAM below the kernel load address. However, this does not work for NOMMU, where PAGE_OFFSET is fixed to the kernel load address. Since that range of memory corresponds to PFNs below ARCH_PFN_OFFSET, mm initialization runs off the beginning of mem_map and corrupts adjacent kernel memory. Fix this by restorin
FN_OFFSET, mm initialization runs off the beginning of mem_map and corrupts adjacent kernel memory. Fix this by restoring the previous behavior for NOMMU kernels. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/b008e327fa570aca210f98c817757649bae56694 - https://git.kernel.org/stable/c/ea6628e4e2353978af7e3b4ad4fdaab6149acf3d - https://git.kernel.org/stable/c/aea702dde7e9876fb00571a2602f25130847bf0f
CVE ID: CVE-2024-35988 State: PUBLISHED Published: 2024-05-20T09:47:54.391Z Last Updated: 2025-05-04T09:10:00.431Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: riscv: Fix TASK_SIZE on 64-bit NOMMU On NOMMU, userspace memory can come from anywhere in physical RAM. The current definition of TASK_SIZE is wrong if any RAM exists above 4G, causing spurious failures in the userspace access routines. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/04bf2e5f95c1a52e28a7567a507f926efe31c3b6 - https://git.kernel.org/stable/c/52e8a42b11078d2aad4b9ba96503d77c7299168
ble/c/04bf2e5f95c1a52e28a7567a507f926efe31c3b6 - https://git.kernel.org/stable/c/52e8a42b11078d2aad4b9ba96503d77c7299168b - https://git.kernel.org/stable/c/4201b8c8f2c32af321fb50867e68ac6c1cbed4be - https://git.kernel.org/stable/c/a0f0dbbb1bc49fa0de18e92c36492ff6d804cdaa - https://git.kernel.org/stable/c/efdcfa554b6eb228943ef1dd4d023c606be647d2 - https://git.kernel.org/stable/c/6065e736f82c817c9a597a31ee67f0ce4628e948
CVE ID: CVE-2024-35989 State: PUBLISHED Published: 2024-05-20T09:47:55.084Z Last Updated: 2025-05-04T09:10:01.608Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix oops during rmmod on single-CPU platforms During the removal of the idxd driver, registered offline callback is invoked as part of the clean up process. However, on systems with only one CPU online, no valid target is available to migrate the perf context, resulting in a kernel oops: BUG: unable to handle page fault for address: 000000000002a2b8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 1470e1067 P4D
00000000002a2b8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 1470e1067 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57 Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023 RIP: 0010:mutex_lock+0x2e/0x50 ... Call Trace: <TASK> __die+0x24/0x70 page_fault_oops+0x82/0x160 do_user_addr_fault+0x65/0x6b0 __pfx___rdmsr_safe_on_cpu+0x10/0x10 exc_page_fault+0x7d/0x170 asm_exc_page_fault+0x26/0x30 mutex_lock+0x2e/0x50 mutex_lock+0x1e/0x50 perf_pmu_migrate_context+0x87/0x1f0 perf_event_cpu_offline+0x76/0x90 [idxd] cpuhp_invoke_callback+0xa2/0x4f0 __pfx_per
0 perf_pmu_migrate_context+0x87/0x1f0 perf_event_cpu_offline+0x76/0x90 [idxd] cpuhp_invoke_callback+0xa2/0x4f0 __pfx_perf_event_cpu_offline+0x10/0x10 [idxd] cpuhp_thread_fun+0x98/0x150 smpboot_thread_fn+0x27/0x260 smpboot_thread_fn+0x1af/0x260 __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x103/0x140 __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 <TASK> Fix the issue by preventing the migration of the perf context to an invalid target. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/9edd3aa34d50f27b97be30b2ba4a6af0945ff56b - https://git.kernel.org/stable/c/023b6390a15a98
ttps://git.kernel.org/stable/c/9edd3aa34d50f27b97be30b2ba4a6af0945ff56b - https://git.kernel.org/stable/c/023b6390a15a98f9c3aa5e7da78d485d5384a08e - https://git.kernel.org/stable/c/f976eca36cdf94e32fa4f865db0e7c427c9aa33c - https://git.kernel.org/stable/c/47533176fdcef17b114a6f688bc872901c1ec6bb - https://git.kernel.org/stable/c/f221033f5c24659dc6ad7e5cf18fb1b075f4a8be
CVE ID: CVE-2024-35990 State: PUBLISHED Published: 2024-05-20T09:47:55.736Z Last Updated: 2025-05-04T09:10:02.814Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dma: xilinx_dpdma: Fix locking There are several places where either chan->lock or chan->vchan.lock was not held. Add appropriate locking. This fixes lockdep warnings like [ 31.077578] ------------[ cut here ]------------ [ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.077953] Modules linked in: [ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98 [ 31.078102] Hardware na
953] Modules linked in: [ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98 [ 31.078102] Hardware name: xlnx,zynqmp (DT) [ 31.078169] Workqueue: events_unbound deferred_probe_work_func [ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0 [ 31.078550] sp : ffffffc083bb2e10 [ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168 [ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480 [ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000 [ 31.079132] x20: ff
24: ffffff880164d480 [ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000 [ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000 [ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001 [ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def [ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516 [ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff [ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000 [ 31.080307] Call trace: [ 31.080340] xilinx_dp
80147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000 [ 31.080307] Call trace: [ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120 [ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac [ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c [ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684 [ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0 [ 31.081139] commit_tail+0x234/0x294 [ 31.081246] drm_atomic_helper_commit+0x1f8/0x210 [ 31.081363] drm_atomic_commit+0x100/0x140 [ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384 [ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c [ 31.081725] drm_client_modes
modeset_commit_atomic+0x318/0x384 [ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c [ 31.081725] drm_client_modeset_commit+0x34/0x5c [ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168 [ 31.081899] drm_fb_helper_set_par+0x50/0x70 [ 31.081971] fbcon_init+0x538/0xc48 [ 31.082047] visual_init+0x16c/0x23c [ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634 [ 31.082320] do_take_over_console+0x24c/0x33c [ 31.082429] do_fbcon_takeover+0xbc/0x1b0 [ 31.082503] fbcon_fb_registered+0x2d0/0x34c [ 31.082663] register_framebuffer+0x27c/0x38c [ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c [ 31.082939] drm_fb_helper_initial_config+0x50/0x74 [ 31.083012] drm_fbdev_d
elper_initial_config_and_unlock+0x5c0/0x91c [ 31.082939] drm_fb_helper_initial_config+0x50/0x74 [ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108 [ 31.083115] drm_client_register+0xa0/0xf4 [ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc [ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0 [ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0 [ 31.083616] platform_probe+0x8c/0x13c [ 31.083713] really_probe+0x258/0x59c [ 31.083793] __driver_probe_device+0xc4/0x224 [ 31.083878] driver_probe_device+0x70/0x1c0 [ 31.083961] __device_attach_driver+0x108/0x1e0 [ 31.084052] bus_for_each_drv+0x9c/0x100 [ 31.084125] __device_attach+0x100/0x298 [ 31.084207] device_initial_probe+0x14/0x20 [ 31.084292] bus_probe_device+0x
00 [ 31.084125] __device_attach+0x100/0x298 [ 31.084207] device_initial_probe+0x14/0x20 [ 31.084292] bus_probe_device+0xd8/0xdc [ 31.084368] deferred_probe_work_func+0x11c/0x180 [ 31.084451] process_one_work+0x3ac/0x988 [ 31.084643] worker_thread+0x398/0x694 [ 31.084752] kthread+0x1bc/0x1c0 [ 31.084848] ret_from_fork+0x10/0x20 [ 31.084932] irq event stamp: 64549 [ 31.084970] hardirqs last enabled at (64548): [<ffffffc081adf35c>] _raw_spin_unlock_irqrestore+0x80/0x90 [ 31.085157] ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/fcdd5bb4a8c81c64c1334d7e0aba41a8829a24de - https://git.kernel.org/stable/c/0cc
rences: - https://git.kernel.org/stable/c/fcdd5bb4a8c81c64c1334d7e0aba41a8829a24de - https://git.kernel.org/stable/c/0ccac964520a6f19e355652c8ca38af2a7f27076 - https://git.kernel.org/stable/c/8bf574183282d219cfa991f7df37aad491d74c11 - https://git.kernel.org/stable/c/8e3c94767cad5150198e4337c8b91f3bb068e14b - https://git.kernel.org/stable/c/c660be571609e03e7d5972343536a736fcb31557 - https://git.kernel.org/stable/c/244296cc3a155199a8b080d19e645d7d49081a38
CVE ID: CVE-2024-35991 State: PUBLISHED Published: 2024-05-20T09:47:56.401Z Last Updated: 2025-05-04T09:10:03.849Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue drain_workqueue() cannot be called safely in a spinlocked context due to possible task rescheduling. In the multi-task scenario, calling queue_work() while drain_workqueue() will lead to a Call Trace as pushing a work on a draining workqueue is not permitted in spinlocked context. Call Trace: <TASK> ? __warn+0x7d/0x140 ? __queue_work+0x2b2/0x440 ? report_bug+0x1f8/0x200 ? handle_bug+0x3c/0x70 ? exc_invali
race: <TASK> ? __warn+0x7d/0x140 ? __queue_work+0x2b2/0x440 ? report_bug+0x1f8/0x200 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? __queue_work+0x2b2/0x440 queue_work_on+0x28/0x30 idxd_misc_thread+0x303/0x5a0 [idxd] ? __schedule+0x369/0xb40 ? __pfx_irq_thread_fn+0x10/0x10 ? irq_thread+0xbc/0x1b0 irq_thread_fn+0x21/0x70 irq_thread+0x102/0x1b0 ? preempt_count_add+0x74/0xa0 ? __pfx_irq_thread_dtor+0x10/0x10 ? __pfx_irq_thread+0x10/0x10 kthread+0x103/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> The current implementation uses a spinlock to protect event log workqueue and will lead to the
ork_asm+0x1b/0x30 </TASK> The current implementation uses a spinlock to protect event log workqueue and will lead to the Call Trace due to potential task rescheduling. To address the locking issue, convert the spinlock to mutex, allowing the drain_workqueue() to be called in a safe mutex-locked context. This change ensures proper synchronization when accessing the event log workqueue, preventing potential Call Trace and improving the overall robustness of the code. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/758071a35d9f3ffd84ff12169d081412a2f5f098 - https://git.kernel.org/stable/c/c9b732a9f73eadc638abdcf0a6d39bc7a
rg/stable/c/758071a35d9f3ffd84ff12169d081412a2f5f098 - https://git.kernel.org/stable/c/c9b732a9f73eadc638abdcf0a6d39bc7a0c1af5f - https://git.kernel.org/stable/c/d5638de827cff0fce77007e426ec0ffdedf68a44