Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ble/c/e1e00dc45648125ef7cb87ebc3b581ac224e7b39 - https://git.kernel.org/stable/c/397254706eba9d8f99fd237feede7ab3169a7f9a - https://git.kernel.org/stable/c/28e5a867aa542e369e211c2baba7044228809a99 - https://git.kernel.org/stable/c/3b3aa72636a6205933609ec274a8747720c1ee3f - https://git.kernel.org/stable/c/f69f8a93aacf6e99af7b1cc992d8ca2cc07b96fb - https://git.kernel.org/stable/c/3db42c75a921854a99db0a2775814fef97415bac
CVE ID: CVE-2025-37884 State: PUBLISHED Published: 2025-05-09T06:45:47.462Z Last Updated: 2025-11-03T19:56:56.651Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix deadlock between rcu_tasks_trace and event_mutex. Fix the following deadlock: CPU A _free_event() perf_kprobe_destroy() mutex_lock(&event_mutex) perf_trace_event_unreg() synchronize_rcu_tasks_trace() There are several paths where _free_event() grabs event_mutex and calls sync_rcu_tasks_trace. Above is one such case. CPU B bpf_prog_test_run_syscall() rcu_read_lock_trace() bpf_prog_run_pin_on_cpu() bpf_prog_load() bpf_tracing_func_proto() trace_set_clr_event() m
scall() rcu_read_lock_trace() bpf_prog_run_pin_on_cpu() bpf_prog_load() bpf_tracing_func_proto() trace_set_clr_event() mutex_lock(&event_mutex) Delegate trace_set_clr_event() to workqueue to avoid such lock dependency. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/255cbc9db7067a83713fd2f4b31034ddd266549a - https://git.kernel.org/stable/c/b5a528a34e1f613565115a7a6016862ccbfcb9ac - https://git.kernel.org/stable/c/c5c833f6375f8ecf9254dd27946c927c7d645421 - https://git.kernel.org/stable/c/45286680b385f2592db3003554872388dee66d68 - https://git.kernel.org/stable/c/4580f4e0ebdf8dc8d506ae926b88510395a0c1d1
CVE ID: CVE-2025-37885 State: PUBLISHED Published: 2025-05-09T06:45:48.150Z Last Updated: 2025-11-03T19:56:59.413Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reset IRTE to host control if *new* route isn't postable Restore an IRTE back to host control (remapped or posted MSI mode) if the *new* GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU. The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in
ng IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn't freed. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/e5f2dee9f7fcd2ff4b97869f3c66a0d89c167769 - https://git.kernel.org/stable/c/116c7d35b8f72eac383b9fd371d7c1a8ffc2968b - https://git.kernel.org/stable/c/023816bd5fa46fab94d1e7917fe131b79ed1fb41 - https://git.kernel.org/stable/c/3481fd96d801715942b6f69fe251133128156f30 - https://git.kernel.org/stable/c/b5de7ac74f69603ad803c524b840bffd36368fc3 - https://git.kernel.org/stable/c/3066ec21d1a33896125747
it.kernel.org/stable/c/b5de7ac74f69603ad803c524b840bffd36368fc3 - https://git.kernel.org/stable/c/3066ec21d1a33896125747f68638725f456308db - https://git.kernel.org/stable/c/9bcac97dc42d2f4da8229d18feb0fe2b1ce523a2
CVE ID: CVE-2025-37886 State: PUBLISHED Published: 2025-05-09T06:45:48.810Z Last Updated: 2025-05-26T05:23:03.001Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: pds_core: make wait_context part of q_info Make the wait_context a full part of the q_info struct rather than a stack variable that goes away after pdsc_adminq_post() is done so that the context is still available after the wait loop has given up. There was a case where a slow development firmware caused the adminq request to time out, but then later the FW finally finished the request and sent the interrupt. The handler tried to complete_all() the completion context t
the FW finally finished the request and sent the interrupt. The handler tried to complete_all() the completion context that had been created on the stack in pdsc_adminq_post() but no longer existed. This caused bad pointer usage, kernel crashes, and much wailing and gnashing of teeth. References: - https://git.kernel.org/stable/c/1d7c4b2b0bbfb09b55b2dc0e2355d7936bf89381 - https://git.kernel.org/stable/c/66d7702b42ffdf0dce4808626088268a4e905ca6 - https://git.kernel.org/stable/c/520f012fe75fb8efc9f16a57ef929a7a2115d892 - https://git.kernel.org/stable/c/3f77c3dfffc7063428b100c4945ca2a7a8680380
CVE ID: CVE-2025-37887 State: PUBLISHED Published: 2025-05-09T06:45:49.492Z Last Updated: 2025-05-26T05:23:04.394Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: pds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result If the FW doesn't support the PDS_CORE_CMD_FW_CONTROL command the driver might at the least print garbage and at the worst crash when the user runs the "devlink dev info" devlink command. This happens because the stack variable fw_list is not 0 initialized which results in fw_list.num_fw_slots being a garbage value from the stack. Then the driver tries to access fw_list.fw_names[i] with i >= ARRAY_SIZE and run
s being a garbage value from the stack. Then the driver tries to access fw_list.fw_names[i] with i >= ARRAY_SIZE and runs off the end of the array. Fix this by initializing the fw_list and by not failing completely if the devcmd fails because other useful information is printed via devlink dev info even if the devcmd fails. References: - https://git.kernel.org/stable/c/cdd784c96fe2e5edbf0ed9b3e96fe776e8092385 - https://git.kernel.org/stable/c/6702f5c6b22deaa95bf84f526148174a160a02cb - https://git.kernel.org/stable/c/12a4651a80dbe4589a84e26785fbbe1ed4d043b7 - https://git.kernel.org/stable/c/2567daad69cd1107fc0ec29b1615f110d7cf7385
CVE ID: CVE-2025-37888 State: PUBLISHED Published: 2025-05-09T06:45:50.128Z Last Updated: 2025-05-26T05:23:05.742Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix null-ptr-deref in mlx5_create_{inner_,}ttc_table() Add NULL check for mlx5_get_flow_namespace() returns in mlx5_create_inner_ttc_table() and mlx5_create_ttc_table() to prevent NULL pointer dereference. References: - https://git.kernel.org/stable/c/0b682680b12b08cd62b113ea92b2938195de1dfe - https://git.kernel.org/stable/c/ecd9d2647ddb4f42a121de648e48659ae1856c39 - https://git.kernel.org/stable/c/91037037ee3d611ce17f39d75f79c7de394b122a
CVE ID: CVE-2025-37889 State: PUBLISHED Published: 2025-05-09T06:45:50.868Z Last Updated: 2025-11-03T19:57:00.804Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Consistently treat platform_max as control value This reverts commit 9bdd10d57a88 ("ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min"), and makes some additional related updates. There are two ways the platform_max could be interpreted; the maximum register value, or the maximum value the control can be set to. The patch moved from treating the value as a control value to a register one. When the patch was applied it was technically correct as s
from treating the value as a control value to a register one. When the patch was applied it was technically correct as snd_soc_limit_volume() also used the register interpretation. However, even then most of the other usages treated platform_max as a control value, and snd_soc_limit_volume() has since been updated to also do so in commit fb9ad24485087 ("ASoC: ops: add correct range check for limiting volume"). That patch however, missed updating snd_soc_put_volsw() back to the control interpretation, and fixing snd_soc_info_volsw_range(). The control interpretation makes more sense as limiting is typically done from the machine driver, so it is appropriate to use the customer facing represen
re sense as limiting is typically done from the machine driver, so it is appropriate to use the customer facing representation rather than the internal codec representation. Update all the code to consistently use this interpretation of platform_max. Finally, also add some comments to the soc_mixer_control struct to hopefully avoid further patches switching between the two approaches. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/c402f184a053c8e7ca325e50f04bbbc1e4fee019 - https://git.kernel.org/stable/c/694110bc2407a61f02a770cbb5f39b51e4ec77c6 - https://git.kernel.org/stable/c/544055329560d4b64fe204fc6be325ebc24c72ca - https://git.kernel.org
70cbb5f39b51e4ec77c6 - https://git.kernel.org/stable/c/544055329560d4b64fe204fc6be325ebc24c72ca - https://git.kernel.org/stable/c/a46a9371f8b9a0eeff53a21e11ed3b65f52d9cf6 - https://git.kernel.org/stable/c/296c8295ae34045da0214882628d49c1c060dd8a - https://git.kernel.org/stable/c/0eba2a7e858907a746ba69cd002eb9eb4dbd7bf3
CVE ID: CVE-2025-37890 State: PUBLISHED Published: 2025-05-16T13:01:12.798Z Last Updated: 2025-11-03T19:57:02.260Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc As described in Gerrard's report [1], we have a UAF case when an hfsc class has a netem child qdisc. The crux of the issue is that hfsc is assuming that checking for cl->qdisc->q.qlen == 0 guarantees that it hasn't inserted the class in the vttree or eltree (which is not true for the netem duplicate case). This patch checks the n_active class variable to make sure that the code won't insert the
for the netem duplicate case). This patch checks the n_active class variable to make sure that the code won't insert the class in the vttree or eltree twice, catering for the reentrant case. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/ Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/273bbcfa53541cde38b2003ad88a59b770306421 - https://git.kernel.org/stable/c/e0cf8ee23e1915431f262a7b2dee0c7a7d699af0 - https://git.kernel.org/stable/c/e3e949a39a91d1f829a4890e7dfe9417ac72e4d0 - https://git.kernel.org/stable/c/8df7d37d626430035b413b97cee18396b3450bef - https://git.kernel.org/stable/c/6082a87af
0 - https://git.kernel.org/stable/c/8df7d37d626430035b413b97cee18396b3450bef - https://git.kernel.org/stable/c/6082a87af4c52f58150d40dec1716011d871ac21 - https://git.kernel.org/stable/c/2e7093c7a8aba5d4f8809f271488e5babe75e202 - https://git.kernel.org/stable/c/ac39fd4a757584d78ed062d4f6fd913f83bd98b5 - https://git.kernel.org/stable/c/141d34391abbb315d68556b7c67ad97885407547
CVE ID: CVE-2025-37891 State: PUBLISHED Published: 2025-05-19T07:19:04.583Z Last Updated: 2025-05-26T05:23:08.292Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: ump: Fix buffer overflow at UMP SysEx message conversion The conversion function from MIDI 1.0 to UMP packet contains an internal buffer to keep the incoming MIDI bytes, and its size is 4, as it was supposed to be the max size for a MIDI1 UMP packet data. However, the implementation overlooked that SysEx is handled in a different format, and it can be up to 6 bytes, as found in do_convert_to_ump(). It leads eventually to a buffer overflow, and may corrupt the mem
can be up to 6 bytes, as found in do_convert_to_ump(). It leads eventually to a buffer overflow, and may corrupt the memory when a longer SysEx message is received. The fix is simply to extend the buffer size to 6 to fit with the SysEx UMP message. References: - https://git.kernel.org/stable/c/ce4f77bef276e7d2eb7ab03a5d08bcbaa40710ec - https://git.kernel.org/stable/c/226beac5605afbb33f8782148d188b64396145a4 - https://git.kernel.org/stable/c/42ef48dd4ebb082a1a90b5c3feeda2e68a9e32fe - https://git.kernel.org/stable/c/56f1f30e6795b890463d9b20b11e576adf5a2f77
CVE ID: CVE-2025-37892 State: PUBLISHED Published: 2025-05-20T11:00:26.977Z Last Updated: 2025-11-03T19:57:03.688Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mtd: inftlcore: Add error check for inftl_read_oob() In INFTL_findwriteunit(), the return value of inftl_read_oob() need to be checked. A proper implementation can be found in INFTL_deleteblock(). The status will be set as SECTOR_IGNORE to break from the while-loop correctly if the inftl_read_oob() fails. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/b828d394308e8e00df0a6f57e7dabae609bb8b7b - https://git.kernel.org/sta
ner: References: - https://git.kernel.org/stable/c/b828d394308e8e00df0a6f57e7dabae609bb8b7b - https://git.kernel.org/stable/c/0300e751170cf80c05ca1a762a7b449e8ca6b693 - https://git.kernel.org/stable/c/e7d6ceff95c55297f0ee8f9dbc4da5c558f30e9e - https://git.kernel.org/stable/c/6af3b92b1c0b58ca281d0e1501bad2567f73c1a5 - https://git.kernel.org/stable/c/7772621041ee78823ccc5f1fe38f6faa22af7023 - https://git.kernel.org/stable/c/5479a6af3c96f73bec2d2819532b6d6814f52dd6 - https://git.kernel.org/stable/c/1c22356dfb041e5292835c9ff44d5f91bef8dd18 - https://git.kernel.org/stable/c/114d94f095aa405fa9a51484c4be34846d7bb386 - https://git.kernel.org/stable/c/d027951dc85cb2e15924c980dc22a6754d100c7c
CVE ID: CVE-2025-37893 State: PUBLISHED Published: 2025-04-18T07:01:28.856Z Last Updated: 2025-10-01T16:14:37.219Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Fix off-by-one error in build_prologue() Vincent reported that running BPF progs with tailcalls on LoongArch causes kernel hard lockup. Debugging the issues shows that the JITed image missing a jirl instruction at the end of the epilogue. There are two passes in JIT compiling, the first pass set the flags and the second pass generates JIT code based on those flags. With BPF progs mixing bpf2bpf and tailcalls, build_prologue() generates N insns in the fi
JIT code based on those flags. With BPF progs mixing bpf2bpf and tailcalls, build_prologue() generates N insns in the first pass and then generates N+1 insns in the second pass. This makes epilogue_offset off by one and we will jump to some unexpected insn and cause lockup. Fix this by inserting a nop insn. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/b3ffad2f02db4aace6799fe0049508b8925eae45 - https://git.kernel.org/stable/c/205a2182c51ffebaef54d643e3745e720cded08b - https://git.kernel.org/stable/c/c74d95a5679741ef428974ab788f5b0758dc78ae - https://git.kernel.org/stable/c/48b904de2408af5f936f0e03f48dfcddeab58aa0 - https://git.kernel.org/sta
788f5b0758dc78ae - https://git.kernel.org/stable/c/48b904de2408af5f936f0e03f48dfcddeab58aa0 - https://git.kernel.org/stable/c/7e2586991e36663c9bc48c828b83eab180ad30a9
CVE ID: CVE-2025-37894 State: PUBLISHED Published: 2025-05-20T15:21:31.283Z Last Updated: 2025-05-26T05:23:12.197Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: use sock_gen_put() when sk_state is TCP_TIME_WAIT It is possible for a pointer of type struct inet_timewait_sock to be returned from the functions __inet_lookup_established() and __inet6_lookup_established(). This can cause a crash when the returned pointer is of type struct inet_timewait_sock and sock_put() is called on it. The following is a crash call stack that shows sk->sk_wmem_alloc being accessed in sk_free() during the call to sock_put() on a struct inet_t
ash call stack that shows sk->sk_wmem_alloc being accessed in sk_free() during the call to sock_put() on a struct inet_timewait_sock pointer. To avoid this issue, use sock_gen_put() instead of sock_put() when sk->sk_state is TCP_TIME_WAIT. mrdump.ko ipanic() + 120 vmlinux notifier_call_chain(nr_to_call=-1, nr_calls=0) + 132 vmlinux atomic_notifier_call_chain(val=0) + 56 vmlinux panic() + 344 vmlinux add_taint() + 164 vmlinux end_report() + 136 vmlinux kasan_report(size=0) + 236 vmlinux report_tag_fault() + 16 vmlinux do_tag_recovery() + 16 vmlinux __do_kernel_fault() + 88 vmlinux do_bad_area() + 28 vmlinux do_tag_check_fault() + 60 vmlinux do_mem_abort() + 80 vmlinux el1_abort() + 56 vmlinux
mlinux do_bad_area() + 28 vmlinux do_tag_check_fault() + 60 vmlinux do_mem_abort() + 80 vmlinux el1_abort() + 56 vmlinux el1h_64_sync_handler() + 124 vmlinux > 0xFFFFFFC080011294() vmlinux __lse_atomic_fetch_add_release(v=0xF2FFFF82A896087C) vmlinux __lse_atomic_fetch_sub_release(v=0xF2FFFF82A896087C) vmlinux arch_atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C) + 8 vmlinux raw_atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C) + 8 vmlinux atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C) + 8 vmlinux __refcount_sub_and_test(i=1, r=0xF2FFFF82A896087C, oldp=0) + 8 vmlinux __refcount_dec_and_test(r=0xF2FFFF82A896087C, oldp=0) + 8 vmlinux refcount_dec_and_test(r=0xF2FFFF82A896087C) + 8 vml
ux __refcount_dec_and_test(r=0xF2FFFF82A896087C, oldp=0) + 8 vmlinux refcount_dec_and_test(r=0xF2FFFF82A896087C) + 8 vmlinux sk_free(sk=0xF2FFFF82A8960700) + 28 vmlinux sock_put() + 48 vmlinux tcp6_check_fraglist_gro() + 236 vmlinux tcp6_gro_receive() + 624 vmlinux ipv6_gro_receive() + 912 vmlinux dev_gro_receive() + 1116 vmlinux napi_gro_receive() + 196 ccmni.ko ccmni_rx_callback() + 208 ccmni.ko ccmni_queue_recv_skb() + 388 ccci_dpmaif.ko dpmaif_rxq_push_thread() + 1088 vmlinux kthread() + 268 vmlinux 0xFFFFFFC08001F30C() References: - https://git.kernel.org/stable/c/c0dba059b118b5206e755042b15b49368a388898 - https://git.kernel.org/stable/c/786650e644c5b1c063921799ca203c0b8670d79a - https:
a059b118b5206e755042b15b49368a388898 - https://git.kernel.org/stable/c/786650e644c5b1c063921799ca203c0b8670d79a - https://git.kernel.org/stable/c/f920436a44295ca791ebb6dae3f4190142eec703
CVE ID: CVE-2025-37895 State: PUBLISHED Published: 2025-05-20T15:21:32.045Z Last Updated: 2025-05-26T05:23:13.458Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix error handling path in bnxt_init_chip() WARN_ON() is triggered in __flush_work() if bnxt_init_chip() fails because we call cancel_work_sync() on dim work that has not been initialized. WARNING: CPU: 37 PID: 5223 at kernel/workqueue.c:4201 __flush_work.isra.0+0x212/0x230 The driver relies on the BNXT_STATE_NAPI_DISABLED bit to check if dim work has already been cancelled. But in the bnxt_open() path, BNXT_STATE_NAPI_DISABLED is not set and this causes the e
work has already been cancelled. But in the bnxt_open() path, BNXT_STATE_NAPI_DISABLED is not set and this causes the error path to think that it needs to cancel the uninitalized dim work. Fix it by setting BNXT_STATE_NAPI_DISABLED during initialization. The bit will be cleared when we enable NAPI and initialize dim work. References: - https://git.kernel.org/stable/c/e039b00ddbfeaa0dc59b8659be114f1a1b37c5bf - https://git.kernel.org/stable/c/21116727f452474502ee74f956d5e7466103e19b - https://git.kernel.org/stable/c/9ab7a709c926c16b4433cf02d04fcbcf35aaab2b
CVE ID: CVE-2025-37896 State: PUBLISHED Published: 2025-05-20T15:21:32.685Z Last Updated: 2025-05-26T05:23:14.733Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: spi: spi-mem: Add fix to avoid divide error For some SPI flash memory operations, dummy bytes are not mandatory. For example, in Winbond SPINAND flash memory devices, the `write_cache` and `update_cache` operation variants have zero dummy bytes. Calculating the duration for SPI memory operations with zero dummy bytes causes a divide error when `ncycles` is calculated in the spi_mem_calc_op_duration(). Add changes to skip the 'ncylcles' calculation for zero dummy bytes.
s` is calculated in the spi_mem_calc_op_duration(). Add changes to skip the 'ncylcles' calculation for zero dummy bytes. Following divide error is fixed by this change: Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI ... ? do_trap+0xdb/0x100 ? do_error_trap+0x75/0xb0 ? spi_mem_calc_op_duration+0x56/0xb0 ? exc_divide_error+0x3b/0x70 ? spi_mem_calc_op_duration+0x56/0xb0 ? asm_exc_divide_error+0x1b/0x20 ? spi_mem_calc_op_duration+0x56/0xb0 ? spinand_select_op_variant+0xee/0x190 [spinand] spinand_match_and_init+0x13e/0x1a0 [spinand] spinand_manufacturer_match+0x6e/0xa0 [spinand] spinand_probe+0x357/0x7f0 [spinand] ? kernfs_activate+0x87/0xd0 spi_mem_probe+0x7a/0xb0 spi_probe+0x7d/0x130 Reference
] spinand_probe+0x357/0x7f0 [spinand] ? kernfs_activate+0x87/0xd0 spi_mem_probe+0x7a/0xb0 spi_probe+0x7d/0x130 References: - https://git.kernel.org/stable/c/1915dbd67dadc0bb35670c8e28229baa29368d17 - https://git.kernel.org/stable/c/8e4d3d8a5e51e07bd0d6cdd81b5e4af79f796927
CVE ID: CVE-2025-37897 State: PUBLISHED Published: 2025-05-20T15:21:33.372Z Last Updated: 2025-11-03T19:57:05.151Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: plfxlc: Remove erroneous assert in plfxlc_mac_release plfxlc_mac_release() asserts that mac->lock is held. This assertion is incorrect, because even if it was possible, it would not be the valid behaviour. The function is used when probe fails or after the device is disconnected. In both cases mac->lock can not be held as the driver is not working with the device at the moment. All functions that use mac->lock unlock it just after it was held. There is also no ne
ng with the device at the moment. All functions that use mac->lock unlock it just after it was held. There is also no need to hold mac->lock for plfxlc_mac_release() itself, as mac data is not affected, except for mac->flags, which is modified atomically. This bug leads to the following warning: ================================================================ WARNING: CPU: 0 PID: 127 at drivers/net/wireless/purelifi/plfxlc/mac.c:106 plfxlc_mac_release+0x7d/0xa0 Modules linked in: CPU: 0 PID: 127 Comm: kworker/0:2 Not tainted 6.1.124-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: usb_hub_wq hub_event RIP: 0010:plfxlc_mac_relea
Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: usb_hub_wq hub_event RIP: 0010:plfxlc_mac_release+0x7d/0xa0 drivers/net/wireless/purelifi/plfxlc/mac.c:106 Call Trace: <TASK> probe+0x941/0xbd0 drivers/net/wireless/purelifi/plfxlc/usb.c:694 usb_probe_interface+0x5c0/0xaf0 drivers/usb/core/driver.c:396 really_probe+0x2ab/0xcb0 drivers/base/dd.c:639 __driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785 driver_probe_device+0x50/0x420 drivers/base/dd.c:815 __device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943 bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429 __device_attach+0x359/0x570 drivers/base/dd.c:1015 bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489 device_
/bus.c:429 __device_attach+0x359/0x570 drivers/base/dd.c:1015 bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489 device_add+0xb48/0xfd0 drivers/base/core.c:3696 usb_set_configuration+0x19dd/0x2020 drivers/usb/core/message.c:2165 usb_generic_driver_probe+0x84/0x140 drivers/usb/core/generic.c:238 usb_probe_device+0x130/0x260 drivers/usb/core/driver.c:293 really_probe+0x2ab/0xcb0 drivers/base/dd.c:639 __driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785 driver_probe_device+0x50/0x420 drivers/base/dd.c:815 __device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943 bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429 __device_attach+0x359/0x570 drivers/base/dd.c:1015 bus_probe_device+0xba/0x1e0 d