Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-38004 State: PUBLISHED Published: 2025-06-08T10:34:56.484Z Last Updated: 2025-11-03T17:33:04.853Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking for bcm_op runtime updates The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The content and also the length of the sequence can be changed resp reduced at runtime where the 'currframe' counter is then set to zero. Although this appeared to be a safe operation the updates of 'currframe' can be triggered from user space and hrtimer context in bcm_can_tx(). Anderson Nascimento created a proof of concept that triggere
ggered from user space and hrtimer context in bcm_can_tx(). Anderson Nascimento created a proof of concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh. At the rework of bcm_can_tx() the 'count' variable has been moved into the protected section as this variable can be modified from both contexts too. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/8f1c022541bf5a923c8d6fa483112c15250f30a4 - https://git.kernel.org/stable/c/7595de7bc56e0e52b74e56c90f7e247bf626d628 - https://git.kernel.org/stable/c/fbd8fdc2b218e979cfe422b139b8f74c12419d1f - https://git.kernel.org/stable/c/2a437b86ac5a9893c902f30
t.kernel.org/stable/c/fbd8fdc2b218e979cfe422b139b8f74c12419d1f - https://git.kernel.org/stable/c/2a437b86ac5a9893c902f30ef66815bf13587bf6 - https://git.kernel.org/stable/c/76c84c3728178b2d38d5604e399dfe8b0752645e - https://git.kernel.org/stable/c/cc55dd28c20a6611e30596019b3b2f636819a4c0 - https://git.kernel.org/stable/c/c4e8a172501e677ebd8ea9d9161d97dc4df56fbd - https://git.kernel.org/stable/c/c2aba69d0c36a496ab4f2e81e9c2b271f2693fd7
CVE ID: CVE-2025-38005 State: PUBLISHED Published: 2025-06-18T09:28:17.105Z Last Updated: 2025-11-03T19:58:13.689Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma: Add missing locking Recent kernels complain about a missing lock in k3-udma.c when the lock validator is enabled: [ 4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238 [ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28 [ 4.144867] Hardware name: pp-v12 (DT) [ 4.148648] Workqueue: events udma_check_tx_completion [ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -D
12 (DT) [ 4.148648] Workqueue: events udma_check_tx_completion [ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.160834] pc : udma_start.isra.0+0x34/0x238 [ 4.165227] lr : udma_start.isra.0+0x30/0x238 [ 4.169618] sp : ffffffc083cabcf0 [ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005 [ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000 [ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670 [ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030 [ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048 [ 4.208976] x14: 0000000000000048 x13: 000000
.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048 [ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001 [ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68 [ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8 [ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000 [ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000 [ 4.244986] Call trace: [ 4.247463] udma_start.isra.0+0x34/0x238 [ 4.251509] udma_check_tx_completion+0xd0/0xdc [ 4.256076] process_one_work+0x244/0x3fc [ 4.260129] process_scheduled_works+0x6c/0x74 [ 4.264610] worker_thread+0x150/0x1d
.256076] process_one_work+0x244/0x3fc [ 4.260129] process_scheduled_works+0x6c/0x74 [ 4.264610] worker_thread+0x150/0x1dc [ 4.268398] kthread+0xd8/0xe8 [ 4.271492] ret_from_fork+0x10/0x20 [ 4.275107] irq event stamp: 220 [ 4.278363] hardirqs last enabled at (219): [<ffffffc080a27c7c>] _raw_spin_unlock_irq+0x38/0x50 [ 4.287183] hardirqs last disabled at (220): [<ffffffc080a1c154>] el1_dbg+0x24/0x50 [ 4.294879] softirqs last enabled at (182): [<ffffffc080037e68>] handle_softirqs+0x1c0/0x3cc [ 4.303437] softirqs last disabled at (177): [<ffffffc080010170>] __do_softirq+0x1c/0x28 [ 4.311559] ---[ end trace 0000000000000000 ]--- This commit adds the missing locking. Additional Analyst Notes: - CV
28 [ 4.311559] ---[ end trace 0000000000000000 ]--- This commit adds the missing locking. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/27e71fa08711e09d81e06a54007b362a5426fd22 - https://git.kernel.org/stable/c/0ea0433f822ed0549715f7044c9cd1cf132ff7fa - https://git.kernel.org/stable/c/df5987e76a4ae4cbd705d81ab4b15ed232250a4a - https://git.kernel.org/stable/c/d87f1cddc592387359fde157cc4296556f6403c2 - https://git.kernel.org/stable/c/26e63b2fe30c61bd25981c6084f67a8af79945d0 - https://git.kernel.org/stable/c/99df1edf17493cb49a8c01f6bde55c3abb6a2a6c - https://git.kernel.org/stable/c/fca280992af8c2fbd511bc43f65abb4a17363f2f
CVE ID: CVE-2025-38006 State: PUBLISHED Published: 2025-06-18T09:28:17.773Z Last Updated: 2025-06-18T09:28:17.773Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: mctp: Don't access ifa_index when missing In mctp_dump_addrinfo, ifa_index can be used to filter interfaces, but only when the struct ifaddrmsg is provided. Otherwise it will be comparing to uninitialised memory - reproducible in the syzkaller case from dhcpd, or busybox "ip addr show". The kernel MCTP implementation has always filtered by ifa_index, so existing userspace programs expecting to dump MCTP addresses must already be passing a valid ifa_index value (ei
dex, so existing userspace programs expecting to dump MCTP addresses must already be passing a valid ifa_index value (either 0 or a real index). BUG: KMSAN: uninit-value in mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824 netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309 References: - https://git.kernel.org/stable/c/acab78ae12c7fefb4f3bfe22e00770a5faa42724 - https://git.kernel.org/stable/c/d4d1561d17eb72908e4489c0900d96e0484fac20 - https://git.kernel.org/stable/c/24fa213dffa470166ec014f979f36c6ff44afb45 - https://git.kernel.org/st
0900d96e0484fac20 - https://git.kernel.org/stable/c/24fa213dffa470166ec014f979f36c6ff44afb45 - https://git.kernel.org/stable/c/f11cf946c0a92c560a890d68e4775723353599e1
CVE ID: CVE-2025-38007 State: PUBLISHED Published: 2025-06-18T09:28:18.735Z Last Updated: 2025-11-03T19:58:15.120Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: Add NULL check in uclogic_input_configured() devm_kasprintf() returns NULL when memory allocation fails. Currently, uclogic_input_configured() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/01b76cc8ca243fc3376b035aa326bbc4f03d384b - https://git.kernel.org/stable/c/ad6caaf2
s: - https://git.kernel.org/stable/c/01b76cc8ca243fc3376b035aa326bbc4f03d384b - https://git.kernel.org/stable/c/ad6caaf29bc26a48b1241ce82561fcbcf0a75aa9 - https://git.kernel.org/stable/c/94e7272b636a0677082e0604609e4c471e0a2caf - https://git.kernel.org/stable/c/b616453d719ee1b8bf2ea6f6cc6c6258a572a590 - https://git.kernel.org/stable/c/bd07f751208ba190f9b0db5e5b7f35d5bb4a8a1e
CVE ID: CVE-2025-38008 State: PUBLISHED Published: 2025-06-18T09:28:19.358Z Last Updated: 2025-06-18T09:28:19.358Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: fix race condition in unaccepted memory handling The page allocator tracks the number of zones that have unaccepted memory using static_branch_enc/dec() and uses that static branch in hot paths to determine if it needs to deal with unaccepted memory. Borislav and Thomas pointed out that the tracking is racy: operations on static_branch are not serialized against adding/removing unaccepted pages to/from the zone. Sanity checks inside static_branch machine
are not serialized against adding/removing unaccepted pages to/from the zone. Sanity checks inside static_branch machinery detects it: WARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0 The comment around the WARN() explains the problem: /* * Warn about the '-1' case though; since that means a * decrement is concurrent with a first (0->1) increment. IOW * people are trying to disable something that wasn't yet fully * enabled. This suggests an ordering problem on the user side. */ The effect of this static_branch optimization is only visible on microbenchmark. Instead of adding more complexity around it, remove it altogether. References: - https://gi
y visible on microbenchmark. Instead of adding more complexity around it, remove it altogether. References: - https://git.kernel.org/stable/c/98fdd2f612e949c652693f6df00442c81037776d - https://git.kernel.org/stable/c/74953f93f47a45296cc2a3fd04e2a3202ff3fa53 - https://git.kernel.org/stable/c/71dda1cb10702dc2859f00eb789b0502de2176a9 - https://git.kernel.org/stable/c/fefc075182275057ce607effaa3daa9e6e3bdc73
CVE ID: CVE-2025-38009 State: PUBLISHED Published: 2025-06-18T09:28:20.068Z Last Updated: 2025-11-03T19:58:16.530Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: disable napi on driver removal A warning on driver removal started occurring after commit 9dd05df8403b ("net: warn if NAPI instance wasn't shut down"). Disable tx napi before deleting it in mt76_dma_cleanup(). WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100 CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy) Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024 RIP
inted 6.15.0-rc4 #4 PREEMPT(lazy) Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024 RIP: 0010:__netif_napi_del_locked+0xf0/0x100 Call Trace: <TASK> mt76_dma_cleanup+0x54/0x2f0 [mt76] mt7921_pci_remove+0xd5/0x190 [mt7921e] pci_device_remove+0x47/0xc0 device_release_driver_internal+0x19e/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x2e/0xb0 __do_sys_delete_module.isra.0+0x197/0x2e0 do_syscall_64+0x7b/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e Tested with mt7921e but the same pattern can be actually applied to other mt76 drivers calling mt76_dma_cleanup() during removal. Tx napi is enabled in their *_dma_init() functions a
ed to other mt76 drivers calling mt76_dma_cleanup() during removal. Tx napi is enabled in their *_dma_init() functions and only toggled off and on again inside their suspend/resume/reset paths. So it should be okay to disable tx napi in such a generic way. Found by Linux Verification Center (linuxtesting.org). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/ff0f820fa5b99035b3c654dd531226d8d83aec5f - https://git.kernel.org/stable/c/ca5b213bf4b4224335a8131a26805d16503fca5f - https://git.kernel.org/stable/c/b892e830d1ea8c5475254b98827771f7366f1039 - https://git.kernel.org/stable/c/5e700b06b970fc19e3a1ecb244e14785f3fbb8e3 - https://git.kernel.org/
b98827771f7366f1039 - https://git.kernel.org/stable/c/5e700b06b970fc19e3a1ecb244e14785f3fbb8e3 - https://git.kernel.org/stable/c/2b81e76db3667d1f7f2ad44e9835cdaf8dea95a8 - https://git.kernel.org/stable/c/e7bfbda5fddd27f3158e723d641c0fcdfb0552a7 - https://git.kernel.org/stable/c/78ab4be549533432d97ea8989d2f00b508fa68d8
CVE ID: CVE-2025-38010 State: PUBLISHED Published: 2025-06-18T09:28:20.715Z Last Updated: 2025-06-18T09:28:20.715Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: phy: tegra: xusb: Use a bitmask for UTMI pad power state tracking The current implementation uses bias_pad_enable as a reference count to manage the shared bias pad for all UTMI PHYs. However, during system suspension with connected USB devices, multiple power-down requests for the UTMI pad result in a mismatch in the reference count, which in turn produces warnings such as: [ 237.762967] WARNING: CPU: 10 PID: 1618 at tegra186_utmi_pad_power_down+0x160/0x170 [ 237.7631
oduces warnings such as: [ 237.762967] WARNING: CPU: 10 PID: 1618 at tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763103] Call trace: [ 237.763104] tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763107] tegra186_utmi_phy_power_off+0x10/0x30 [ 237.763110] phy_power_off+0x48/0x100 [ 237.763113] tegra_xusb_enter_elpg+0x204/0x500 [ 237.763119] tegra_xusb_suspend+0x48/0x140 [ 237.763122] platform_pm_suspend+0x2c/0xb0 [ 237.763125] dpm_run_callback.isra.0+0x20/0xa0 [ 237.763127] __device_suspend+0x118/0x330 [ 237.763129] dpm_suspend+0x10c/0x1f0 [ 237.763130] dpm_suspend_start+0x88/0xb0 [ 237.763132] suspend_devices_and_enter+0x120/0x500 [ 237.763135] pm_suspend+0x1ec/0x270 The root cause was tra
x88/0xb0 [ 237.763132] suspend_devices_and_enter+0x120/0x500 [ 237.763135] pm_suspend+0x1ec/0x270 The root cause was traced back to the dynamic power-down changes introduced in commit a30951d31b25 ("xhci: tegra: USB2 pad power controls"), where the UTMI pad was being powered down without verifying its current state. This unbalanced behavior led to discrepancies in the reference count. To rectify this issue, this patch replaces the single reference counter with a bitmask, renamed to utmi_pad_enabled. Each bit in the mask corresponds to one of the four USB2 PHYs, allowing us to track each pad's enablement status individually. With this change: - The bias pad is powered on only when the mask is
to track each pad's enablement status individually. With this change: - The bias pad is powered on only when the mask is clear. - Each UTMI pad is powered on or down based on its corresponding bit in the mask, preventing redundant operations. - The overall power state of the shared bias pad is maintained correctly during suspend/resume cycles. The mutex used to prevent race conditions during UTMI pad enable/disable operations has been moved from the tegra186_utmi_bias_pad_power_on/off functions to the parent functions tegra186_utmi_pad_power_on/down. This change ensures that there are no race conditions when updating the bitmask. References: - https://git.kernel.org/stable/c/ba25131b3c1ceec3
t there are no race conditions when updating the bitmask. References: - https://git.kernel.org/stable/c/ba25131b3c1ceec303839b2462586d7673788197 - https://git.kernel.org/stable/c/1db527f0cb8f677adadd4e28e5bc77aaf5d4e4c9 - https://git.kernel.org/stable/c/628bec9ed68a2204184fc8230a2609075b08666e - https://git.kernel.org/stable/c/b47158fb42959c417ff2662075c0d46fb783d5d1
CVE ID: CVE-2025-38011 State: PUBLISHED Published: 2025-06-18T09:28:21.453Z Last Updated: 2025-07-15T15:43:52.921Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: csa unmap use uninterruptible lock After process exit to unmap csa and free GPU vm, if signal is accepted and then waiting to take vm lock is interrupted and return, it causes memory leaking and below warning backtrace. Change to use uninterruptible wait lock fix the issue. WARNING: CPU: 69 PID: 167800 at amd/amdgpu/amdgpu_kms.c:1525 amdgpu_driver_postclose_kms+0x294/0x2a0 [amdgpu] Call Trace: <TASK> drm_file_free.part.0+0x1da/0x230 [drm] drm_close_helper.i
u_driver_postclose_kms+0x294/0x2a0 [amdgpu] Call Trace: <TASK> drm_file_free.part.0+0x1da/0x230 [drm] drm_close_helper.isra.0+0x65/0x70 [drm] drm_release+0x6a/0x120 [drm] amdgpu_drm_release+0x51/0x60 [amdgpu] __fput+0x9f/0x280 ____fput+0xe/0x20 task_work_run+0x67/0xa0 do_exit+0x217/0x3c0 do_group_exit+0x3b/0xb0 get_signal+0x14a/0x8d0 arch_do_signal_or_restart+0xde/0x100 exit_to_user_mode_loop+0xc1/0x1a0 exit_to_user_mode_prepare+0xf4/0x100 syscall_exit_to_user_mode+0x17/0x40 do_syscall_64+0x69/0xc0 (cherry picked from commit 7dbbfb3c171a6f63b01165958629c9c26abf38ab) References: - https://git.kernel.org/stable/c/8d71c3231b33e24a911b8f2d8c3a17ee40aa32d5 - https://git.kernel.org/stable/c/a1adc8
ces: - https://git.kernel.org/stable/c/8d71c3231b33e24a911b8f2d8c3a17ee40aa32d5 - https://git.kernel.org/stable/c/a1adc8d9a0d219d4e88672c30dbc9ea960d73136 - https://git.kernel.org/stable/c/a0fa7873f2f869087b1e7793f7fac3713a1e3afe
CVE ID: CVE-2025-38012 State: PUBLISHED Published: 2025-06-18T09:28:22.057Z Last Updated: 2025-06-18T09:28:22.057Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sched_ext: bpf_iter_scx_dsq_new() should always initialize iterator BPF programs may call next() and destroy() on BPF iterators even after new() returns an error value (e.g. bpf_for_each() macro ignores error returns from new()). bpf_iter_scx_dsq_new() could leave the iterator in an uninitialized state after an error return causing bpf_iter_scx_dsq_next() to dereference garbage data. Make bpf_iter_scx_dsq_new() always clear $kit->dsq so that next() and destroy() become
xt() to dereference garbage data. Make bpf_iter_scx_dsq_new() always clear $kit->dsq so that next() and destroy() become noops. References: - https://git.kernel.org/stable/c/0102989af4c334d1d98b2a0fd4d61a5152e39b72 - https://git.kernel.org/stable/c/255dd31bfc4a67a19b1fc2cd130a50284dadfe3a - https://git.kernel.org/stable/c/428dc9fc0873989d73918d4a9cc22745b7bbc799
CVE ID: CVE-2025-38013 State: PUBLISHED Published: 2025-06-18T09:28:22.672Z Last Updated: 2025-06-18T09:28:22.672Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Set n_channels after allocating struct cfg80211_scan_request Make sure that n_channels is set after allocating the struct cfg80211_registered_device::int_scan_req member. Seen with syzkaller: UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:1208:5 index 0 is out of range for type 'struct ieee80211_channel *[] __counted_by(n_channels)' (aka 'struct ieee80211_channel *[]') This was missed in the initial conversions because I failed to locate the al
nels)' (aka 'struct ieee80211_channel *[]') This was missed in the initial conversions because I failed to locate the allocation likely due to the "sizeof(void *)" not matching the "channels" array type. References: - https://git.kernel.org/stable/c/fde33ab3c052a302ee8a0b739094b88ceae4dd67 - https://git.kernel.org/stable/c/07c737d9ab02c07b562aefcca16aa95077368e24 - https://git.kernel.org/stable/c/e3192e999a0d05ea0ba2c59c09afaf0b8ee70b81 - https://git.kernel.org/stable/c/82bbe02b2500ef0a62053fe2eb84773fe31c5a0a
CVE ID: CVE-2025-38014 State: PUBLISHED Published: 2025-06-18T09:28:23.545Z Last Updated: 2025-06-18T09:28:23.545Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Refactor remove call with idxd_cleanup() helper The idxd_cleanup() helper cleans up perfmon, interrupts, internals and so on. Refactor remove call with the idxd_cleanup() helper to avoid code duplication. Note, this also fixes the missing put_device() for idxd groups, enginces and wqs. References: - https://git.kernel.org/stable/c/d530dd65f6f3c04bbf141702ecccd70170ed04ad - https://git.kernel.org/stable/c/23dc14c52d84b02b39d816bf16a754c0e7d48f9c - https
0dd65f6f3c04bbf141702ecccd70170ed04ad - https://git.kernel.org/stable/c/23dc14c52d84b02b39d816bf16a754c0e7d48f9c - https://git.kernel.org/stable/c/a7bd00f7e9bd075f3e4fbcc608d8ea445aed8692 - https://git.kernel.org/stable/c/a409e919ca321cc0e28f8abf96fde299f0072a81
CVE ID: CVE-2025-38015 State: PUBLISHED Published: 2025-06-18T09:28:24.235Z Last Updated: 2025-11-03T19:58:17.911Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix memory leak in error handling path of idxd_alloc Memory allocated for idxd is not freed if an error occurs during idxd_alloc(). To fix it, free the allocated memory in the reverse order of allocation before exiting the function in case of an error. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/64afd9a1f644b27661420257dcc007d5009c99dd - https://git.kernel.org/stable/c/6e94a2c3e4c166cd2736ac225fba588
.org/stable/c/64afd9a1f644b27661420257dcc007d5009c99dd - https://git.kernel.org/stable/c/6e94a2c3e4c166cd2736ac225fba5889fb1e8ac0 - https://git.kernel.org/stable/c/868dbce755ec92855362d213f47e045a8388361a - https://git.kernel.org/stable/c/4f005eb68890698e5abc6a3af04dab76f175c50c - https://git.kernel.org/stable/c/46a5cca76c76c86063000a12936f8e7875295838
CVE ID: CVE-2025-38016 State: PUBLISHED Published: 2025-06-18T09:28:24.883Z Last Updated: 2025-06-18T09:28:24.883Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: bpf: abort dispatch if device destroyed The current HID bpf implementation assumes no output report/request will go through it after hid_bpf_destroy_device() has been called. This leads to a bug that unplugging certain types of HID devices causes a cleaned- up SRCU to be accessed. The bug was previously a hidden failure until a recent x86 percpu change [1] made it access not-present pages. The bug will be triggered if the conditions below are met: A) a device unde
change [1] made it access not-present pages. The bug will be triggered if the conditions below are met: A) a device under the driver has some LEDs on B) hid_ll_driver->request() is uninplemented (e.g., logitech-djreceiver) If condition A is met, hidinput_led_worker() is always scheduled *after* hid_bpf_destroy_device(). hid_destroy_device ` hid_bpf_destroy_device ` cleanup_srcu_struct(&hdev->bpf.srcu) ` hid_remove_device ` ... ` led_classdev_unregister ` led_trigger_set(led_cdev, NULL) ` led_set_brightness(led_cdev, LED_OFF) ` ... ` input_inject_event ` input_event_dispose ` hidinput_input_event ` schedule_work(&hid->led_work) [hidinput_led_worker] This is fine when condition B is not met, w
` hidinput_input_event ` schedule_work(&hid->led_work) [hidinput_led_worker] This is fine when condition B is not met, where hidinput_led_worker() calls hid_ll_driver->request(). This is the case for most HID drivers, which implement it or use the generic one from usbhid. The driver itself or an underlying driver will then abort processing the request. Otherwise, hidinput_led_worker() tries hid_hw_output_report() and leads to the bug. hidinput_led_worker ` hid_hw_output_report ` dispatch_hid_bpf_output_report ` srcu_read_lock(&hdev->bpf.srcu) ` srcu_read_unlock(&hdev->bpf.srcu, idx) The bug has existed since the introduction [2] of dispatch_hid_bpf_output_report(). However, the same bug also
rcu, idx) The bug has existed since the introduction [2] of dispatch_hid_bpf_output_report(). However, the same bug also exists in dispatch_hid_bpf_raw_requests(), and I've reproduced (no visible effect because of the lack of [1], but confirmed bpf.destroyed == 1) the bug against the commit (i.e., the Fixes:) introducing the function. This is because hidinput_led_worker() falls back to hid_hw_raw_request() when hid_ll_driver->output_report() is uninplemented (e.g., logitech- djreceiver). hidinput_led_worker ` hid_hw_output_report: -ENOSYS ` hid_hw_raw_request ` dispatch_hid_bpf_raw_requests ` srcu_read_lock(&hdev->bpf.srcu) ` srcu_read_unlock(&hdev->bpf.srcu, idx) Fix the issue by returning