Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-22076 State: PUBLISHED Published: 2025-04-16T14:12:27.214Z Last Updated: 2025-05-26T05:17:57.120Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: exfat: fix missing shutdown check xfstests generic/730 test failed because after deleting the device that still had dirty data, the file could still be read without returning an error. The reason is the missing shutdown check in ->read_iter. I also noticed that shutdown checks were missing from ->write_iter, ->splice_read, and ->mmap. This commit adds shutdown checks to all of them. References: - https://git.kernel.org/stable/c/4a9595eb024b8319957c178be3cdeed613ac0795
shutdown checks to all of them. References: - https://git.kernel.org/stable/c/4a9595eb024b8319957c178be3cdeed613ac0795 - https://git.kernel.org/stable/c/e41e33eb795cb9c1ead6ac627d8710546fac6e81 - https://git.kernel.org/stable/c/539147585ca453db6e3d7a5cf3b9c9690513762d - https://git.kernel.org/stable/c/47e35366bc6fa3cf189a8305bce63992495f3efa
CVE ID: CVE-2025-22077 State: PUBLISHED Published: 2025-04-16T14:12:27.882Z Last Updated: 2025-05-26T05:17:58.451Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Revert "smb: client: fix TCP timers deadlock after rmmod" This reverts commit e9f2517a3e18a54a3943c098d2226b245d488801. Commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after rmmod") is intended to fix a null-ptr-deref in LOCKDEP, which is mentioned as CVE-2024-54680, but is actually did not fix anything; The issue can be reproduced on top of it. [0] Also, it reverted the change by commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.")
f it. [0] Also, it reverted the change by commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") and introduced a real issue by reviving the kernel TCP socket. When a reconnect happens for a CIFS connection, the socket state transitions to FIN_WAIT_1. Then, inet_csk_clear_xmit_timers_sync() in tcp_close() stops all timers for the socket. If an incoming FIN packet is lost, the socket will stay at FIN_WAIT_1 forever, and such sockets could be leaked up to net.ipv4.tcp_max_orphans. Usually, FIN can be retransmitted by the peer, but if the peer aborts the connection, the issue comes into reality. I warned about this privately by pointing out the exact report [1], but the b
connection, the issue comes into reality. I warned about this privately by pointing out the exact report [1], but the bogus fix was finally merged. So, we should not stop the timers to finally kill the connection on our side in that case, meaning we must not use a kernel socket for TCP whose sk->sk_net_refcnt is 0. The kernel socket does not have a reference to its netns to make it possible to tear down netns without cleaning up every resource in it. For example, tunnel devices use a UDP socket internally, but we can destroy netns without removing such devices and let it complete during exit. Otherwise, netns would be leaked when the last application died. However, this is problematic for T
omplete during exit. Otherwise, netns would be leaked when the last application died. However, this is problematic for TCP sockets because TCP has timers to close the connection gracefully even after the socket is close()d. The lifetime of the socket and its netns is different from the lifetime of the underlying connection. If the socket user does not maintain the netns lifetime, the timer could be fired after the socket is close()d and its netns is freed up, resulting in use-after-free. Actually, we have seen so many similar issues and converted such sockets to have a reference to netns. That's why I converted the CIFS client socket to have a reference to netns (sk->sk_net_refcnt == 1), whi
rence to netns. That's why I converted the CIFS client socket to have a reference to netns (sk->sk_net_refcnt == 1), which is somehow mentioned as out-of-scope of CIFS and technically wrong in e9f2517a3e18, but **is in-scope and right fix**. Regarding the LOCKDEP issue, we can prevent the module unload by bumping the module refcount when switching the LOCKDDEP key in sock_lock_init_class_and_name(). [2] For a while, let's revert the bogus fix. Note that now we can use sk_net_refcnt_upgrade() for the socket conversion, but I'll do so later separately to make backport easy. References: - https://git.kernel.org/stable/c/8dbf060480236877703bff0106fc984576184d11 - https://git.kernel.org/stable/c/
eferences: - https://git.kernel.org/stable/c/8dbf060480236877703bff0106fc984576184d11 - https://git.kernel.org/stable/c/f761eeefd531e6550cd3a5c047835b4892acb00d - https://git.kernel.org/stable/c/4b6f6bf1bde8d6045c389fda8d21c304dfe49384 - https://git.kernel.org/stable/c/95d2b9f693ff2a1180a23d7d59acc0c4e72f4c41
CVE ID: CVE-2025-22078 State: PUBLISHED Published: 2025-04-16T14:12:28.562Z Last Updated: 2025-05-26T05:17:59.735Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: staging: vchiq_arm: Fix possible NPR of keep-alive thread In case vchiq_platform_conn_state_changed() is never called or fails before driver removal, ka_thread won't be a valid pointer to a task_struct. So do the necessary checks before calling kthread_stop to avoid a crash. References: - https://git.kernel.org/stable/c/1817c4b85011998604e5ff9a80a6e01adb7e7e81 - https://git.kernel.org/stable/c/a915c896f95a989a7759a73f8c064f5dc3775175 - https://git.kernel.org/stable/c/b
adb7e7e81 - https://git.kernel.org/stable/c/a915c896f95a989a7759a73f8c064f5dc3775175 - https://git.kernel.org/stable/c/bd38395b901327f77a82112f006240de22cf2ceb - https://git.kernel.org/stable/c/3db89bc6d973e2bcaa852f6409c98c228f39a926
CVE ID: CVE-2025-22079 State: PUBLISHED Published: 2025-04-16T14:12:29.215Z Last Updated: 2025-11-03T19:41:59.218Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate l_tree_depth to avoid out-of-bounds access The l_tree_depth field is 16-bit (__le16), but the actual maximum depth is limited to OCFS2_MAX_PATH_DEPTH. Add a check to prevent out-of-bounds access if l_tree_depth has an invalid value, which may occur when reading from a corrupted mounted disk [1]. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/ef34840bda333fe99bafbd2d73b70ceaaf9eba66 - https://git.kernel.o
Container: References: - https://git.kernel.org/stable/c/ef34840bda333fe99bafbd2d73b70ceaaf9eba66 - https://git.kernel.org/stable/c/538ed8b049ef801a86c543433e5061a91cc106e3 - https://git.kernel.org/stable/c/17c99ab3db2ba74096d36c69daa6e784e98fc0b8 - https://git.kernel.org/stable/c/11e24802e73362aa2948ee16b8fb4e32635d5b2a - https://git.kernel.org/stable/c/3d012ba4404a0bb517658699ba85e6abda386dc3 - https://git.kernel.org/stable/c/49d2a2ea9d30991bae82107f9523915b91637683 - https://git.kernel.org/stable/c/b942f88fe7d2d789e51c5c30a675fa1c126f5a6d - https://git.kernel.org/stable/c/e95d97c9c8cd0c239b7b59c79be0f6a9dcf7905c - https://git.kernel.org/stable/c/a406aff8c05115119127c962cbbbbd202e1973ef
CVE ID: CVE-2025-22080 State: PUBLISHED Published: 2025-04-16T14:12:29.886Z Last Updated: 2025-10-01T16:15:44.922Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Prevent integer overflow in hdr_first_de() The "de_off" and "used" variables come from the disk so they both need to check. The problem is that on 32bit systems if they're both greater than UINT_MAX - 16 then the check does work as intended because of an integer overflow. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f6d44b1aa46d317e52c21fb9314cfb20dd69e7b0 - https://git.kernel.org/stable/c/201a2bdda13b619c49
://git.kernel.org/stable/c/f6d44b1aa46d317e52c21fb9314cfb20dd69e7b0 - https://git.kernel.org/stable/c/201a2bdda13b619c4927700ffe47d387a30ced50 - https://git.kernel.org/stable/c/85615aa442830027923fc690390fa74d17b36ae1 - https://git.kernel.org/stable/c/b9982065b82b4177ba3a7a72ce18c84921f7494d - https://git.kernel.org/stable/c/6bb81b94f7a9cba6bde9a905cef52a65317a8b04
CVE ID: CVE-2025-22081 State: PUBLISHED Published: 2025-04-16T14:12:30.850Z Last Updated: 2025-11-03T19:42:00.625Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix a couple integer overflows on 32bit systems On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can have an integer wrapping issue. Fix it by using size_add(). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/0922d86a7a6032cb1694eab0b44b861bd33ba8d5 - https://git.kernel.org/stable/c/1a14e9718a19d2e88de004a1360bfd7a86ed1395 - https://git.kernel.org/stable/c/0dfe700fbd3525f30a
://git.kernel.org/stable/c/1a14e9718a19d2e88de004a1360bfd7a86ed1395 - https://git.kernel.org/stable/c/0dfe700fbd3525f30a36ffbe390a5b9319bd009a - https://git.kernel.org/stable/c/284c9549386e9883855fb82b730303bb2edea9de - https://git.kernel.org/stable/c/0538f52410b619737e663167b6a2b2d0bc1a589d - https://git.kernel.org/stable/c/4d0f4f42922a832388a0c2fe5204c0a1037ff786 - https://git.kernel.org/stable/c/5ad414f4df2294b28836b5b7b69787659d6aa708
CVE ID: CVE-2025-22082 State: PUBLISHED Published: 2025-04-16T14:12:31.529Z Last Updated: 2025-05-26T05:18:05.746Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iio: backend: make sure to NULL terminate stack buffer Make sure to NULL terminate the buffer in iio_backend_debugfs_write_reg() before passing it to sscanf(). It is a stack variable so we should not assume it will 0 initialized. References: - https://git.kernel.org/stable/c/df3892e5e861c43d5612728ed259634675b8a71f - https://git.kernel.org/stable/c/04271a4d2740f98bbe36f82cd3d74677a839d1eb - https://git.kernel.org/stable/c/fd791c81f410ab1c554686a6f486dc7a176dfe35 - http
271a4d2740f98bbe36f82cd3d74677a839d1eb - https://git.kernel.org/stable/c/fd791c81f410ab1c554686a6f486dc7a176dfe35 - https://git.kernel.org/stable/c/035b4989211dc1c8626e186d655ae8ca5141bb73
CVE ID: CVE-2025-22083 State: PUBLISHED Published: 2025-04-16T14:12:32.291Z Last Updated: 2025-05-26T05:18:07.054Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang: 1. Use-after-free when no tpgs are found: This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tp
ce and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do: vhost_vq_set_backend(vq, vs_tpg); ... kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via: kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If a scsi request is then sent we do: vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend which sees the vs_tpg we just did a kfree on. 2. Tpg dir removal hang: This patch fixes an issue where we cannot remove a LIO/targ
the vs_tpg we just did a kfree on. 2. Tpg dir removal hang: This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1. The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg. Later, when vhost_scsi_clear_endpoint run
call as well as tpgs we added in previous calls which are also in vs->vs_tpg. Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir. 3. Tpg leak: This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names. The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again w
VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs. Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times w
d_item on the tpgs. Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first. References: - https://git.kernel.org/stable/c/2b34bdc42df047794542f3e220fe989124e4499a - https://git.kernel.org/stable/c/3a19eb3d9818e28f14c818a18dc913344a52ca92 - https://git.kernel.org/stable/c/3fd054baf382a426bbf5135ede0fc5673db74d3e - https://git.kernel.org/sta
8dc913344a52ca92 - https://git.kernel.org/stable/c/3fd054baf382a426bbf5135ede0fc5673db74d3e - https://git.kernel.org/stable/c/63b449f73ab0dcc0ba11ceaa4c5c70bc86ccf03c - https://git.kernel.org/stable/c/5dd639a1646ef5fe8f4bf270fad47c5c3755b9b6
CVE ID: CVE-2025-22084 State: PUBLISHED Published: 2025-04-16T14:12:32.950Z Last Updated: 2025-05-26T05:18:08.278Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: w1: fix NULL pointer dereference in probe The w1_uart_probe() function calls w1_uart_serdev_open() (which includes devm_serdev_device_open()) before setting the client ops via serdev_device_set_client_ops(). This ordering can trigger a NULL pointer dereference in the serdev controller's receive_buf handler, as it assumes serdev->ops is valid when SERPORT_ACTIVE is set. This is similar to the issue fixed in commit 5e700b384ec1 ("platform/chrome: cros_ec_uart: properly f
ORT_ACTIVE is set. This is similar to the issue fixed in commit 5e700b384ec1 ("platform/chrome: cros_ec_uart: properly fix race condition") where devm_serdev_device_open() was called before fully initializing the device. Fix the race by ensuring client ops are set before enabling the port via w1_uart_serdev_open(). References: - https://git.kernel.org/stable/c/4f750b84628080ff0d67bf1af67a4967b740acf2 - https://git.kernel.org/stable/c/64ab50577c59bb7049bec6b5c42d1c38e4029f29 - https://git.kernel.org/stable/c/cc6b0ec7cccbf66ef3621e9e93296b7bd1f52298 - https://git.kernel.org/stable/c/0dd6770a72f138dabea9eae87f3da6ffa68f0d06
CVE ID: CVE-2025-22085 State: PUBLISHED Published: 2025-04-16T14:12:33.821Z Last Updated: 2025-05-26T05:18:09.541Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix use-after-free when rename device name Syzbot reported a slab-use-after-free with the following call trace: ================================================================== BUG: KASAN: slab-use-after-free in nla_put+0xd3/0x150 lib/nlattr.c:1099 Read of size 5 at addr ffff888140ea1c60 by task syz.0.988/10025 CPU: 0 UID: 0 PID: 10025 Comm: syz.0.988 Not tainted 6.14.0-rc4-syzkaller-00859-gf77f12010f67 #0 Hardware name: Google Compute Engine, BIOS Google
mm: syz.0.988 Not tainted 6.14.0-rc4-syzkaller-00859-gf77f12010f67 #0 Hardware name: Google Compute Engine, BIOS Google 02/12/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0x16e/0x5b0 mm/kasan/report.c:521 kasan_report+0x143/0x180 mm/kasan/report.c:634 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 nla_put+0xd3/0x150 lib/nlattr.c:1099 nla_put_string include/net/netlink.h:1621 [inline] fill_nldev_handle+0x16e/0x200 drivers/infiniband/core/nldev.c:265 rdma_nl_notify_event+0x561/0xef0 drivers/infiniband/core
ll_nldev_handle+0x16e/0x200 drivers/infiniband/core/nldev.c:265 rdma_nl_notify_event+0x561/0xef0 drivers/infiniband/core/nldev.c:2857 ib_device_notify_register+0x22/0x230 drivers/infiniband/core/device.c:1344 ib_register_device+0x1292/0x1460 drivers/infiniband/core/device.c:1460 rxe_register_device+0x233/0x350 drivers/infiniband/sw/rxe/rxe_verbs.c:1540 rxe_net_add+0x74/0xf0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0xde/0x1a0 drivers/infiniband/sw/rxe/rxe.c:212 nldev_newlink+0x5ea/0x680 drivers/infiniband/core/nldev.c:1795 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0x6dd/0x9e0 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/a
etlink.c:239 [inline] rdma_nl_rcv+0x6dd/0x9e0 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:709 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:724 ____sys_sendmsg+0x53a/0x860 net/socket.c:2564 ___sys_sendmsg net/socket.c:2618 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2650 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f42d1b8d169 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f
.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f42d1b8d169 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 ... RSP: 002b:00007f42d2960038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f42d1da6320 RCX: 00007f42d1b8d169 RDX: 0000000000000000 RSI: 00004000000002c0 RDI: 000000000000000c RBP: 00007f42d1c0e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f42d1da6320 R15: 00007ffe399344a8 </TASK> Allocated by task 10025: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/
asan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4294 [inline] __kmalloc_node_track_caller_noprof+0x28b/0x4c0 mm/slub.c:4313 __kmemdup_nul mm/util.c:61 [inline] kstrdup+0x42/0x100 mm/util.c:81 kobject_set_name_vargs+0x61/0x120 lib/kobject.c:274 dev_set_name+0xd5/0x120 drivers/base/core.c:3468 assign_name drivers/infiniband/core/device.c:1202 [inline] ib_register_device+0x178/0x1460 drivers/infiniband/core/device.c:1384 rxe_register_device+0x233/0x350 drivers/infiniband/sw
register_device+0x178/0x1460 drivers/infiniband/core/device.c:1384 rxe_register_device+0x233/0x350 drivers/infiniband/sw/rxe/rxe_verbs.c:1540 rxe_net_add+0x74/0xf0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0xde/0x1a0 drivers/infiniband/sw/rxe/rxe.c:212 nldev_newlink+0x5ea/0x680 drivers/infiniband/core/nldev.c:1795 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0x6dd/0x9e0 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8de/0xcb0 net ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kern
endmsg+0x8de/0xcb0 net ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0d6460b9d2a3ee380940bdf47680751ef91cb88e - https://git.kernel.org/stable/c/56ec8580be5174b2b9774066e60f1aad56d201db - https://git.kernel.org/stable/c/edf6b543e81ba68c6dbac2499ab362098a5a9716 - https://git.kernel.org/stable/c/1d6a9e7449e2a0c1e2934eee7880ba8bd1e464cd
CVE ID: CVE-2025-22086 State: PUBLISHED Published: 2025-04-16T14:12:34.560Z Last Updated: 2025-11-03T19:42:06.134Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow When cur_qp isn't NULL, in order to avoid fetching the QP from the radix tree again we check if the next cqe QP is identical to the one we already have. The bug however is that we are checking if the QP is identical by checking the QP number inside the CQE against the QP number inside the mlx5_ib_qp, but that's wrong since the QP number from the CQE is from FW so it should be matched against mlx5_core_qp which is our FW
ut that's wrong since the QP number from the CQE is from FW so it should be matched against mlx5_core_qp which is our FW QP number. Otherwise we could use the wrong QP when handling a CQE which could cause the kernel trace below. This issue is mainly noticeable over QPs 0 & 1, since for now they are the only QPs in our driver whereas the QP number inside mlx5_ib_qp doesn't match the QP number inside mlx5_core_qp. BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU St
ops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000
: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: <TASK> ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] __ib_process_cq+0x5a/0x150 [ib_core] i