Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_osf: fix out-of-bounds read on option matching<br /> <br /> In nf_osf_match(), the nf_osf_hdr_ctx structure is initialized once<br /> and passed by reference to nf_osf_match_one() for each fingerprint<br /> checked. During TCP option parsing, nf_osf_match_one() advances the<br /> shared ctx-&gt;optp pointer.<br /> <br /> If a fingerprint perfectly matches, the function returns early without<br /> restoring ctx-&gt;optp to its initial state. If the user has configured<br /> NF_OSF_LOGLEVEL_ALL, the loop continues to the next fingerprint.<br /> However, because ctx-&gt;optp was not restored, the next call to<br /> nf_osf_match_one() starts parsing from the end of the options buffer.<br /> This causes subsequent matches to read garbage data and fail<br /> immediately, making it impossible to log more than one match or logging<br /> incorrect matches.<br /> <br /> Instead of using a shared ctx-&gt;optp pointer, pass the context as a<br /> constant pointer and use a local pointer (optp) for TCP option<br /> traversal. This makes nf_osf_match_one() strictly stateless from the<br /> caller&amp;#39;s perspective, ensuring every fingerprint check starts at the<br /> correct option offset.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_osf: fix potential NULL dereference in ttl check<br /> <br /> The nf_osf_ttl() function accessed skb-&gt;dev to perform a local interface<br /> address lookup without verifying that the device pointer was valid.<br /> <br /> Additionally, the implementation utilized an in_dev_for_each_ifa_rcu<br /> loop to match the packet source address against local interface<br /> addresses. It assumed that packets from the same subnet should not see a<br /> decrement on the initial TTL. A packet might appear it is from the same<br /> subnet but it actually isn&amp;#39;t especially in modern environments with<br /> containers and virtual switching.<br /> <br /> Remove the device dereference and interface loop. Replace the logic with<br /> a switch statement that evaluates the TTL according to the ttl_check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_dualpi2: drain both C-queue and L-queue in dualpi2_change()<br /> <br /> Fix dualpi2_change() to correctly enforce updated limit and memlimit<br /> values after a configuration change of the dualpi2 qdisc.<br /> <br /> Before this patch, dualpi2_change() always attempted to dequeue packets<br /> via the root qdisc (C-queue) when reducing backlog or memory usage, and<br /> unconditionally assumed that a valid skb will be returned. When traffic<br /> classification results in packets being queued in the L-queue while the<br /> C-queue is empty, this leads to a NULL skb dereference during limit or<br /> memlimit enforcement.<br /> <br /> This is fixed by first dequeuing from the C-queue path if it is<br /> non-empty. Once the C-queue is empty, packets are dequeued directly from<br /> the L-queue. Return values from qdisc_dequeue_internal() are checked for<br /> both queues. When dequeuing from the L-queue, the parent qdisc qlen and<br /> backlog counters are updated explicitly to keep overall qdisc statistics<br /> consistent.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix durable fd leak on ClientGUID mismatch in durable v2 open<br /> <br /> ksmbd_lookup_fd_cguid() returns a ksmbd_file with its refcount<br /> incremented via ksmbd_fp_get(). parse_durable_handle_context() in<br /> the DURABLE_REQ_V2 case properly releases this reference on every<br /> path inside the ClientGUID-match branch, either by calling<br /> ksmbd_put_durable_fd() or by transferring ownership to dh_info-&gt;fp<br /> for a successful reconnect. However, when an entry exists in the<br /> global file table with the same CreateGuid but a different<br /> ClientGUID, the code simply falls through to the new-open path<br /> without dropping the reference obtained from ksmbd_lookup_fd_cguid().<br /> <br /> Per MS-SMB2 section 3.3.5.9.10 ("Handling the<br /> SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 Create Context"), the server<br /> MUST locate an Open whose Open.CreateGuid matches the request&amp;#39;s<br /> CreateGuid AND whose Open.ClientGuid matches the ClientGuid of the<br /> connection that received the request. If no such Open is found, the<br /> server MUST continue with the normal open execution phase. A<br /> CreateGuid hit with a ClientGUID mismatch is therefore the<br /> "Open not found" case: proceeding with a new open is correct, but<br /> the reference obtained purely as a side effect of the lookup must<br /> not be leaked.<br /> <br /> Repeated requests that hit this mismatch pin global_ft entries,<br /> prevent __ksmbd_close_fd() from ever running for the corresponding<br /> files, and defeat the durable scavenger, leading to long-lived<br /> resource leaks.<br /> <br /> Release the reference in the mismatch path and clear dh_info-&gt;fp so<br /> subsequent logic does not mistake a non-matching lookup result for<br /> a reconnect target.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rds: zero per-item info buffer before handing it to visitors<br /> <br /> rds_for_each_conn_info() and rds_walk_conn_path_info() both hand a<br /> caller-allocated on-stack u64 buffer to a per-connection visitor and<br /> then copy the full item_len bytes back to user space via<br /> rds_info_copy() regardless of how much of the buffer the visitor<br /> actually wrote.<br /> <br /> rds_ib_conn_info_visitor() and rds6_ib_conn_info_visitor() only<br /> write a subset of their output struct when the underlying<br /> rds_connection is not in state RDS_CONN_UP (src/dst addr, tos, sl<br /> and the two GIDs via explicit memsets). Several u32 fields<br /> (max_send_wr, max_recv_wr, max_send_sge, rdma_mr_max, rdma_mr_size,<br /> cache_allocs) and the 2-byte alignment hole between sl and<br /> cache_allocs remain as whatever stack contents preceded the visitor<br /> call and are then memcpy_to_user()&amp;#39;d out to user space.<br /> <br /> struct rds_info_rdma_connection and struct rds6_info_rdma_connection<br /> are the only rds_info_* structs in include/uapi/linux/rds.h that are<br /> not marked __attribute__((packed)), so they have a real alignment<br /> hole. The other info visitors (rds_conn_info_visitor,<br /> rds6_conn_info_visitor, rds_tcp_tc_info, ...) write all fields of<br /> their packed output struct today and are not known to be vulnerable,<br /> but a future visitor that adds a conditional write-path would have<br /> the same bug.<br /> <br /> Reproduction on a kernel built without CONFIG_INIT_STACK_ALL_ZERO=y:<br /> a local unprivileged user opens AF_RDS, sets SO_RDS_TRANSPORT=IB,<br /> binds to a local address on an RDMA-capable netdev (rxe soft-RoCE on<br /> any netdev is sufficient), sendto()&amp;#39;s any peer on the same subnet<br /> (fails cleanly but installs an rds_connection in the global hash in<br /> RDS_CONN_CONNECTING), then calls getsockopt(SOL_RDS,<br /> RDS_INFO_IB_CONNECTIONS). The returned 68-byte item contains 26<br /> bytes of stack garbage including kernel text/data pointers:<br /> <br /> 0..7 0a 63 00 01 0a 63 00 02 src=10.99.0.1 dst=10.99.0.2<br /> 8..39 00 ... gids (memset-zeroed)<br /> 40..47 e0 92 a3 81 ff ff ff ff kernel pointer (max_send_wr)<br /> 48..55 7f 37 b5 81 ff ff ff ff kernel pointer (rdma_mr_max)<br /> 56..59 01 00 08 00 rdma_mr_size (garbage)<br /> 60..61 00 00 tos, sl<br /> 62..63 00 00 alignment padding<br /> 64..67 18 00 00 00 cache_allocs (garbage)<br /> <br /> Fix by zeroing the per-item buffer in both rds_for_each_conn_info()<br /> and rds_walk_conn_path_info() before invoking the visitor. This<br /> covers the IPv4/IPv6 IB visitors and hardens all current and future<br /> visitors against the same class of bug.<br /> <br /> No functional change for visitors that fully populate their output.<br /> <br /> Changes in v2:<br /> - retarget at the net tree (subject prefix "[PATCH net v2]",<br /> net/rds: prefix in the title)<br /> - pick up Reviewed-by tags from Sharath Srinivasan and<br /> Allison Henderson

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting<br /> <br /> virtio_transport_init_zcopy_skb() uses iter-&gt;count as the size argument<br /> for msg_zerocopy_realloc(), which in turn passes it to<br /> mm_account_pinned_pages() for RLIMIT_MEMLOCK accounting. However, this<br /> function is called after virtio_transport_fill_skb() has already consumed<br /> the iterator via __zerocopy_sg_from_iter(), so on the last skb, iter-&gt;count<br /> will be 0, skipping the RLIMIT_MEMLOCK enforcement.<br /> <br /> Pass pkt_len (the total bytes being sent) as an explicit parameter to<br /> virtio_transport_init_zcopy_skb() instead of reading the already-consumed<br /> iter-&gt;count.<br /> <br /> This matches TCP and UDP, which both call msg_zerocopy_realloc() with<br /> the original message size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/adfs: validate nzones in adfs_validate_bblk()<br /> <br /> Reject ADFS disc records with a zero zone count during boot block<br /> validation, before the disc record is used.<br /> <br /> When nzones is 0, adfs_read_map() passes it to kmalloc_array(0, ...)<br /> which returns ZERO_SIZE_PTR, and adfs_map_layout() then writes to<br /> dm[-1], causing an out-of-bounds write before the allocated buffer.<br /> <br /> adfs_validate_dr0() already rejects nzones != 1 for old-format<br /> images. Add the equivalent check to adfs_validate_bblk() for<br /> new-format images so that a crafted image with nzones == 0 is<br /> rejected at probe time.<br /> <br /> Found by syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix double-free in tipc_buf_append()<br /> <br /> tipc_msg_validate() can potentially reallocate the skb it is validating,<br /> freeing the old one. In tipc_buf_append(), it was being called with a<br /> pointer to a local variable which was a copy of the caller&amp;#39;s skb<br /> pointer.<br /> <br /> If the skb was reallocated and validation subsequently failed, the error<br /> handling path would free the original skb pointer, which had already<br /> been freed, leading to double-free.<br /> <br /> Fix this by checking if head now points to a newly allocated reassembled<br /> skb. If it does, reassign *headbuf for later freeing operations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: avoid double drm_exec_fini() in userq validate<br /> <br /> When new_addition is true, amdgpu_userq_vm_validate() calls<br /> drm_exec_fini(&amp;exec) before iterating over the collected HMM ranges and<br /> calling amdgpu_ttm_tt_get_user_pages().<br /> <br /> If amdgpu_ttm_tt_get_user_pages() fails in that path, the code jumps to<br /> unlock_all and calls drm_exec_fini(&amp;exec) a second time on the same<br /> exec object. drm_exec_fini() is not idempotent: it frees exec-&gt;objects<br /> and may also drop exec-&gt;contended and finalize the ww acquire context.<br /> <br /> Route that error path directly to the range cleanup once exec has<br /> already been finalized.<br /> <br /> Issue found using a prototype static analysis tool<br /> and confirmed by code review.<br /> <br /> (cherry picked from commit 2802952e4a07306da6ebe813ff1acacc5691851a)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers<br /> <br /> Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds<br /> PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd-&gt;queue)<br /> and returns early. However, because the function returns void, the<br /> callers are entirely unaware that a fatal error has occurred and<br /> that the cmd-&gt;recv_msg.msg_iter was left uninitialized.<br /> <br /> Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly<br /> overwrite the queue state with queue-&gt;rcv_state = NVMET_TCP_RECV_DATA<br /> Consequently, the socket receiving loop may attempt to read incoming<br /> network data into the uninitialized iterator.<br /> <br /> Fix this by shifting the error handling responsibility to the callers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/psi: fix race between file release and pressure write<br /> <br /> A potential race condition exists between pressure write and cgroup file<br /> release regarding the priv member of struct kernfs_open_file, which<br /> triggers the uaf reported in [1].<br /> <br /> Consider the following scenario involving execution on two separate CPUs:<br /> <br /> CPU0 CPU1<br /> ==== ====<br /> vfs_rmdir()<br /> kernfs_iop_rmdir()<br /> cgroup_rmdir()<br /> cgroup_kn_lock_live()<br /> cgroup_destroy_locked()<br /> cgroup_addrm_files()<br /> cgroup_rm_file()<br /> kernfs_remove_by_name()<br /> kernfs_remove_by_name_ns()<br /> vfs_write() __kernfs_remove()<br /> new_sync_write() kernfs_drain()<br /> kernfs_fop_write_iter() kernfs_drain_open_files()<br /> cgroup_file_write() kernfs_release_file()<br /> pressure_write() cgroup_file_release()<br /> ctx = of-&gt;priv;<br /> kfree(ctx);<br /> of-&gt;priv = NULL;<br /> cgroup_kn_unlock()<br /> cgroup_kn_lock_live()<br /> cgroup_get(cgrp)<br /> cgroup_kn_unlock()<br /> if (ctx-&gt;psi.trigger) // here, trigger uaf for ctx, that is of-&gt;priv<br /> <br /> The cgroup_rmdir() is protected by the cgroup_mutex, it also safeguards<br /> the memory deallocation of of-&gt;priv performed within cgroup_file_release().<br /> However, the operations involving of-&gt;priv executed within pressure_write()<br /> are not entirely covered by the protection of cgroup_mutex. Consequently,<br /> if the code in pressure_write(), specifically the section handling the<br /> ctx variable executes after cgroup_file_release() has completed, a uaf<br /> vulnerability involving of-&gt;priv is triggered.<br /> <br /> Therefore, the issue can be resolved by extending the scope of the<br /> cgroup_mutex lock within pressure_write() to encompass all code paths<br /> involving of-&gt;priv, thereby properly synchronizing the race condition<br /> occurring between cgroup_file_release() and pressure_write().<br /> <br /> And, if an live kn lock can be successfully acquired while executing<br /> the pressure write operation, it indicates that the cgroup deletion<br /> process has not yet reached its final stage; consequently, the priv<br /> pointer within open_file cannot be NULL. Therefore, the operation to<br /> retrieve the ctx value must be moved to a point *after* the live kn<br /> lock has been successfully acquired.<br /> <br /> In another situation, specifically after entering cgroup_kn_lock_live()<br /> but before acquiring cgroup_mutex, there exists a different class of<br /> race condition:<br /> <br /> CPU0: write memory.pressure CPU1: write cgroup.pressure=0<br /> =========================== =============================<br /> <br /> kernfs_fop_write_iter()<br /> kernfs_get_active_of(of)<br /> pressure_write()<br /> cgroup_kn_lock_live(memory.pressure)<br /> cgroup_tryget(cgrp)<br /> kernfs_break_active_protection(kn)<br /> ... blocks on cgroup_mutex<br /> <br /> cgroup_pressure_write()<br /> cgroup_kn_lock_live(cgroup.pressure)<br /> cgroup_file_show(memory.pressure, false)<br /> kernfs_show(false)<br /> kernfs_drain_open_files()<br /> cgroup_file_release(of)<br /> kfree(ctx)<br /> of-&gt;priv = NULL<br /> cgroup_kn_unlock()<br /> <br /> ... acquires cgroup_mutex<br /> ctx = of-&gt;priv; // may now be NULL<br /> if (ctx-&gt;psi.trigger) // NULL dereference<br /> <br /> Consequently, there is a possibility that of-&gt;priv is NULL, the pressure<br /> write needs to check for this.<br /> <br /> Now that the scope of the cgroup_mutex has been expanded, the original<br /> explicit cgroup_get/put operations are no longer necessary, this is<br /> because acquiring/releasing the live kn lock inherently executes a<br /> cgroup get/put operation.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011<br /> Call Trace:<br /> pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011<br /> cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c:43<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fsnotify: fix inode reference leak in fsnotify_recalc_mask()<br /> <br /> fsnotify_recalc_mask() fails to handle the return value of<br /> __fsnotify_recalc_mask(), which may return an inode pointer that needs<br /> to be released via fsnotify_drop_object() when the connector&amp;#39;s HAS_IREF<br /> flag transitions from set to cleared.<br /> <br /> This manifests as a hung task with the following call trace:<br /> <br /> INFO: task umount:1234 blocked for more than 120 seconds.<br /> Call Trace:<br /> __schedule<br /> schedule<br /> fsnotify_sb_delete<br /> generic_shutdown_super<br /> kill_anon_super<br /> cleanup_mnt<br /> task_work_run<br /> do_exit<br /> do_group_exit<br /> <br /> The race window that triggers the iref leak:<br /> <br /> Thread A (adding mark) Thread B (removing mark)<br /> ────────────────────── ────────────────────────<br /> fsnotify_add_mark_locked():<br /> fsnotify_add_mark_list():<br /> spin_lock(conn-&gt;lock)<br /> add mark_B(evictable) to list<br /> spin_unlock(conn-&gt;lock)<br /> return<br /> <br /> /* ---- gap: no lock held ---- */<br /> <br /> fsnotify_detach_mark(mark_A):<br /> spin_lock(mark_A-&gt;lock)<br /> clear ATTACHED flag on mark_A<br /> spin_unlock(mark_A-&gt;lock)<br /> fsnotify_put_mark(mark_A)<br /> <br /> fsnotify_recalc_mask():<br /> spin_lock(conn-&gt;lock)<br /> __fsnotify_recalc_mask():<br /> /* mark_A skipped: ATTACHED cleared */<br /> /* only mark_B(evictable) remains */<br /> want_iref = false<br /> has_iref = true /* not yet cleared */<br /> -&gt; HAS_IREF transitions true -&gt; false<br /> -&gt; returns inode pointer<br /> spin_unlock(conn-&gt;lock)<br /> /* BUG: return value discarded!<br /> * iput() and fsnotify_put_sb_watched_objects()<br /> * are never called */<br /> <br /> Fix this by deferring the transition true -&gt; false of HAS_IREF flag from<br /> fsnotify_recalc_mask() (Thread A) to fsnotify_put_mark() (thread B).