Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
reason+0x7e/0x1f0 Call Trace: <IRQ> skb_release_data+0xf9/0x1d0 kfree_skb_reason+0x40/0x100 tipc_link_xmit+0x57a/0x740 [tipc] tipc_node_xmit+0x16c/0x5c0 [tipc] tipc_named_node_up+0x27f/0x2c0 [tipc] tipc_node_write_unlock+0x149/0x170 [tipc] tipc_rcv+0x608/0x740 [tipc] tipc_udp_recv+0xdc/0x1f0 [tipc] udp_queue_rcv_one_skb+0x33e/0x620 udp_unicast_rcv_skb.isra.72+0x75/0x90 __udp4_lib_rcv+0x56d/0xc20 ip_protocol_deliver_rcu+0x100/0x2d0 This patch fixes it by checking the new mtu against tipc_bearer_min_mtu(), and not updating mtu if it is too small. References: - https://git.kernel.org/stable/c/2bd4ff4ffb92113f8acd04dbaed83269172c24b4 - https://git.kernel.org/stable/c/575e84d90a74c0b091b3417ba763
nel.org/stable/c/2bd4ff4ffb92113f8acd04dbaed83269172c24b4 - https://git.kernel.org/stable/c/575e84d90a74c0b091b3417ba763ebb237aa0a8c - https://git.kernel.org/stable/c/259683001d7e879fea4b42084fb6560dd9408a7e - https://git.kernel.org/stable/c/1dd7ae5e0cf5a56e513f7ab7ab9570b7496281d2 - https://git.kernel.org/stable/c/56077b56cd3fb78e1c8619e29581ba25a5c55e86
CVE ID: CVE-2023-53518 State: PUBLISHED Published: 2025-10-01T11:46:05.446Z Last Updated: 2025-10-01T11:46:05.446Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Fix leak in devfreq_dev_release() srcu_init_notifier_head() allocates resources that need to be released with a srcu_cleanup_notifier_head() call. Reported by kmemleak. References: - https://git.kernel.org/stable/c/7462483446cb9986568ad7adae746ce5f18d2968 - https://git.kernel.org/stable/c/64e6e0dc2d578c0a9e31cb4edd719f0a3ed98f6d - https://git.kernel.org/stable/c/29811f4b8255d4238cf326f3bb7129784766beab - https://git.kernel.org/stable/c/ab192e5e5d3b4841590
//git.kernel.org/stable/c/29811f4b8255d4238cf326f3bb7129784766beab - https://git.kernel.org/stable/c/ab192e5e5d3b48415909a8408acfd007a607bcc0 - https://git.kernel.org/stable/c/111bafa210ae546bee7644be730c42df9c35b66e - https://git.kernel.org/stable/c/8918025feb2f5f7c73f2495c158f22997e25cb02 - https://git.kernel.org/stable/c/1640e9c72173911ad0fddb05012c01eafe082c4e - https://git.kernel.org/stable/c/3354c401c68d70567d1ef25d12f4e22a7813a3c6 - https://git.kernel.org/stable/c/5693d077595de721f9ddbf9d37f40e5409707dfe
CVE ID: CVE-2023-53519 State: PUBLISHED Published: 2025-10-01T11:46:06.419Z Last Updated: 2025-10-01T11:46:06.419Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: v4l2-mem2mem: add lock to protect parameter num_rdy Getting below error when using KCSAN to check the driver. Adding lock to protect parameter num_rdy when getting the value with function: v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready. kworker/u16:3: [name:report&]BUG: KCSAN: data-race in v4l2_m2m_buf_queue kworker/u16:3: [name:report&] kworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7: kworker/u16:3: v4l2_
&] kworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7: kworker/u16:3: v4l2_m2m_buf_queue+0xd8/0x10c References: - https://git.kernel.org/stable/c/690dd4780b3f4d755e4e7883e8c3d1b5052f6bf2 - https://git.kernel.org/stable/c/7fc7f87725805197388ba749a1801df33000fa50 - https://git.kernel.org/stable/c/ef009fe2010ea2a3a7045ecb72729cf366e0967b - https://git.kernel.org/stable/c/e52de26cb37459b16213438a2c82feb155dd3bbd - https://git.kernel.org/stable/c/1676748aa29099fc0abd71e0fb092e76e835f25c - https://git.kernel.org/stable/c/c71aa5f1cf961264690f2560503ea396b6e3c680 - https://git.kernel.org/stable/c/e01ea1c4191ee08440b5f86db98dff695e9cedf9 - https://git.kern
64690f2560503ea396b6e3c680 - https://git.kernel.org/stable/c/e01ea1c4191ee08440b5f86db98dff695e9cedf9 - https://git.kernel.org/stable/c/56b5c3e67b0f9af3f45cf393be048ee8d8a92694
CVE ID: CVE-2023-53520 State: PUBLISHED Published: 2025-10-01T11:46:07.355Z Last Updated: 2025-10-01T11:46:07.355Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix hci_suspend_sync crash If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier may still be accessing it, it can cause the program to crash. Here's the call trace: <4>[102152.653246] Call Trace: <4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271
52.653263] hci_suspend_notifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 This p
0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 This patch holds the reference count of the hci_dev object while processing it in hci_suspend_notifier to avoid potential crash caused by the race condition. References: - https://git.kernel.org/stable/c/06e2b5ad72b60f90bfe565c201346532e271f484 - https://git.kernel.org/stable/c/f9c8ce5d665653e3cf71a76349d41d7a7f7947e6 - https://git.kernel.org/stable/c/573ebae162111063eedc6c838a659ba628f66a0f
CVE ID: CVE-2023-53521 State: PUBLISHED Published: 2025-10-01T11:46:08.131Z Last Updated: 2025-10-01T11:46:08.131Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: ses: Fix slab-out-of-bounds in ses_intf_remove() A fix for: BUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses] Read of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013 When edev->components is zero, accessing edev->component[0] members is wrong. References: - https://git.kernel.org/stable/c/76f7050537476ac062ec23a544fbca8270f2d08b - https://git.kernel.org/stable/c/87e47be38d205df338c52ead43f23b2864567423 - https://git.kernel.org/stable/c/40af9
2d08b - https://git.kernel.org/stable/c/87e47be38d205df338c52ead43f23b2864567423 - https://git.kernel.org/stable/c/40af9a6deed723485e05b7d3255a28750692e8db - https://git.kernel.org/stable/c/8f9542cad6c27297c8391de3a659f0b7948495d0 - https://git.kernel.org/stable/c/0595cdb587726b4f0fa780eb7462e3679d141e82 - https://git.kernel.org/stable/c/82143faf01dda831b89eccef60c39ef8575ab08a - https://git.kernel.org/stable/c/2fb1fa8425cce2dc4dce298275d22d7077694b73 - https://git.kernel.org/stable/c/578797f0c8cbc2e3ec5fc0dab87087b4c7073686
CVE ID: CVE-2023-53522 State: PUBLISHED Published: 2025-10-01T11:46:08.909Z Last Updated: 2025-10-01T11:46:08.909Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cgroup,freezer: hold cpu_hotplug_lock before freezer_mutex syzbot is reporting circular locking dependency between cpu_hotplug_lock and freezer_mutex, for commit f5d39b020809 ("freezer,sched: Rewrite core freezer logic") replaced atomic_inc() in freezer_apply_state() with static_branch_inc() which holds cpu_hotplug_lock. cpu_hotplug_lock => cgroup_threadgroup_rwsem => freezer_mutex cgroup_file_write() { cgroup_procs_write() { __cgroup_procs_write() { cgroup_procs_write
eadgroup_rwsem => freezer_mutex cgroup_file_write() { cgroup_procs_write() { __cgroup_procs_write() { cgroup_procs_write_start() { cgroup_attach_lock() { cpus_read_lock() { percpu_down_read(&cpu_hotplug_lock); } percpu_down_write(&cgroup_threadgroup_rwsem); } } cgroup_attach_task() { cgroup_migrate() { cgroup_migrate_execute() { freezer_attach() { mutex_lock(&freezer_mutex); (...snipped...) } } } } (...snipped...) } } } freezer_mutex => cpu_hotplug_lock cgroup_file_write() { freezer_write() { freezer_change_state() { mutex_lock(&freezer_mutex); freezer_apply_state() { static_branch_inc(&freezer_active) { static_key_slow_inc() { cpus_read_lock(); static_key_slow_inc_cpuslocked(); cpus_read_un
c_branch_inc(&freezer_active) { static_key_slow_inc() { cpus_read_lock(); static_key_slow_inc_cpuslocked(); cpus_read_unlock(); } } } mutex_unlock(&freezer_mutex); } } } Swap locking order by moving cpus_read_lock() in freezer_apply_state() to before mutex_lock(&freezer_mutex) in freezer_change_state(). References: - https://git.kernel.org/stable/c/3756171b97c307d9df8b8ded1d883eec30172085 - https://git.kernel.org/stable/c/34fbb7b45bae20b551dda24337c7761ca13ce69d - https://git.kernel.org/stable/c/57dcd64c7e036299ef526b400a8d12b8a2352f26
CVE ID: CVE-2023-53523 State: PUBLISHED Published: 2025-10-01T11:46:09.632Z Last Updated: 2025-10-01T11:46:09.632Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: fix time stamp counter initialization If the gs_usb device driver is unloaded (or unbound) before the interface is shut down, the USB stack first calls the struct usb_driver::disconnect and then the struct net_device_ops::ndo_stop callback. In gs_usb_disconnect() all pending bulk URBs are killed, i.e. no more RX'ed CAN frames are send from the USB device to the host. Later in gs_can_close() a reset control message is send to each CAN channel to remove the
m the USB device to the host. Later in gs_can_close() a reset control message is send to each CAN channel to remove the controller from the CAN bus. In this race window the USB device can still receive CAN frames from the bus and internally queue them to be send to the host. At least in the current version of the candlelight firmware, the queue of received CAN frames is not emptied during the reset command. After loading (or binding) the gs_usb driver, new URBs are submitted during the struct net_device_ops::ndo_open callback and the candlelight firmware starts sending its already queued CAN frames to the host. However, this scenario was not considered when implementing the hardware timestam
already queued CAN frames to the host. However, this scenario was not considered when implementing the hardware timestamp function. The cycle counter/time counter infrastructure is set up (gs_usb_timestamp_init()) after the USBs are submitted, resulting in a NULL pointer dereference if timecounter_cyc2time() (via the call chain: gs_usb_receive_bulk_callback() -> gs_usb_set_timestamp() -> gs_usb_skb_set_timestamp()) is called too early. Move the gs_usb_timestamp_init() function before the URBs are submitted to fix this problem. For a comprehensive solution, we need to consider gs_usb devices with more than 1 channel. The cycle counter/time counter infrastructure is setup per channel, but the
er gs_usb devices with more than 1 channel. The cycle counter/time counter infrastructure is setup per channel, but the RX URBs are per device. Once gs_can_open() of _a_ channel has been called, and URBs have been submitted, the gs_usb_receive_bulk_callback() can be called for _all_ available channels, even for channels that are not running, yet. As cycle counter/time counter has not set up, this will again lead to a NULL pointer dereference. Convert the cycle counter/time counter from a "per channel" to a "per device" functionality. Also set it up, before submitting any URBs to the device. Further in gs_usb_receive_bulk_callback(), don't process any URBs for not started CAN channels, only r
Bs to the device. Further in gs_usb_receive_bulk_callback(), don't process any URBs for not started CAN channels, only resubmit the URB. References: - https://git.kernel.org/stable/c/210a8cffc9c1b044281c0a868485c870c9c11374 - https://git.kernel.org/stable/c/5886e4d5ecec3e22844efed90b2dd383ef804b3a
CVE ID: CVE-2023-53524 State: PUBLISHED Published: 2025-10-01T11:46:10.397Z Last Updated: 2025-10-01T11:46:10.397Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: pcie: Fix integer overflow in iwl_write_to_user_buf An integer overflow occurs in the iwl_write_to_user_buf() function, which is called by the iwl_dbgfs_monitor_data_read() function. static bool iwl_write_to_user_buf(char __user *user_buf, ssize_t count, void *buf, ssize_t *size, ssize_t *bytes_copied) { int buf_size_left = count - *bytes_copied; buf_size_left = buf_size_left - (buf_size_left % sizeof(u32)); if (*size > buf_size_left) *size = buf_size_le
es_copied; buf_size_left = buf_size_left - (buf_size_left % sizeof(u32)); if (*size > buf_size_left) *size = buf_size_left; If the user passes a SIZE_MAX value to the "ssize_t count" parameter, the ssize_t count parameter is assigned to "int buf_size_left". Then compare "*size" with "buf_size_left" . Here, "buf_size_left" is a negative number, so "*size" is assigned "buf_size_left" and goes into the third argument of the copy_to_user function, causing a heap overflow. This is not a security vulnerability because iwl_dbgfs_monitor_data_read() is a debugfs operation with 0400 privileges. References: - https://git.kernel.org/stable/c/0ad8dd870aa187d0c21d032bb2c6433559075eec - https://git.kernel
privileges. References: - https://git.kernel.org/stable/c/0ad8dd870aa187d0c21d032bb2c6433559075eec - https://git.kernel.org/stable/c/059e426d666a41e26b184c177c1ca3ee2d6fa1b6 - https://git.kernel.org/stable/c/82f877ec9b041edc4c7c509c605cc3393d837bf0 - https://git.kernel.org/stable/c/eb1ef44efac797b384d361a76e33f77027c29a14 - https://git.kernel.org/stable/c/de78456976026102babe66258c228691ca5677c0 - https://git.kernel.org/stable/c/58d1b717879bfeabe09b35e41ad667c79933eb2e
CVE ID: CVE-2023-53525 State: PUBLISHED Published: 2025-10-01T11:46:11.188Z Last Updated: 2025-10-01T11:46:11.188Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Allow UD qp_type to join multicast only As for multicast: - The SIDR is the only mode that makes sense; - Besides PS_UDP, other port spaces like PS_IB is also allowed, as it is UD compatible. In this case qkey also needs to be set [1]. This patch allows only UD qp_type to join multicast, and set qkey to default if it's not set, to fix an uninit-value error: the ib->rec.qkey field is accessed without being initialized. =========================================
nit-value error: the ib->rec.qkey field is accessed without being initialized. ===================================================== BUG: KMSAN: uninit-value in cma_set_qkey drivers/infiniband/core/cma.c:510 [inline] BUG: KMSAN: uninit-value in cma_make_mc_event+0xb73/0xe00 drivers/infiniband/core/cma.c:4570 cma_set_qkey drivers/infiniband/core/cma.c:510 [inline] cma_make_mc_event+0xb73/0xe00 drivers/infiniband/core/cma.c:4570 cma_iboe_join_multicast drivers/infiniband/core/cma.c:4782 [inline] rdma_join_multicast+0x2b83/0x30a0 drivers/infiniband/core/cma.c:4814 ucma_process_join+0xa76/0xf60 drivers/infiniband/core/ucma.c:1479 ucma_join_multicast+0x1e3/0x250 drivers/infiniband/core/ucma.c:154
_join+0xa76/0xf60 drivers/infiniband/core/ucma.c:1479 ucma_join_multicast+0x1e3/0x250 drivers/infiniband/core/ucma.c:1546 ucma_write+0x639/0x6d0 drivers/infiniband/core/ucma.c:1732 vfs_write+0x8ce/0x2030 fs/read_write.c:588 ksys_write+0x28c/0x520 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __ia32_sys_write+0xdb/0x120 fs/read_write.c:652 do_syscall_32_irqs_on arch/x86/entry/common.c:114 [inline] __do_fast_syscall_32+0x96/0xf0 arch/x86/entry/common.c:180 do_fast_syscall_32+0x34/0x70 arch/x86/entry/common.c:205 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:248 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c Local variable ib.i cre
_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:248 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c Local variable ib.i created at: cma_iboe_join_multicast drivers/infiniband/core/cma.c:4737 [inline] rdma_join_multicast+0x586/0x30a0 drivers/infiniband/core/cma.c:4814 ucma_process_join+0xa76/0xf60 drivers/infiniband/core/ucma.c:1479 CPU: 0 PID: 29874 Comm: syz-executor.3 Not tainted 5.16.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 ===================================================== [1] https://lore.kernel.org/linux-rdma/20220117183832.GD84788@nvidia.com/ References: - https://git.kernel.org/stable/c/ae11498851423d6de27aebfe12a5ee
nux-rdma/20220117183832.GD84788@nvidia.com/ References: - https://git.kernel.org/stable/c/ae11498851423d6de27aebfe12a5ee85060ab1d5 - https://git.kernel.org/stable/c/48e8e7851dc0b1584d83817a78fc7108c8904b54 - https://git.kernel.org/stable/c/02eabb635bc64bd1e3a7cf887d6d182bffb64b99 - https://git.kernel.org/stable/c/bb18b9dbac2bbdf7695e0bfaac4bf944ff7b207d - https://git.kernel.org/stable/c/58e84f6b3e84e46524b7e5a916b53c1ad798bc8f
CVE ID: CVE-2023-53526 State: PUBLISHED Published: 2025-10-01T11:46:11.862Z Last Updated: 2025-10-01T11:46:11.862Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: jbd2: check 'jh->b_transaction' before removing it from checkpoint Following process will corrupt ext4 image: Step 1: jbd2_journal_commit_transaction __jbd2_journal_insert_checkpoint(jh, commit_transaction) // Put jh into trans1->t_checkpoint_list journal->j_checkpoint_transactions = commit_transaction // Put trans1 into journal->j_checkpoint_transactions Step 2: do_get_write_access test_clear_buffer_dirty(bh) // clear buffer dirty，set jbd dirty __jbd2_journal_file_buf
ions Step 2: do_get_write_access test_clear_buffer_dirty(bh) // clear buffer dirty，set jbd dirty __jbd2_journal_file_buffer(jh, transaction) // jh belongs to trans2 Step 3: drop_cache journal_shrink_one_cp_list jbd2_journal_try_remove_checkpoint if (!trylock_buffer(bh)) // lock bh, true if (buffer_dirty(bh)) // buffer is not dirty __jbd2_journal_remove_checkpoint(jh) // remove jh from trans1->t_checkpoint_list Step 4: jbd2_log_do_checkpoint trans1 = journal->j_checkpoint_transactions // jh is not in trans1->t_checkpoint_list jbd2_cleanup_journal_tail(journal) // trans1 is done Step 5: Power cut, trans2 is not committed, jh is lost in next mounting. Fix it by checking 'jh->b_transaction' befo
one Step 5: Power cut, trans2 is not committed, jh is lost in next mounting. Fix it by checking 'jh->b_transaction' before remove it from checkpoint. References: - https://git.kernel.org/stable/c/ef5fea70e5915afd64182d155e72bfb4f275e1fc - https://git.kernel.org/stable/c/dbafe636db415299e54d9dfefc1003bda9e71c9d - https://git.kernel.org/stable/c/2298f2589903a8bc03061b54b31fd97985ab6529 - https://git.kernel.org/stable/c/590a809ff743e7bd890ba5fb36bc38e20a36de53
CVE ID: CVE-2023-53527 State: PUBLISHED Published: 2025-10-01T11:46:12.696Z Last Updated: 2025-10-01T11:46:12.696Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix memory leak in tb_handle_dp_bandwidth_request() The memory allocated in tb_queue_dp_bandwidth_request() needs to be released once the request is handled to avoid leaking it. References: - https://git.kernel.org/stable/c/0752bb32aed2c5dd85821195a507a1079c4835f7 - https://git.kernel.org/stable/c/596a5123cc782d458b057eb3837e66535cd0befa
CVE ID: CVE-2023-53528 State: PUBLISHED Published: 2025-10-01T11:46:13.504Z Last Updated: 2025-10-01T11:46:13.504Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix unsafe drain work queue code If create_qp does not fully succeed it is possible for qp cleanup code to attempt to drain the send or recv work queues before the queues have been created causing a seg fault. This patch checks to see if the queues exist before attempting to drain them. References: - https://git.kernel.org/stable/c/da572f6313aeead1f79e0810666bd8d8ffc794d4 - https://git.kernel.org/stable/c/d366642b3099bd322375f5b71ba84ab1d586cd6d - https://git
3aeead1f79e0810666bd8d8ffc794d4 - https://git.kernel.org/stable/c/d366642b3099bd322375f5b71ba84ab1d586cd6d - https://git.kernel.org/stable/c/5993b75d0bc71cd2b441d174b028fc36180f032c
CVE ID: CVE-2023-53529 State: PUBLISHED Published: 2025-10-01T11:46:14.358Z Last Updated: 2025-10-02T07:04:30.330Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: Fix memory leak in rtw88_usb Kmemleak shows the following leak arising from routine in the usb probe routine: unreferenced object 0xffff895cb29bba00 (size 512): comm "(udev-worker)", pid 534, jiffies 4294903932 (age 102751.088s) hex dump (first 32 bytes): 77 30 30 30 00 00 00 00 02 2f 2d 2b 30 00 00 00 w000...../-+0... 02 00 2a 28 00 00 00 00 ff 55 ff ff ff 00 00 00 ..*(.....U...... backtrace: [<ffffffff9265fa36>] kmalloc_trace+0x26/0x90 [<ffffffffc17eec41
0 00 ff 55 ff ff ff 00 00 00 ..*(.....U...... backtrace: [<ffffffff9265fa36>] kmalloc_trace+0x26/0x90 [<ffffffffc17eec41>] rtw_usb_probe+0x2f1/0x680 [rtw_usb] [<ffffffffc03e19fd>] usb_probe_interface+0xdd/0x2e0 [usbcore] [<ffffffff92b4f2fe>] really_probe+0x18e/0x3d0 [<ffffffff92b4f5b8>] __driver_probe_device+0x78/0x160 [<ffffffff92b4f6bf>] driver_probe_device+0x1f/0x90 [<ffffffff92b4f8df>] __driver_attach+0xbf/0x1b0 [<ffffffff92b4d350>] bus_for_each_dev+0x70/0xc0 [<ffffffff92b4e51e>] bus_add_driver+0x10e/0x210 [<ffffffff92b50935>] driver_register+0x55/0xf0 [<ffffffffc03e0708>] usb_register_driver+0x88/0x140 [usbcore] [<ffffffff92401153>] do_one_initcall+0x43/0x210 [<ffffffff9254f42a>] do_ini
8>] usb_register_driver+0x88/0x140 [usbcore] [<ffffffff92401153>] do_one_initcall+0x43/0x210 [<ffffffff9254f42a>] do_init_module+0x4a/0x200 [<ffffffff92551d1c>] __do_sys_finit_module+0xac/0x120 [<ffffffff92ee6626>] do_syscall_64+0x56/0x80 [<ffffffff9300006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 The leak was verified to be real by unloading the driver, which resulted in a dangling pointer to the allocation. The allocated memory is freed in rtw_usb_intf_deinit(). References: - https://git.kernel.org/stable/c/5bba1ad561a8b5bb14704d8f511cf10466336e3d - https://git.kernel.org/stable/c/59a3a312009723e3e5082899655fdcc420e2b47a
CVE ID: CVE-2023-53530 State: PUBLISHED Published: 2025-10-01T11:46:15.075Z Last Updated: 2025-10-01T11:46:15.075Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Use raw_smp_processor_id() instead of smp_processor_id() The following call trace was observed: localhost kernel: nvme nvme0: NVME-FC{0}: controller connect complete localhost kernel: BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u129:4/75092 localhost kernel: nvme nvme0: NVME-FC{0}: new ctrl: NQN "nqn.1992-08.com.netapp:sn.b42d198afb4d11ecad6d00a098d6abfa:subsystem.PR_Channel2022_RH84_subsystem_291" localhost kernel: caller is ql
m.netapp:sn.b42d198afb4d11ecad6d00a098d6abfa:subsystem.PR_Channel2022_RH84_subsystem_291" localhost kernel: caller is qla_nvme_post_cmd+0x216/0x1380 [qla2xxx] localhost kernel: CPU: 6 PID: 75092 Comm: kworker/u129:4 Kdump: loaded Tainted: G B W OE --------- --- 5.14.0-70.22.1.el9_0.x86_64+debug #1 localhost kernel: Hardware name: HPE ProLiant XL420 Gen10/ProLiant XL420 Gen10, BIOS U39 01/13/2022 localhost kernel: Workqueue: nvme-wq nvme_async_event_work [nvme_core] localhost kernel: Call Trace: localhost kernel: dump_stack_lvl+0x57/0x7d localhost kernel: check_preemption_disabled+0xc8/0xd0 localhost kernel: qla_nvme_post_cmd+0x216/0x1380 [qla2xxx] Use raw_smp_processor_id() instead of smp_pr