Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: validate l_tree_depth to avoid out-of-bounds access<br /> <br /> The l_tree_depth field is 16-bit (__le16), but the actual maximum depth is<br /> limited to OCFS2_MAX_PATH_DEPTH.<br /> <br /> Add a check to prevent out-of-bounds access if l_tree_depth has an invalid<br /> value, which may occur when reading from a corrupted mounted disk [1].

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix a couple integer overflows on 32bit systems<br /> <br /> On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can<br /> have an integer wrapping issue. Fix it by using size_add().

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 /> vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint<br /> <br /> If vhost_scsi_set_endpoint is called multiple times without a<br /> vhost_scsi_clear_endpoint between them, we can hit multiple bugs<br /> found by Haoran Zhang:<br /> <br /> 1. Use-after-free when no tpgs are found:<br /> <br /> This fixes a use after free that occurs when vhost_scsi_set_endpoint is<br /> called more than once and calls after the first call do not find any<br /> tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds<br /> tpgs to add to the vs_tpg array match=true, so we will do:<br /> <br /> vhost_vq_set_backend(vq, vs_tpg);<br /> ...<br /> <br /> kfree(vs-&gt;vs_tpg);<br /> vs-&gt;vs_tpg = vs_tpg;<br /> <br /> If vhost_scsi_set_endpoint is called again and no tpgs are found<br /> match=false so we skip the vhost_vq_set_backend call leaving the<br /> pointer to the vs_tpg we then free via:<br /> <br /> kfree(vs-&gt;vs_tpg);<br /> vs-&gt;vs_tpg = vs_tpg;<br /> <br /> If a scsi request is then sent we do:<br /> <br /> vhost_scsi_handle_vq -&gt; vhost_scsi_get_req -&gt; vhost_vq_get_backend<br /> <br /> which sees the vs_tpg we just did a kfree on.<br /> <br /> 2. Tpg dir removal hang:<br /> <br /> This patch fixes an issue where we cannot remove a LIO/target layer<br /> tpg (and structs above it like the target) dir due to the refcount<br /> dropping to -1.<br /> <br /> The problem is that if vhost_scsi_set_endpoint detects a tpg is already<br /> in the vs-&gt;vs_tpg array or if the tpg has been removed so<br /> target_depend_item fails, the undepend goto handler will do<br /> target_undepend_item on all tpgs in the vs_tpg array dropping their<br /> refcount to 0. At this time vs_tpg contains both the tpgs we have added<br /> in the current vhost_scsi_set_endpoint call as well as tpgs we added in<br /> previous calls which are also in vs-&gt;vs_tpg.<br /> <br /> Later, when vhost_scsi_clear_endpoint runs it will do<br /> target_undepend_item on all the tpgs in the vs-&gt;vs_tpg which will drop<br /> their refcount to -1. Userspace will then not be able to remove the tpg<br /> and will hang when it tries to do rmdir on the tpg dir.<br /> <br /> 3. Tpg leak:<br /> <br /> This fixes a bug where we can leak tpgs and cause them to be<br /> un-removable because the target name is overwritten when<br /> vhost_scsi_set_endpoint is called multiple times but with different<br /> target names.<br /> <br /> The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup<br /> a vhost-scsi device to target/tpg mapping, then calls<br /> VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we<br /> haven&amp;#39;t seen before (target1 has tpg1 but target2 has tpg2). When this<br /> happens we don&amp;#39;t teardown the old target tpg mapping and just overwrite<br /> the target name and the vs-&gt;vs_tpg array. Later when we do<br /> vhost_scsi_clear_endpoint, we are passed in either target1 or target2&amp;#39;s<br /> name and we will only match that target&amp;#39;s tpgs when we loop over the<br /> vs-&gt;vs_tpg. We will then return from the function without doing<br /> target_undepend_item on the tpgs.<br /> <br /> Because of all these bugs, it looks like being able to call<br /> vhost_scsi_set_endpoint multiple times was never supported. The major<br /> user, QEMU, already has checks to prevent this use case. So to fix the<br /> issues, this patch prevents vhost_scsi_set_endpoint from being called<br /> if it&amp;#39;s already successfully added tpgs. To add, remove or change the<br /> tpg config or target name, you must do a vhost_scsi_clear_endpoint<br /> first.

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 /> 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.