Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-38297 State: PUBLISHED Published: 2025-07-10T07:42:10.918Z Last Updated: 2025-07-28T04:17:50.092Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PM: EM: Fix potential division-by-zero error in em_compute_costs() When the device is of a non-CPU type, table[i].performance won't be initialized in the previous em_init_performance(), resulting in division by zero when calculating costs in em_compute_costs(). Since the 'cost' algorithm is only used for EAS energy efficiency calculations and is currently not utilized by other device drivers, we should add the _is_cpu_device(dev) check to prevent this division-by-zero
ntly not utilized by other device drivers, we should add the _is_cpu_device(dev) check to prevent this division-by-zero issue. References: - https://git.kernel.org/stable/c/81d72f9241d884ec29524431f74f8009310cfa0c - https://git.kernel.org/stable/c/14cbdd64f3870cf0a2d94b87919b9056448c59a0 - https://git.kernel.org/stable/c/179c0c7044a378198adb36f2a12410ab68cc730a
CVE ID: CVE-2025-38298 State: PUBLISHED Published: 2025-07-10T07:42:11.553Z Last Updated: 2025-11-03T17:36:19.762Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: EDAC/skx_common: Fix general protection fault After loading i10nm_edac (which automatically loads skx_edac_common), if unload only i10nm_edac, then reload it and perform error injection testing, a general protection fault may occur: mce: [Hardware Error]: Machine check events logged Oops: general protection fault ... ... Workqueue: events mce_gen_pool_process RIP: 0010:string+0x53/0xe0 ... Call Trace: <TASK> ? die_addr+0x37/0x90 ? exc_general_protection+0x1e7/0x3f0 ? a
_process RIP: 0010:string+0x53/0xe0 ... Call Trace: <TASK> ? die_addr+0x37/0x90 ? exc_general_protection+0x1e7/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? string+0x53/0xe0 vsnprintf+0x23e/0x4c0 snprintf+0x4d/0x70 skx_adxl_decode+0x16a/0x330 [skx_edac_common] skx_mce_check_error.part.0+0xf8/0x220 [skx_edac_common] skx_mce_check_error+0x17/0x20 [skx_edac_common] ... The issue arose was because the variable 'adxl_component_count' (inside skx_edac_common), which counts the ADXL components, was not reset. During the reloading of i10nm_edac, the count was incremented by the actual number of ADXL components again, resulting in a count that was double the real number of ADXL components. This led
tual number of ADXL components again, resulting in a count that was double the real number of ADXL components. This led to an out-of-bounds reference to the ADXL component array, causing the general protection fault above. Fix this issue by resetting the 'adxl_component_count' in adxl_put(), which is called during the unloading of {skx,i10nm}_edac. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/80bf28fd623d97dd4f4825fbbe9d736cec2afba3 - https://git.kernel.org/stable/c/a6ed3a6edff09c1187cc6ade7f5967bca2376a13 - https://git.kernel.org/stable/c/bf6a8502a5f4ff6e4d135d795945cdade49ec8b0 - https://git.kernel.org/stable/c/e8530ed3c0769a4d8f79c212715
rnel.org/stable/c/bf6a8502a5f4ff6e4d135d795945cdade49ec8b0 - https://git.kernel.org/stable/c/e8530ed3c0769a4d8f79c212715ec1cf277787f8 - https://git.kernel.org/stable/c/3f5d0659000923735350da60ad710f8c804544fe - https://git.kernel.org/stable/c/a13e8343ffcff27af1ff79597ff7ba241e6d9471 - https://git.kernel.org/stable/c/31ef6f7c9aee3be78d63789653e92350f2537f93 - https://git.kernel.org/stable/c/20d2d476b3ae18041be423671a8637ed5ffd6958
CVE ID: CVE-2025-38299 State: PUBLISHED Published: 2025-07-10T07:42:12.216Z Last Updated: 2025-07-28T04:17:53.157Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8195: Set ETDM1/2 IN/OUT to COMP_DUMMY() ETDM2_IN_BE and ETDM1_OUT_BE are defined as COMP_EMPTY(), in the case the codec dai_name will be null. Avoid a crash if the device tree is not assigning a codec to these links. [ 1.179936] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 1.181065] Mem abort info: [ 1.181420] ESR = 0x0000000096000004 [ 1.181892] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.182576] SET = 0,
t info: [ 1.181420] ESR = 0x0000000096000004 [ 1.181892] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.182576] SET = 0, FnV = 0 [ 1.182964] EA = 0, S1PTW = 0 [ 1.183367] FSC = 0x04: level 0 translation fault [ 1.183983] Data abort info: [ 1.184406] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1.185097] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1.185766] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1.186439] [0000000000000000] user address but active_mm is swapper [ 1.187239] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 1.188029] Modules linked in: [ 1.188420] CPU: 7 UID: 0 PID: 70 Comm: kworker/u32:1 Not tainted 6.14.0-rc4-next-20250226+ #85 [ 1.189515] Hardware name: Radxa N
] CPU: 7 UID: 0 PID: 70 Comm: kworker/u32:1 Not tainted 6.14.0-rc4-next-20250226+ #85 [ 1.189515] Hardware name: Radxa NIO 12L (DT) [ 1.190065] Workqueue: events_unbound deferred_probe_work_func [ 1.190808] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.191683] pc : __pi_strcmp+0x24/0x140 [ 1.192170] lr : mt8195_mt6359_soc_card_probe+0x224/0x7b0 [ 1.192854] sp : ffff800083473970 [ 1.193271] x29: ffff800083473a10 x28: 0000000000001008 x27: 0000000000000002 [ 1.194168] x26: ffff800082408960 x25: ffff800082417db0 x24: ffff800082417d88 [ 1.195065] x23: 000000000000001e x22: ffff800082dbf480 x21: ffff800082dc07b8 [ 1.195961] x20: 0000000000000000 x19: 0000000000000013 x18: 00
00000000001e x22: ffff800082dbf480 x21: ffff800082dc07b8 [ 1.195961] x20: 0000000000000000 x19: 0000000000000013 x18: 00000000ffffffff [ 1.196858] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000006 [ 1.197755] x14: ffff800082407af0 x13: 6e6f69737265766e x12: 692d6b636f6c6374 [ 1.198651] x11: 0000000000000002 x10: ffff80008240b920 x9 : 0000000000000018 [ 1.199547] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000 [ 1.200443] x5 : 0000000000000000 x4 : 8080808080000000 x3 : 303933383978616d [ 1.201339] x2 : 0000000000000000 x1 : ffff80008240b920 x0 : 0000000000000000 [ 1.202236] Call trace: [ 1.202545] __pi_strcmp+0x24/0x140 (P) [ 1.203029] mtk_soundcard_common_p
x0 : 0000000000000000 [ 1.202236] Call trace: [ 1.202545] __pi_strcmp+0x24/0x140 (P) [ 1.203029] mtk_soundcard_common_probe+0x3bc/0x5b8 [ 1.203644] platform_probe+0x70/0xe8 [ 1.204106] really_probe+0xc8/0x3a0 [ 1.204556] __driver_probe_device+0x84/0x160 [ 1.205104] driver_probe_device+0x44/0x130 [ 1.205630] __device_attach_driver+0xc4/0x170 [ 1.206189] bus_for_each_drv+0x8c/0xf8 [ 1.206672] __device_attach+0xa8/0x1c8 [ 1.207155] device_initial_probe+0x1c/0x30 [ 1.207681] bus_probe_device+0xb0/0xc0 [ 1.208165] deferred_probe_work_func+0xa4/0x100 [ 1.208747] process_one_work+0x158/0x3e0 [ 1.209254] worker_thread+0x2c4/0x3e8 [ 1.209727] kthread+0x134/0x1f0 [ 1.210136] ret_from_fork+0x10/0x20 [
+0x158/0x3e0 [ 1.209254] worker_thread+0x2c4/0x3e8 [ 1.209727] kthread+0x134/0x1f0 [ 1.210136] ret_from_fork+0x10/0x20 [ 1.210589] Code: 54000401 b50002c6 d503201f f86a6803 (f8408402) [ 1.211355] ---[ end trace 0000000000000000 ]--- References: - https://git.kernel.org/stable/c/87dbfe2b392df9621f6e522e5fa6fb8849ca92ab - https://git.kernel.org/stable/c/183e7329d41d7a8e298f48b6b0eb81102a8654de - https://git.kernel.org/stable/c/7af317f7faaab09d5a78f24605057d11f5955115
CVE ID: CVE-2025-38300 State: PUBLISHED Published: 2025-07-10T07:42:12.826Z Last Updated: 2025-11-03T17:36:20.735Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare() Fix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare(): 1] If dma_map_sg() fails for areq->dst, the device driver would try to free DMA memory it has not allocated in the first place. To fix this, on the "theend_sgs" error path, call dma unmap only if the corresponding dma map was successful. 2] If the dma_map_single() call for the IV fails, the device driver would try to free
esponding dma map was successful. 2] If the dma_map_single() call for the IV fails, the device driver would try to free an invalid DMA memory address on the "theend_iv" path: ------------[ cut here ]------------ DMA-API: sun8i-ce 1904000.crypto: device driver tries to free an invalid DMA memory address WARNING: CPU: 2 PID: 69 at kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90 Modules linked in: skcipher_example(O+) CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: G O 6.15.0-rc3+ #24 PREEMPT Tainted: [O]=OOT_MODULE Hardware name: OrangePi Zero2 (DT) pc : check_unmap+0x123c/0x1b90 lr : check_unmap+0x123c/0x1b90 ... Call trace: check_unmap+0x123c/0x1b90 (P) debug_dma_unmap_page+0xac/0xc0 d
23c/0x1b90 lr : check_unmap+0x123c/0x1b90 ... Call trace: check_unmap+0x123c/0x1b90 (P) debug_dma_unmap_page+0xac/0xc0 dma_unmap_page_attrs+0x1f4/0x5fc sun8i_ce_cipher_do_one+0x1bd4/0x1f40 crypto_pump_work+0x334/0x6e0 kthread_worker_fn+0x21c/0x438 kthread+0x374/0x664 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- To fix this, check for !dma_mapping_error() before calling dma_unmap_single() on the "theend_iv" path. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a0ac3f85b2e3ef529e852f252a70311f9029d5e6 - https://git.kernel.org/stable/c/c62b79c1c51303dbcb6edfa4de0ee176f4934c52 - https://git.kernel.org/stable/c/19d267d9fad00d94ad847
git.kernel.org/stable/c/c62b79c1c51303dbcb6edfa4de0ee176f4934c52 - https://git.kernel.org/stable/c/19d267d9fad00d94ad8477899e38ed7c11f33fb6 - https://git.kernel.org/stable/c/4051250e5db489f8ad65fc337e2677b9b568ac72 - https://git.kernel.org/stable/c/f31adc3e356f7350d4a4d68c98d3f60f2f6e26b3
CVE ID: CVE-2025-38301 State: PUBLISHED Published: 2025-07-10T07:42:13.455Z Last Updated: 2025-07-28T04:18:00.922Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nvmem: zynqmp_nvmem: unbreak driver after cleanup Commit 29be47fcd6a0 ("nvmem: zynqmp_nvmem: zynqmp_nvmem_probe cleanup") changed the driver to expect the device pointer to be passed as the "context", but in nvmem the context parameter comes from nvmem_config.priv which is never set - Leading to null pointer exceptions when the device is accessed. References: - https://git.kernel.org/stable/c/c8bb1bcea877446f86922a8fd1661b8c07d90e5c - https://git.kernel.org/stable/c/37
erences: - https://git.kernel.org/stable/c/c8bb1bcea877446f86922a8fd1661b8c07d90e5c - https://git.kernel.org/stable/c/3728101f56ef54425a11027a3ddc2c3941d60b71 - https://git.kernel.org/stable/c/fe8abdd175d7b547ae1a612757e7902bcd62e9cf
CVE ID: CVE-2025-38302 State: PUBLISHED Published: 2025-07-10T07:42:14.076Z Last Updated: 2025-07-28T04:18:02.625Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: block: don't use submit_bio_noacct_nocheck in blk_zone_wplug_bio_work Bios queued up in the zone write plug have already gone through all all preparation in the submit_bio path, including the freeze protection. Submitting them through submit_bio_noacct_nocheck duplicates the work and can can cause deadlocks when freezing a queue with pending bio write plugs. Go straight to ->submit_bio or blk_mq_submit_bio to bypass the superfluous extra freeze protection and checks. R
plugs. Go straight to ->submit_bio or blk_mq_submit_bio to bypass the superfluous extra freeze protection and checks. References: - https://git.kernel.org/stable/c/0fccb6773b1f4f992e435582cf8e050de421b678 - https://git.kernel.org/stable/c/6ffae5d53f704d300cc73b06b4ea99e4507f7cf1 - https://git.kernel.org/stable/c/cf625013d8741c01407bbb4a60c111b61b9fa69d
CVE ID: CVE-2025-38303 State: PUBLISHED Published: 2025-07-10T07:42:14.728Z Last Updated: 2025-07-28T04:18:04.131Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: eir: Fix possible crashes on eir_create_adv_data eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER without checking if that would fit. References: - https://git.kernel.org/stable/c/2af40d795d3fb0ee5c074b7ac56ab22402aa6e4f - https://git.kernel.org/stable/c/b9db0c27e73b7c8a19384a44af527edfda74ff3d - https://git.kernel.org/stable/c/47c03902269aff377f959dc3fd94a9733aa31d6e
CVE ID: CVE-2025-38304 State: PUBLISHED Published: 2025-07-10T07:42:15.466Z Last Updated: 2025-11-03T17:36:21.665Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix NULL pointer deference on eir_get_service_data The len parameter is considered optional so it can be NULL so it cannot be used for skipping to next entry of EIR_SERVICE_DATA. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/497c9d2d7d3983826bb02c10fb4a5818be6550fb - https://git.kernel.org/stable/c/4bf29910570666e668a60d953f8da78e95bb7fa2 - https://git.kernel.org/stable/c/842f7c3154d5b25ca11753c02ee8cf6ee64c
stable/c/4bf29910570666e668a60d953f8da78e95bb7fa2 - https://git.kernel.org/stable/c/842f7c3154d5b25ca11753c02ee8cf6ee64c0142 - https://git.kernel.org/stable/c/7d99cc0f8e6fa0f35570887899f178122a61d44e - https://git.kernel.org/stable/c/20a2aa01f5aeb6daad9aeaa7c33dd512c58d81eb
CVE ID: CVE-2025-38305 State: PUBLISHED Published: 2025-07-10T07:42:16.127Z Last Updated: 2025-11-03T17:36:22.602Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use() There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use. However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store(). ============================================ WARNING: possible recursive locking detected 6.15.0-rc6 #1
clocks_store(). ============================================ WARNING: possible recursive locking detected 6.15.0-rc6 #1 Not tainted -------------------------------------------- syz.0.1540/13807 is trying to acquire lock: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415 but task is already holding lock: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ptp->n_vclock
tp_sysfs.c:215 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux); *** DEADLOCK *** .... ============================================ The best way to solve this is to remove the logic that checks ptp->n_vclocks in ptp_vclock_in_use(). The reason why this is appropriate is that any path that uses ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater than 0 before unregistering vclocks, and all functions are already written this way. And in the function that uses ptp->n_vclocks, we already get ptp->n_vclocks_mux before unregistering vclocks. Therefore, we need to remove the redundant check
locks, we already get ptp->n_vclocks_mux before unregistering vclocks. Therefore, we need to remove the redundant check for ptp->n_vclocks in ptp_vclock_in_use() to prevent recursive locking. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/5d217e7031a5c06d366580fc6ddbf43527b780d4 - https://git.kernel.org/stable/c/b1b73c452331451020be3bf4b014901015ae6663 - https://git.kernel.org/stable/c/259119595227fd20f6aa29d85abe086b6fdd9eb1 - https://git.kernel.org/stable/c/b93e6fef4eda48e17d9c642b9abad98a066fd4a3 - https://git.kernel.org/stable/c/ef8fc007c28a30a4c0d90bf755e0f343d99bb392 - https://git.kernel.org/stable/c/87f7ce260a3c838b49e1dc1ceedf10067951
stable/c/ef8fc007c28a30a4c0d90bf755e0f343d99bb392 - https://git.kernel.org/stable/c/87f7ce260a3c838b49e1dc1ceedf1006795157a2
CVE ID: CVE-2025-38306 State: PUBLISHED Published: 2025-07-10T07:42:16.806Z Last Updated: 2025-09-09T17:06:11.491Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs/fhandle.c: fix a race in call of has_locked_children() may_decode_fh() is calling has_locked_children() while holding no locks. That's an oopsable race... The rest of the callers are safe since they are holding namespace_sem and are guaranteed a positive refcount on the mount in question. Rename the current has_locked_children() to __has_locked_children(), make it static and switch the fs/namespace.c users to it. Make has_locked_children() a wrapper for __has_locked
ldren(), make it static and switch the fs/namespace.c users to it. Make has_locked_children() a wrapper for __has_locked_children(), calling the latter under read_seqlock_excl(&mount_lock). References: - https://git.kernel.org/stable/c/6482c3dccbfb8d20e2856ce67c75856859930b3f - https://git.kernel.org/stable/c/287c7d34eedd37af1272dfb3b6e8656f4f026424 - https://git.kernel.org/stable/c/1f282cdc1d219c4a557f7009e81bc792820d9d9a
CVE ID: CVE-2025-38307 State: PUBLISHED Published: 2025-07-10T07:42:17.427Z Last Updated: 2025-07-28T04:18:10.079Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Verify content returned by parse_int_array() The first element of the returned array stores its length. If it is 0, any manipulation beyond the element at index 0 ends with null-ptr-deref. References: - https://git.kernel.org/stable/c/cc03c899e6d9812b25c3754c9a95c3830c4aec26 - https://git.kernel.org/stable/c/18ff538aac63de1866e5a49d57e22788b5c21d12 - https://git.kernel.org/stable/c/2916794ffbce604cc2cda105f6b8a4a7c748dd7f - https://git.kernel.org/stab
7e22788b5c21d12 - https://git.kernel.org/stable/c/2916794ffbce604cc2cda105f6b8a4a7c748dd7f - https://git.kernel.org/stable/c/93e246b6769bdacb09cfff4ea0f00fe5ab4f0d7a
CVE ID: CVE-2025-38308 State: PUBLISHED Published: 2025-07-10T07:42:18.085Z Last Updated: 2025-07-28T04:18:11.425Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Fix possible null-ptr-deref when initing hw Search result of avs_dai_find_path_template() shall be verified before being used. As 'template' is already known when avs_hw_constraints_init() is fired, drop the search entirely. References: - https://git.kernel.org/stable/c/ea218ae05e60616531fe652650b98dcd3c328279 - https://git.kernel.org/stable/c/2f78724d4f0c665c83e202e3989d5333a2cb1036
CVE ID: CVE-2025-38309 State: PUBLISHED Published: 2025-07-10T07:42:18.701Z Last Updated: 2025-07-28T04:18:12.942Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: move xe_svm_init() earlier In xe_vm_close_and_put() we need to be able to call xe_svm_fini(), however during vm creation we can call this on the error path, before having actually initialised the svm state, leading to various splats followed by a fatal NPD. (cherry picked from commit 4f296d77cf49fcb5f90b4674123ad7f3a0676165) References: - https://git.kernel.org/stable/c/f5e6a6a8aa46d44ec7a240766cf3b7dd077718b9 - https://git.kernel.org/stable/c/8cf8cde41ad011
ttps://git.kernel.org/stable/c/f5e6a6a8aa46d44ec7a240766cf3b7dd077718b9 - https://git.kernel.org/stable/c/8cf8cde41ad01150afbd1327ad1942387787f7fd
CVE ID: CVE-2025-38310 State: PUBLISHED Published: 2025-07-10T07:42:19.338Z Last Updated: 2025-11-03T17:36:23.610Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: seg6: Fix validation of nexthop addresses The kernel currently validates that the length of the provided nexthop address does not exceed the specified length. This can lead to the kernel reading uninitialized memory if user space provided a shorter length than the specified one. Fix by validating that the provided length exactly matches the specified one. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/668923c474608dd9eb
one. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/668923c474608dd9ebce0fbcc41bd8a27aa73dd6 - https://git.kernel.org/stable/c/cef33a86bcb04ecf4dc10c56f6c42ee9d1c54bac - https://git.kernel.org/stable/c/d2507aeea45b3c5aa24d5daae0cf3db76895c0b7 - https://git.kernel.org/stable/c/d5d9fd13bc19a3f9f2a951c5b6e934d84205789e - https://git.kernel.org/stable/c/cd4cd09810211fa23609c5c1018352e9e1cd8e5a - https://git.kernel.org/stable/c/7632fedb266d93ed0ed9f487133e6c6314a9b2d1
CVE ID: CVE-2025-38311 State: PUBLISHED Published: 2025-07-10T07:42:20.006Z Last Updated: 2025-07-28T04:18:15.601Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iavf: get rid of the crit lock Get rid of the crit lock. That frees us from the error prone logic of try_locks. Thanks to netdev_lock() by Jakub it is now easy, and in most cases we were protected by it already - replace crit lock by netdev lock when it was not the case. Lockdep reports that we should cancel the work under crit_lock [splat1], and that was the scheme we have mostly followed since [1] by Slawomir. But when that is done we still got into deadlocks [splat2
was the scheme we have mostly followed since [1] by Slawomir. But when that is done we still got into deadlocks [splat2]. So instead we should look at the bigger problem, namely "weird locking/scheduling" of the iavf. The first step to fix that is to remove the crit lock. I will followup with a -next series that simplifies scheduling/tasks. Cancel the work without netdev lock (weird unlock+lock scheme), to fix the [splat2] (which would be totally ugly if we would kept the crit lock). Extend protected part of iavf_watchdog_task() to include scheduling more work. Note that the removed comment in iavf_reset_task() was misplaced, it belonged to inside of the removed if condition, so it's gone n
he removed comment in iavf_reset_task() was misplaced, it belonged to inside of the removed if condition, so it's gone now. [splat1] - w/o this patch - The deadlock during VF removal: WARNING: possible circular locking dependency detected sh/3825 is trying to acquire lock: ((work_completion)(&(&adapter->watchdog_task)->work)){+.+.}-{0:0}, at: start_flush_work+0x1a1/0x470 but task is already holding lock: (&adapter->crit_lock){+.+.}-{4:4}, at: iavf_remove+0xd1/0x690 [iavf] which lock already depends on the new lock. [splat2] - when cancelling work under crit lock, w/o this series, see [2] for the band aid attempt WARNING: possible circular locking dependency detected sh/3550 is trying to acqu
eries, see [2] for the band aid attempt WARNING: possible circular locking dependency detected sh/3550 is trying to acquire lock: ((wq_completion)iavf){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 but task is already holding lock: (&dev->lock){+.+.}-{4:4}, at: iavf_remove+0xa6/0x6e0 [iavf] which lock already depends on the new lock. [1] fc2e6b3b132a ("iavf: Rework mutexes for better synchronisation") [2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a References: - https://git.kernel.org/stable/c/620ab4d6215de0b25227f9fff1a8c7fb66837cb8 - https://git.kernel.org/stable/c/120f28a6f314fef7f282c99f196923fe44081cad