Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
table/c/fd53f41bd86daa39b454fd4637a908ff2123547f - https://git.kernel.org/stable/c/8632384337038b97910c2f7bb5a3f377aa68d001 - https://git.kernel.org/stable/c/bc88243bbe6140d289bb32b4ee4607ba5ce1124a - https://git.kernel.org/stable/c/f345d4d71e87d878437417ffbb9a7d4e16d235eb - https://git.kernel.org/stable/c/2d0f63077f481f11a07f20eab1c1f4367dfaef32 - https://git.kernel.org/stable/c/55ecdcd12bc176b86fecbcb125ac814ac8fe857a - https://git.kernel.org/stable/c/49c17fccae36505550c9121891722fff337f148a - https://git.kernel.org/stable/c/61f49171a43ab1f80c73c5c88c508770c461e0f2
CVE ID: CVE-2023-53568 State: PUBLISHED Published: 2025-10-04T15:17:10.044Z Last Updated: 2025-10-04T15:17:10.044Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: don't leak memory if dev_set_name() fails When dev_set_name() fails, zcdn_create() doesn't free the newly allocated resources. Do it. References: - https://git.kernel.org/stable/c/6b0cb9c055843777b374309503d89eabeb769355 - https://git.kernel.org/stable/c/0878052579cb2773caee64812a811edcab6b5a55 - https://git.kernel.org/stable/c/131cd74a8e38d75239f2c81dfee53d6554eb8bf8 - https://git.kernel.org/stable/c/147d8da33a2c2195ec63acd56cd7d80a3458c253 - https://git.
38d75239f2c81dfee53d6554eb8bf8 - https://git.kernel.org/stable/c/147d8da33a2c2195ec63acd56cd7d80a3458c253 - https://git.kernel.org/stable/c/174f11ef1615ec3ab1e2189685864433c0d855a2 - https://git.kernel.org/stable/c/6252f47b78031979ad919f971dc8468b893488bd
CVE ID: CVE-2023-53569 State: PUBLISHED Published: 2025-10-04T15:17:10.734Z Last Updated: 2025-10-04T15:17:10.734Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext2: Check block size validity during mount Check that log of block size stored in the superblock has sensible value. Otherwise the shift computing the block size can overflow leading to undefined behavior. References: - https://git.kernel.org/stable/c/0ebfaf14150f55550cffb1148ed3920143c7a69c - https://git.kernel.org/stable/c/451b98155be5dfee05bc6e7c8b30c0be4add3f71 - https://git.kernel.org/stable/c/c4813f858e5c3e4c4659ce95385c1c400c593e1e - https://git.kernel.org/sta
8b30c0be4add3f71 - https://git.kernel.org/stable/c/c4813f858e5c3e4c4659ce95385c1c400c593e1e - https://git.kernel.org/stable/c/22ab5fed07ad4b206ea910fd0132d1a0d4831584 - https://git.kernel.org/stable/c/99f8a15af6c9f0653193104a9e70891f950c6001 - https://git.kernel.org/stable/c/e6f4fb28890c1361e0db9eb1adee3fc04e7fe7f5 - https://git.kernel.org/stable/c/c2e7776843a953fd7e48895c3880c277f996193e - https://git.kernel.org/stable/c/62aeb94433fcec80241754b70d0d1836d5926b0a
CVE ID: CVE-2023-53570 State: PUBLISHED Published: 2025-10-04T15:17:11.525Z Last Updated: 2025-10-04T15:17:11.525Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: fix integer overflow in nl80211_parse_mbssid_elems() nl80211_parse_mbssid_elems() uses a u8 variable num_elems to count the number of MBSSID elements in the nested netlink attribute attrs, which can lead to an integer overflow if a user of the nl80211 interface specifies 256 or more elements in the corresponding attribute in userspace. The integer overflow can lead to a heap buffer overflow as num_elems determines the size of the trailing array in elems,
The integer overflow can lead to a heap buffer overflow as num_elems determines the size of the trailing array in elems, and this array is thereafter written to for each element in attrs. Note that this vulnerability only affects devices with the wiphy->mbssid_max_interfaces member set for the wireless physical device struct in the device driver, and can only be triggered by a process with CAP_NET_ADMIN capabilities. Fix this by checking for a maximum of 255 elements in attrs. References: - https://git.kernel.org/stable/c/e642eb67b8c10dcce758d549cc81564116e0fa49 - https://git.kernel.org/stable/c/7d09f9f255a5f78578deba5454923072bb53b16c - https://git.kernel.org/stable/c/6311071a056272e1e761de
it.kernel.org/stable/c/7d09f9f255a5f78578deba5454923072bb53b16c - https://git.kernel.org/stable/c/6311071a056272e1e761de8d0305e87cc566f734
CVE ID: CVE-2023-53571 State: PUBLISHED Published: 2025-10-04T15:17:12.304Z Last Updated: 2025-10-04T15:17:12.304Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/i915: Make intel_get_crtc_new_encoder() less oopsy The point of the WARN was to print something, not oops straight up. Currently that is precisely what happens if we can't find the connector for the crtc in the atomic state. Get the dev pointer from the atomic state instead of the potentially NULL encoder to avoid that. (cherry picked from commit 3b6692357f70498f617ea1b31a0378070a0acf1c) References: - https://git.kernel.org/stable/c/780f303233c35eeb5132e3ee1cbc8f4c
3b6692357f70498f617ea1b31a0378070a0acf1c) References: - https://git.kernel.org/stable/c/780f303233c35eeb5132e3ee1cbc8f4cebe86dd2 - https://git.kernel.org/stable/c/54202488c835dab8c648acd107f0bb8eaa699894 - https://git.kernel.org/stable/c/0fe6ef82e4f4764e8f556632e4cd93d78d448e99 - https://git.kernel.org/stable/c/8cd725315c559a8a4d18ac1d7fce1d6b9a667529 - https://git.kernel.org/stable/c/fd8b0abecdf66379e9d25d7448b942b5be379cb2 - https://git.kernel.org/stable/c/631420b06597a33c72b6dcef78d1c2dea17f452d
CVE ID: CVE-2023-53572 State: PUBLISHED Published: 2025-10-04T15:17:13.089Z Last Updated: 2025-10-04T15:17:13.089Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: clk: imx: scu: use _safe list iterator to avoid a use after free This loop is freeing "clk" so it needs to use list_for_each_entry_safe(). Otherwise it dereferences a freed variable to get the next item on the loop. References: - https://git.kernel.org/stable/c/f95ff838ac39f861d1f95a0f3bbb1e01c2517d79 - https://git.kernel.org/stable/c/08cc7cd2c2a29a2abf5bceb8f048c0734d3694ba - https://git.kernel.org/stable/c/3d90921f91fc6a8c801d527bb5848c99e335c1cf - https://git.kernel
bf5bceb8f048c0734d3694ba - https://git.kernel.org/stable/c/3d90921f91fc6a8c801d527bb5848c99e335c1cf - https://git.kernel.org/stable/c/0a719f0e4b6f233979e219baff73923e76a96e09 - https://git.kernel.org/stable/c/632c60ecd25dbacee54d5581fe3aeb834b57010a
CVE ID: CVE-2023-53573 State: PUBLISHED Published: 2025-10-04T15:17:13.872Z Last Updated: 2025-10-04T15:17:13.872Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: clk: rs9: Fix suspend/resume Disabling the cache in commit 2ff4ba9e3702 ("clk: rs9: Fix I2C accessors") without removing cache synchronization in resume path results in a kernel panic as map->cache_ops is unset, due to REGCACHE_NONE. Enable flat cache again to support resume again. num_reg_defaults_raw is necessary to read the cache defaults from hardware. Some registers are strapped in hardware and cannot be provided in software. References: - https://git.kernel.org/s
ware. Some registers are strapped in hardware and cannot be provided in software. References: - https://git.kernel.org/stable/c/74f4471ad64214dd5046213ebdd6e0930da7bd2c - https://git.kernel.org/stable/c/a983967602675880d6160a17ace2c0f48717ff33 - https://git.kernel.org/stable/c/632e04739c8f45c2d9ca4d4c5bd18d80c2ac9296
CVE ID: CVE-2023-53574 State: PUBLISHED Published: 2025-10-04T15:17:14.532Z Last Updated: 2025-10-06T09:07:18.330Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: delete timer and free skb queue when unloading Fix possible crash and memory leak on driver unload by deleting TX purge timer and freeing C2H queue in 'rtw_core_deinit()', shrink critical section in the latter by freeing COEX queue out of TX report lock scope. References: - https://git.kernel.org/stable/c/4128b00a6006870e117ab1841e58f369e9284ecb - https://git.kernel.org/stable/c/634fcbcaa4062db39aeb5ac6ed1bc1feb8dd5216
CVE ID: CVE-2023-53575 State: PUBLISHED Published: 2025-10-04T15:17:15.224Z Last Updated: 2025-10-06T09:07:19.662Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix potential array out of bounds access Account for IWL_SEC_WEP_KEY_OFFSET when needed while verifying key_len size in iwl_mvm_sec_key_add(). References: - https://git.kernel.org/stable/c/133b1cd4d98bb8b272335c8e6b0e0c399c0b2ffa - https://git.kernel.org/stable/c/637452360ecde9ac972d19416e9606529576b302
CVE ID: CVE-2023-53576 State: PUBLISHED Published: 2025-10-04T15:17:15.931Z Last Updated: 2025-10-04T15:17:15.931Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: null_blk: Always check queue mode setting from configfs Make sure to check device queue mode in the null_validate_conf() and return error for NULL_Q_RQ as we don't allow legacy I/O path, without this patch we get OOPs when queue mode is set to 1 from configfs, following are repro steps :- modprobe null_blk nr_devices=0 mkdir config/nullb/nullb0 echo 1 > config/nullb/nullb0/memory_backed echo 4096 > config/nullb/nullb0/blocksize echo 20480 > config/nullb/nullb0/size ech
> config/nullb/nullb0/memory_backed echo 4096 > config/nullb/nullb0/blocksize echo 20480 > config/nullb/nullb0/size echo 1 > config/nullb/nullb0/queue_mode echo 1 > config/nullb/nullb0/power Entering kdb (current=0xffff88810acdd080, pid 2372) on processor 42 Oops: (null) due to oops @ 0xffffffffc041c329 CPU: 42 PID: 2372 Comm: sh Tainted: G O N 6.3.0-rc5lblk+ #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:null_add_dev.part.0+0xd9/0x720 [null_blk] Code: 01 00 00 85 d2 0f 85 a1 03 00 00 48 83 bb 08 01 00 00 00 0f 85 f7 03 00 00 80 bb 62 01 00 00 00 48 8b 75 20 0f 85 6d 02 00 00 <48> 89 6e 60 48 8b 75 20 bf 06 00
b 08 01 00 00 00 0f 85 f7 03 00 00 80 bb 62 01 00 00 00 48 8b 75 20 0f 85 6d 02 00 00 <48> 89 6e 60 48 8b 75 20 bf 06 00 00 00 e8 f5 37 2c c1 48 8b 75 20 RSP: 0018:ffffc900052cbde0 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff88811084d800 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888100042e00 RBP: ffff8881053d8200 R08: ffffc900052cbd68 R09: ffff888105db2000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002 R13: ffff888104765200 R14: ffff88810eec1748 R15: ffff88810eec1740 FS: 00007fd445fd1740(0000) GS:ffff8897dfc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000060 CR3: 0000000166a00000 CR4
knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000060 CR3: 0000000166a00000 CR4: 0000000000350ee0 DR0: ffffffff8437a488 DR1: ffffffff8437a489 DR2: ffffffff8437a48a DR3: ffffffff8437a48b DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: <TASK> nullb_device_power_store+0xd1/0x120 [null_blk] configfs_write_iter+0xb4/0x120 vfs_write+0x2ba/0x3c0 ksys_write+0x5f/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7fd4460c57a7 Code: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007ffd3792a4a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fd4460c57a7 RDX: 0000000000000002 RSI: 000055b43c02e4c0 RDI: 0000000000000001 RBP: 000055b43c02e4c0 R08: 000000000000000a R09: 00007fd44615b4e0 R10: 00007fd44615b3e0 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fd446198520 R14: 0000000000000002 R15: 00007fd446198700 </TASK> References: - https://git.kernel.org/stable/c/e732a266b973cd4e115e2cc2ea5007119e8a7fbc - https://git.kernel.org/stable/c/35e304dbcefa95237a3d6f94c007bfb10f012b17 - https:
a266b973cd4e115e2cc2ea5007119e8a7fbc - https://git.kernel.org/stable/c/35e304dbcefa95237a3d6f94c007bfb10f012b17 - https://git.kernel.org/stable/c/fd35b7bb6d5a329c427924886949ab51f210200a - https://git.kernel.org/stable/c/651260e563d9f50827dac496dc8a0b9b23d5db1a - https://git.kernel.org/stable/c/63f8793ee60513a09f110ea460a6ff2c33811cdb
CVE ID: CVE-2023-53577 State: PUBLISHED Published: 2025-10-04T15:17:16.632Z Last Updated: 2025-10-04T15:17:16.632Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf, cpumap: Make sure kthread is running before map update returns The following warning was reported when running stress-mode enabled xdp_redirect_cpu with some RT threads: ------------[ cut here ]------------ WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135 CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: events cpu_map_kthread_stop RIP: 0010:put_cpu_map_entry+0xda/0x220 ...... Call Trace:
(i440FX + PIIX, 1996) Workqueue: events cpu_map_kthread_stop RIP: 0010:put_cpu_map_entry+0xda/0x220 ...... Call Trace: <TASK> ? show_regs+0x65/0x70 ? __warn+0xa5/0x240 ...... ? put_cpu_map_entry+0xda/0x220 cpu_map_kthread_stop+0x41/0x60 process_one_work+0x6b0/0xb80 worker_thread+0x96/0x720 kthread+0x1a5/0x1f0 ret_from_fork+0x3a/0x70 ret_from_fork_asm+0x1b/0x30 </TASK> The root cause is the same as commit 436901649731 ("bpf: cpumap: Fix memory leak in cpu_map_update_elem"). The kthread is stopped prematurely by kthread_stop() in cpu_map_kthread_stop(), and kthread() doesn't call cpu_map_kthread_run() at all but XDP program has already queued some frames or skbs into ptr_ring. So when __cpu_m
call cpu_map_kthread_run() at all but XDP program has already queued some frames or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checks the ptr_ring, it will find it was not emptied and report a warning. An alternative fix is to use __cpu_map_ring_cleanup() to drop these pending frames or skbs when kthread_stop() returns -EINTR, but it may confuse the user, because these frames or skbs have been handled correctly by XDP program. So instead of dropping these frames or skbs, just make sure the per-cpu kthread is running before __cpu_map_entry_alloc() returns. After apply the fix, the error handle for kthread_stop() will be unnecessary because it will always return 0, so just remove it
pply the fix, the error handle for kthread_stop() will be unnecessary because it will always return 0, so just remove it. References: - https://git.kernel.org/stable/c/b44d28b98f185d2f2348aa3c3636838c316f889e - https://git.kernel.org/stable/c/7a1178a3671b40746830d355836b72e47ceb2490 - https://git.kernel.org/stable/c/ecb45b852af5e88257020b88bea5ff0798d72aca - https://git.kernel.org/stable/c/640a604585aa30f93e39b17d4d6ba69fcb1e66c9
CVE ID: CVE-2023-53578 State: PUBLISHED Published: 2025-10-04T15:17:17.350Z Last Updated: 2025-10-04T15:17:17.350Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: qrtr: Fix an uninit variable access bug in qrtr_tx_resume() Syzbot reported a bug as following: ===================================================== BUG: KMSAN: uninit-value in qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230 qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230 qrtr_endpoint_post+0xf85/0x11b0 net/qrtr/af_qrtr.c:519 qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600
iter+0x270/0x400 net/qrtr/tun.c:108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:
mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988 kmalloc_reserve net/core/skbuff.c:492 [inline] __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565 __netdev_alloc_skb+0x120/0x7d0 net/core/skbuff.c:630 qrtr_endpoint_post+0xbd/0x11b0 net/qrtr/af_qrtr.c:446 qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x
o.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd It is because that skb->len requires at least sizeof(struct qrtr_ctrl_pkt) in qrtr_tx_resume(). And skb->len equals to size in qrtr_endpoint_post(). But size is less than sizeof(struct qrtr_ctrl_pkt) when qrtr_cb->type equals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() under the syzbot scenario. This triggers the uninit variable access bug. Add size check when qrtr_cb->type equals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() to fix the bug. References: - https://git.kernel.org/stable/c/3814d211
ls to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() to fix the bug. References: - https://git.kernel.org/stable/c/3814d211ff13ee35f2d9437439a6c7df58524137 - https://git.kernel.org/stable/c/c6a796ee5a639ffb83c6e5469408cc2ec16cac6a - https://git.kernel.org/stable/c/bef57c227b52c2bde00fad33556175d36d12cfa0 - https://git.kernel.org/stable/c/8c9ce34a6ff2c544f96ce0b088e8fd3c1b9698c4 - https://git.kernel.org/stable/c/6417070918de3bcdbe0646e7256dae58fd8083ba
CVE ID: CVE-2023-53579 State: PUBLISHED Published: 2025-10-04T15:17:18.040Z Last Updated: 2025-10-04T15:17:18.040Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix irq domain leak Uwe Kleine-König pointed out we still have one resource leak in the mvebu driver triggered on driver detach. Let's address it with a custom devm action. References: - https://git.kernel.org/stable/c/b19e90521286a03bc3793fd598f20277a8f99c85 - https://git.kernel.org/stable/c/44e2afbf650f3264519643fcc9e6b4d2f6e8d547 - https://git.kernel.org/stable/c/d9b791d8362359d241b4e8f4b4767c681ffdb6ef - https://git.kernel.org/stable/c/644ee70267a934be
ps://git.kernel.org/stable/c/d9b791d8362359d241b4e8f4b4767c681ffdb6ef - https://git.kernel.org/stable/c/644ee70267a934be27370f9aa618b29af7290544
CVE ID: CVE-2023-53580 State: PUBLISHED Published: 2025-10-04T15:43:57.064Z Last Updated: 2025-10-04T15:43:57.064Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: USB: Gadget: core: Help prevent panic during UVC unconfigure Avichal Rakesh reported a kernel panic that occurred when the UVC gadget driver was removed from a gadget's configuration. The panic involves a somewhat complicated interaction between the kernel driver and a userspace component (as described in the Link tag below), but the analysis did make one thing clear: The Gadget core should accomodate gadget drivers calling usb_gadget_deactivate() as part of their unbi
one thing clear: The Gadget core should accomodate gadget drivers calling usb_gadget_deactivate() as part of their unbind procedure. Currently this doesn't work. gadget_unbind_driver() calls driver->unbind() while holding the udc->connect_lock mutex, and usb_gadget_deactivate() attempts to acquire that mutex, which will result in a deadlock. The simple fix is for gadget_unbind_driver() to release the mutex when invoking the ->unbind() callback. There is no particular reason for it to be holding the mutex at that time, and the mutex isn't held while the ->bind() callback is invoked. So we'll drop the mutex before performing the unbind callback and reacquire it afterward. We'll also add a cou
invoked. So we'll drop the mutex before performing the unbind callback and reacquire it afterward. We'll also add a couple of comments to usb_gadget_activate() and usb_gadget_deactivate(). Because they run in process context they must not be called from a gadget driver's ->disconnect() callback, which (according to the kerneldoc for struct usb_gadget_driver in include/linux/usb/gadget.h) may run in interrupt context. This may help prevent similar bugs from arising in the future. References: - https://git.kernel.org/stable/c/bed19d95fcb9c98dfaa9585922b39a2dfba7898d - https://git.kernel.org/stable/c/8c1edc00db65f6d4408b3d1cd845e8da3b9e0ca4 - https://git.kernel.org/stable/c/65dadb2beeb7360232b
//git.kernel.org/stable/c/8c1edc00db65f6d4408b3d1cd845e8da3b9e0ca4 - https://git.kernel.org/stable/c/65dadb2beeb7360232b09ebc4585b54475dfee06
CVE ID: CVE-2023-53581 State: PUBLISHED Published: 2025-10-04T15:43:57.758Z Last Updated: 2025-10-04T15:43:57.758Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Check for NOT_READY flag state after locking Currently the check for NOT_READY flag is performed before obtaining the necessary lock. This opens a possibility for race condition when the flow is concurrently removed from unready_flows list by the workqueue task, which causes a double-removal from the list and a crash[0]. Fix the issue by moving the flag check inside the section protected by uplink_priv->unready_flows_lock mutex. [0]: [44376.389654] general p
ving the flag check inside the section protected by uplink_priv->unready_flows_lock mutex. [0]: [44376.389654] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP [44376.391665] CPU: 7 PID: 59123 Comm: tc Not tainted 6.4.0-rc4+ #1 [44376.392984] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [44376.395342] RIP: 0010:mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core] [44376.396857] Code: 00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 88 e1 48 8b 83 98 06 00 00 48 8b 93 90 06 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06 [44376.399167
8b 83 98 06 00 00 48 8b 93 90 06 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06 [44376.399167] RSP: 0018:ffff88812cc97570 EFLAGS: 00010246 [44376.399680] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00 [44376.400337] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0 [44376.401001] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001 [44376.401663] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000 [44376.402342] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000 [44376.402999] FS: 00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000 [44376.403787] CS: 0010 DS: 0000 ES: 0
2999] FS: 00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000 [44376.403787] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [44376.404343] CR2: 0000000000489108 CR3: 0000000123a79003 CR4: 0000000000370ea0 [44376.405004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [44376.405665] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [44376.406339] Call Trace: [44376.406651] <TASK> [44376.406939] ? die_addr+0x33/0x90 [44376.407311] ? exc_general_protection+0x192/0x390 [44376.407795] ? asm_exc_general_protection+0x22/0x30 [44376.408292] ? mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core] [44376.408876] __mlx5e_tc_del_fdb_peer_flow+0xbc/0xe0 [mlx