Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow<br /> <br /> When cur_qp isn&amp;#39;t NULL, in order to avoid fetching the QP from<br /> the radix tree again we check if the next cqe QP is identical to<br /> the one we already have.<br /> <br /> The bug however is that we are checking if the QP is identical by<br /> checking the QP number inside the CQE against the QP number inside the<br /> mlx5_ib_qp, but that&amp;#39;s wrong since the QP number from the CQE is from<br /> FW so it should be matched against mlx5_core_qp which is our FW QP<br /> number.<br /> <br /> Otherwise we could use the wrong QP when handling a CQE which could<br /> cause the kernel trace below.<br /> <br /> This issue is mainly noticeable over QPs 0 &amp; 1, since for now they are<br /> the only QPs in our driver whereas the QP number inside mlx5_ib_qp<br /> doesn&amp;#39;t match the QP number inside mlx5_core_qp.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000012<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP<br /> CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]<br /> RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]<br /> 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 b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21<br /> RSP: 0018:ffff88810511bd60 EFLAGS: 00010046<br /> RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a<br /> RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10<br /> R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000<br /> R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0<br /> FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0<br /> Call Trace:<br /> <br /> ? __die+0x20/0x60<br /> ? page_fault_oops+0x150/0x3e0<br /> ? exc_page_fault+0x74/0x130<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]<br /> __ib_process_cq+0x5a/0x150 [ib_core]<br /> ib_cq_poll_work+0x31/0x90 [ib_core]<br /> process_one_work+0x169/0x320<br /> worker_thread+0x288/0x3a0<br /> ? work_busy+0xb0/0xb0<br /> kthread+0xd7/0x1f0<br /> ? kthreads_online_cpu+0x130/0x130<br /> ? kthreads_online_cpu+0x130/0x130<br /> ret_from_fork+0x2d/0x50<br /> ? kthreads_online_cpu+0x130/0x130<br /> ret_from_fork_asm+0x11/0x20<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "smb: client: fix TCP timers deadlock after rmmod"<br /> <br /> This reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.<br /> <br /> Commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after<br /> rmmod") is intended to fix a null-ptr-deref in LOCKDEP, which is<br /> mentioned as CVE-2024-54680, but is actually did not fix anything;<br /> The issue can be reproduced on top of it. [0]<br /> <br /> Also, it reverted the change by commit ef7134c7fc48 ("smb: client:<br /> Fix use-after-free of network namespace.") and introduced a real<br /> issue by reviving the kernel TCP socket.<br /> <br /> When a reconnect happens for a CIFS connection, the socket state<br /> transitions to FIN_WAIT_1. Then, inet_csk_clear_xmit_timers_sync()<br /> in tcp_close() stops all timers for the socket.<br /> <br /> If an incoming FIN packet is lost, the socket will stay at FIN_WAIT_1<br /> forever, and such sockets could be leaked up to net.ipv4.tcp_max_orphans.<br /> <br /> Usually, FIN can be retransmitted by the peer, but if the peer aborts<br /> the connection, the issue comes into reality.<br /> <br /> I warned about this privately by pointing out the exact report [1],<br /> but the bogus fix was finally merged.<br /> <br /> So, we should not stop the timers to finally kill the connection on<br /> our side in that case, meaning we must not use a kernel socket for<br /> TCP whose sk-&gt;sk_net_refcnt is 0.<br /> <br /> The kernel socket does not have a reference to its netns to make it<br /> possible to tear down netns without cleaning up every resource in it.<br /> <br /> For example, tunnel devices use a UDP socket internally, but we can<br /> destroy netns without removing such devices and let it complete<br /> during exit. Otherwise, netns would be leaked when the last application<br /> died.<br /> <br /> However, this is problematic for TCP sockets because TCP has timers to<br /> close the connection gracefully even after the socket is close()d. The<br /> lifetime of the socket and its netns is different from the lifetime of<br /> the underlying connection.<br /> <br /> If the socket user does not maintain the netns lifetime, the timer could<br /> be fired after the socket is close()d and its netns is freed up, resulting<br /> in use-after-free.<br /> <br /> Actually, we have seen so many similar issues and converted such sockets<br /> to have a reference to netns.<br /> <br /> That&amp;#39;s why I converted the CIFS client socket to have a reference to<br /> netns (sk-&gt;sk_net_refcnt == 1), which is somehow mentioned as out-of-scope<br /> of CIFS and technically wrong in e9f2517a3e18, but **is in-scope and right<br /> fix**.<br /> <br /> Regarding the LOCKDEP issue, we can prevent the module unload by<br /> bumping the module refcount when switching the LOCKDDEP key in<br /> sock_lock_init_class_and_name(). [2]<br /> <br /> For a while, let&amp;#39;s revert the bogus fix.<br /> <br /> Note that now we can use sk_net_refcnt_upgrade() for the socket<br /> conversion, but I&amp;#39;ll do so later separately to make backport easy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: fix missing shutdown check<br /> <br /> xfstests generic/730 test failed because after deleting the device<br /> that still had dirty data, the file could still be read without<br /> returning an error. The reason is the missing shutdown check in<br /> -&gt;read_iter.<br /> <br /> I also noticed that shutdown checks were missing from -&gt;write_iter,<br /> -&gt;splice_read, and -&gt;mmap. This commit adds shutdown checks to all<br /> of them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: make sure ubq-&gt;canceling is set when queue is frozen<br /> <br /> Now ublk driver depends on `ubq-&gt;canceling` for deciding if the request<br /> can be dispatched via uring_cmd &amp; io_uring_cmd_complete_in_task().<br /> <br /> Once ubq-&gt;canceling is set, the uring_cmd can be done via ublk_cancel_cmd()<br /> and io_uring_cmd_done().<br /> <br /> So set ubq-&gt;canceling when queue is frozen, this way makes sure that the<br /> flag can be observed from ublk_queue_rq() reliably, and avoids<br /> use-after-free on uring_cmd.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/9p: fix NULL pointer dereference on mkdir<br /> <br /> When a 9p tree was mounted with option &amp;#39;posixacl&amp;#39;, parent directory had a<br /> default ACL set for its subdirectories, e.g.:<br /> <br /> setfacl -m default:group:simpsons:rwx parentdir<br /> <br /> then creating a subdirectory crashed 9p client, as v9fs_fid_add() call in<br /> function v9fs_vfs_mkdir_dotl() sets the passed &amp;#39;fid&amp;#39; pointer to NULL<br /> (since dafbe689736) even though the subsequent v9fs_set_create_acl() call<br /> expects a valid non-NULL &amp;#39;fid&amp;#39; pointer:<br /> <br /> [ 37.273191] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> [ 37.322338] Call Trace:<br /> [ 37.323043] <br /> [ 37.323621] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)<br /> [ 37.324448] ? page_fault_oops (arch/x86/mm/fault.c:714)<br /> [ 37.325532] ? search_module_extables (kernel/module/main.c:3733)<br /> [ 37.326742] ? p9_client_walk (net/9p/client.c:1165) 9pnet<br /> [ 37.328006] ? search_bpf_extables (kernel/bpf/core.c:804)<br /> [ 37.329142] ? exc_page_fault (./arch/x86/include/asm/paravirt.h:686 arch/x86/mm/fault.c:1488 arch/x86/mm/fault.c:1538)<br /> [ 37.330196] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:574)<br /> [ 37.331330] ? p9_client_walk (net/9p/client.c:1165) 9pnet<br /> [ 37.332562] ? v9fs_fid_xattr_get (fs/9p/xattr.c:30) 9p<br /> [ 37.333824] v9fs_fid_xattr_set (fs/9p/fid.h:23 fs/9p/xattr.c:121) 9p<br /> [ 37.335077] v9fs_set_acl (fs/9p/acl.c:276) 9p<br /> [ 37.336112] v9fs_set_create_acl (fs/9p/acl.c:307) 9p<br /> [ 37.337326] v9fs_vfs_mkdir_dotl (fs/9p/vfs_inode_dotl.c:411) 9p<br /> [ 37.338590] vfs_mkdir (fs/namei.c:4313)<br /> [ 37.339535] do_mkdirat (fs/namei.c:4336)<br /> [ 37.340465] __x64_sys_mkdir (fs/namei.c:4354)<br /> [ 37.341455] do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)<br /> [ 37.342447] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> <br /> Fix this by simply swapping the sequence of these two calls in<br /> v9fs_vfs_mkdir_dotl(), i.e. calling v9fs_set_create_acl() before<br /> v9fs_fid_add().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix r_count dec/increment mismatch<br /> <br /> r_count is only increased when there is an oplock break wait,<br /> so r_count inc/decrement are not paired. This can cause r_count<br /> to become negative, which can lead to a problem where the ksmbd<br /> thread does not terminate.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: fgraph: Fix stack layout to match __arch_ftrace_regs argument of ftrace_return_to_handler<br /> <br /> Naresh Kamboju reported a "Bad frame pointer" kernel warning while<br /> running LTP trace ftrace_stress_test.sh in riscv. We can reproduce the<br /> same issue with the following command:<br /> <br /> ```<br /> $ cd /sys/kernel/debug/tracing<br /> $ echo &amp;#39;f:myprobe do_nanosleep%return args1=$retval&amp;#39; &gt; dynamic_events<br /> $ echo 1 &gt; events/fprobes/enable<br /> $ echo 1 &gt; tracing_on<br /> $ sleep 1<br /> ```<br /> <br /> And we can get the following kernel warning:<br /> <br /> [ 127.692888] ------------[ cut here ]------------<br /> [ 127.693755] Bad frame pointer: expected ff2000000065be50, received ba34c141e9594000<br /> [ 127.693755] from func do_nanosleep return to ffffffff800ccb16<br /> [ 127.698699] WARNING: CPU: 1 PID: 129 at kernel/trace/fgraph.c:755 ftrace_return_to_handler+0x1b2/0x1be<br /> [ 127.699894] Modules linked in:<br /> [ 127.700908] CPU: 1 UID: 0 PID: 129 Comm: sleep Not tainted 6.14.0-rc3-g0ab191c74642 #32<br /> [ 127.701453] Hardware name: riscv-virtio,qemu (DT)<br /> [ 127.701859] epc : ftrace_return_to_handler+0x1b2/0x1be<br /> [ 127.702032] ra : ftrace_return_to_handler+0x1b2/0x1be<br /> [ 127.702151] epc : ffffffff8013b5e0 ra : ffffffff8013b5e0 sp : ff2000000065bd10<br /> [ 127.702221] gp : ffffffff819c12f8 tp : ff60000080853100 t0 : 6e00000000000000<br /> [ 127.702284] t1 : 0000000000000020 t2 : 6e7566206d6f7266 s0 : ff2000000065bd80<br /> [ 127.702346] s1 : ff60000081262000 a0 : 000000000000007b a1 : ffffffff81894f20<br /> [ 127.702408] a2 : 0000000000000010 a3 : fffffffffffffffe a4 : 0000000000000000<br /> [ 127.702470] a5 : 0000000000000000 a6 : 0000000000000008 a7 : 0000000000000038<br /> [ 127.702530] s2 : ba34c141e9594000 s3 : 0000000000000000 s4 : ff2000000065bdd0<br /> [ 127.702591] s5 : 00007fff8adcf400 s6 : 000055556dc1d8c0 s7 : 0000000000000068<br /> [ 127.702651] s8 : 00007fff8adf5d10 s9 : 000000000000006d s10: 0000000000000001<br /> [ 127.702710] s11: 00005555737377c8 t3 : ffffffff819d899e t4 : ffffffff819d899e<br /> [ 127.702769] t5 : ffffffff819d89a0 t6 : ff2000000065bb18<br /> [ 127.702826] status: 0000000200000120 badaddr: 0000000000000000 cause: 0000000000000003<br /> [ 127.703292] [] ftrace_return_to_handler+0x1b2/0x1be<br /> [ 127.703760] [] return_to_handler+0x16/0x26<br /> [ 127.704009] [] return_to_handler+0x0/0x26<br /> [ 127.704057] [] common_nsleep+0x42/0x54<br /> [ 127.704117] [] __riscv_sys_clock_nanosleep+0xba/0x10a<br /> [ 127.704176] [] do_trap_ecall_u+0x188/0x218<br /> [ 127.704295] [] handle_exception+0x14a/0x156<br /> [ 127.705436] ---[ end trace 0000000000000000 ]---<br /> <br /> The reason is that the stack layout for constructing argument for the<br /> ftrace_return_to_handler in the return_to_handler does not match the<br /> __arch_ftrace_regs structure of riscv, leading to unexpected results.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spufs: fix a leak in spufs_create_context()<br /> <br /> Leak fixes back in 2008 missed one case - if we are trying to set affinity<br /> and spufs_mkdir() fails, we need to drop the reference to neighbor.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spufs: fix gang directory lifetimes<br /> <br /> prior to "[POWERPC] spufs: Fix gang destroy leaks" we used to have<br /> a problem with gang lifetimes - creation of a gang returns opened<br /> gang directory, which normally gets removed when that gets closed,<br /> but if somebody has created a context belonging to that gang and<br /> kept it alive until the gang got closed, removal failed and we<br /> ended up with a leak.<br /> <br /> Unfortunately, it had been fixed the wrong way. Dentry of gang<br /> directory was no longer pinned, and rmdir on close was gone.<br /> One problem was that failure of open kept calling simple_rmdir()<br /> as cleanup, which meant an unbalanced dput(). Another bug was<br /> in the success case - gang creation incremented link count on<br /> root directory, but that was no longer undone when gang got<br /> destroyed.<br /> <br /> Fix consists of<br /> * reverting the commit in question<br /> * adding a counter to gang, protected by -&gt;i_rwsem<br /> of gang directory inode.<br /> * having it set to 1 at creation time, dropped<br /> in both spufs_dir_close() and spufs_gang_close() and bumped<br /> in spufs_create_context(), provided that it&amp;#39;s not 0.<br /> * using simple_recursive_removal() to take the gang<br /> directory out when counter reaches zero.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spufs: fix a leak on spufs_new_file() failure<br /> <br /> It&amp;#39;s called from spufs_fill_dir(), and caller of that will do<br /> spufs_rmdir() in case of failure. That does remove everything<br /> we&amp;#39;d managed to create, but... the problem dentry is still<br /> negative. IOW, it needs to be explicitly dropped.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtnetlink: Allocate vfinfo size for VF GUIDs when supported<br /> <br /> Commit 30aad41721e0 ("net/core: Add support for getting VF GUIDs")<br /> added support for getting VF port and node GUIDs in netlink ifinfo<br /> messages, but their size was not taken into consideration in the<br /> function that allocates the netlink message, causing the following<br /> warning when a netlink message is filled with many VF port and node<br /> GUIDs:<br /> # echo 64 &gt; /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs<br /> # ip link show dev ib0<br /> RTNETLINK answers: Message too long<br /> Cannot send link get request: Message too long<br /> <br /> Kernel warning:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0<br /> Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core<br /> CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:rtnl_getlink+0x586/0x5a0<br /> Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00<br /> RSP: 0018:ffff888113557348 EFLAGS: 00010246<br /> RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000<br /> RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8<br /> RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000<br /> R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00<br /> R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff<br /> FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __warn+0xa5/0x230<br /> ? rtnl_getlink+0x586/0x5a0<br /> ? report_bug+0x22d/0x240<br /> ? handle_bug+0x53/0xa0<br /> ? exc_invalid_op+0x14/0x50<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? skb_trim+0x6a/0x80<br /> ? rtnl_getlink+0x586/0x5a0<br /> ? __pfx_rtnl_getlink+0x10/0x10<br /> ? rtnetlink_rcv_msg+0x1e5/0x860<br /> ? __pfx___mutex_lock+0x10/0x10<br /> ? rcu_is_watching+0x34/0x60<br /> ? __pfx_lock_acquire+0x10/0x10<br /> ? stack_trace_save+0x90/0xd0<br /> ? filter_irq_stacks+0x1d/0x70<br /> ? kasan_save_stack+0x30/0x40<br /> ? kasan_save_stack+0x20/0x40<br /> ? kasan_save_track+0x10/0x30<br /> rtnetlink_rcv_msg+0x21c/0x860<br /> ? entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ? __pfx_rtnetlink_rcv_msg+0x10/0x10<br /> ? arch_stack_walk+0x9e/0xf0<br /> ? rcu_is_watching+0x34/0x60<br /> ? lock_acquire+0xd5/0x410<br /> ? rcu_is_watching+0x34/0x60<br /> netlink_rcv_skb+0xe0/0x210<br /> ? __pfx_rtnetlink_rcv_msg+0x10/0x10<br /> ? __pfx_netlink_rcv_skb+0x10/0x10<br /> ? rcu_is_watching+0x34/0x60<br /> ? __pfx___netlink_lookup+0x10/0x10<br /> ? lock_release+0x62/0x200<br /> ? netlink_deliver_tap+0xfd/0x290<br /> ? rcu_is_watching+0x34/0x60<br /> ? lock_release+0x62/0x200<br /> ? netlink_deliver_tap+0x95/0x290<br /> netlink_unicast+0x31f/0x480<br /> ? __pfx_netlink_unicast+0x10/0x10<br /> ? rcu_is_watching+0x34/0x60<br /> ? lock_acquire+0xd5/0x410<br /> netlink_sendmsg+0x369/0x660<br /> ? lock_release+0x62/0x200<br /> ? __pfx_netlink_sendmsg+0x10/0x10<br /> ? import_ubuf+0xb9/0xf0<br /> ? __import_iovec+0x254/0x2b0<br /> ? lock_release+0x62/0x200<br /> ? __pfx_netlink_sendmsg+0x10/0x10<br /> ____sys_sendmsg+0x559/0x5a0<br /> ? __pfx_____sys_sendmsg+0x10/0x10<br /> ? __pfx_copy_msghdr_from_user+0x10/0x10<br /> ? rcu_is_watching+0x34/0x60<br /> ? do_read_fault+0x213/0x4a0<br /> ? rcu_is_watching+0x34/0x60<br /> ___sys_sendmsg+0xe4/0x150<br /> ? __pfx____sys_sendmsg+0x10/0x10<br /> ? do_fault+0x2cc/0x6f0<br /> ? handle_pte_fault+0x2e3/0x3d0<br /> ? __pfx_handle_pte_fault+0x10/0x10<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: don&amp;#39;t unregister hook when table is dormant<br /> <br /> When nf_tables_updchain encounters an error, hook registration needs to<br /> be rolled back.<br /> <br /> This should only be done if the hook has been registered, which won&amp;#39;t<br /> happen when the table is flagged as dormant (inactive).<br /> <br /> Just move the assignment into the registration block.