Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: xtables: restrict several matches to inet family<br /> <br /> This is a partial revert of:<br /> <br /> commit ab4f21e6fb1c ("netfilter: xtables: use NFPROTO_UNSPEC in more extensions")<br /> <br /> to allow ipv4 and ipv6 only.<br /> <br /> - xt_mac<br /> - xt_owner<br /> - xt_physdev<br /> <br /> These extensions are not used by ebtables in userspace.<br /> <br /> Moreover, xt_realm is only for ipv4, since dst-&gt;tclassid is ipv4<br /> specific.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nat: use kfree_rcu to release ops<br /> <br /> Florian Westphal says:<br /> <br /> "Historically this is not an issue, even for normal base hooks: the data<br /> path doesn&amp;#39;t use the original nf_hook_ops that are used to register the<br /> callbacks.<br /> <br /> However, in v5.14 I added the ability to dump the active netfilter<br /> hooks from userspace.<br /> <br /> This code will peek back into the nf_hook_ops that are available<br /> at the tail of the pointer-array blob used by the datapath.<br /> <br /> The nat hooks are special, because they are called indirectly from<br /> the central nat dispatcher hook. They are currently invisible to<br /> the nfnl hook dump subsystem though.<br /> <br /> But once that changes the nat ops structures have to be deferred too."<br /> <br /> Update nf_nat_register_fn() to deal with partial exposition of the hooks<br /> from error path which can be also an issue for nfnetlink_hook.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: remove sprintf usage<br /> <br /> Replace it with scnprintf, the buffer sizes are expected to be large enough<br /> to hold the result, no need for snprintf+overflow check.<br /> <br /> Increase buffer size in mangle_content_len() while at it.<br /> <br /> BUG: KASAN: stack-out-of-bounds in vsnprintf+0xea5/0x1270<br /> Write of size 1 at addr [..]<br /> vsnprintf+0xea5/0x1270<br /> sprintf+0xb1/0xe0<br /> mangle_content_len+0x1ac/0x280<br /> nf_nat_sdp_session+0x1cc/0x240<br /> process_sdp+0x8f8/0xb80<br /> process_invite_request+0x108/0x2b0<br /> process_sip_msg+0x5da/0xf50<br /> sip_help_tcp+0x45e/0x780<br /> nf_confirm+0x34d/0x990<br /> [..]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix possible UAF in icmpv6_rcv()<br /> <br /> Caching saddr and daddr before pskb_pull() is problematic<br /> since skb-&gt;head can change.<br /> <br /> Remove these temporary variables:<br /> <br /> - We only access &amp;ipv6_hdr(skb)-&gt;saddr and &amp;ipv6_hdr(skb)-&gt;daddr<br /> when net_dbg_ratelimited() is called in the slow path.<br /> <br /> - Avoid potential future misuse after pskb_pull() call.

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