Vulnerabilidades

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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---

*** Pendiente de traducción *** 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).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: join hook list via splice_list_rcu() in commit phase<br /> <br /> Publish new hooks in the list into the basechain/flowtable using<br /> splice_list_rcu() to ensure netlink dump list traversal via rcu is safe<br /> while concurrent ruleset update is going on.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack_sip: don&amp;#39;t use simple_strtoul<br /> <br /> Replace unsafe port parsing in epaddr_len(), ct_sip_parse_header_uri(),<br /> and ct_sip_parse_request() with a new sip_parse_port() helper that<br /> validates each digit against the buffer limit, eliminating the use of<br /> simple_strtoul() which assumes NUL-terminated strings.<br /> <br /> The previous code dereferenced pointers without bounds checks after<br /> sip_parse_addr() and relied on simple_strtoul() on non-NUL-terminated<br /> skb data. A port that reaches the buffer limit without a trailing<br /> character is also rejected as malformed.<br /> <br /> Also get rid of all simple_strtoul() usage in conntrack, prefer a<br /> stricter version instead. There are intentional changes:<br /> <br /> - Bail out if number is &gt; UINT_MAX and indicate a failure, same for<br /> too long sequences.<br /> While we do accept 05535 as port 5535, we will not accept e.g.<br /> &amp;#39;sip:10.0.0.1:005060&amp;#39;. While its syntactically valid under RFC 3261,<br /> we should restrict this to not waste cycles when presented with<br /> malformed packets with 64k &amp;#39;0&amp;#39; characters.<br /> <br /> - Force base 10 in ct_sip_parse_numerical_param(). This is used to fetch<br /> &amp;#39;expire=&amp;#39; and &amp;#39;rports=&amp;#39;; both are expected to use base-10.<br /> <br /> - In nf_nat_sip.c, only accept the parsed value if its within the 1k-64k<br /> range.<br /> <br /> - epaddr_len now returns 0 if the port is invalid, as it already does<br /> for invalid ip addresses. This is intentional. nf_conntrack_sip<br /> performs lots of guesswork to find the right parts of the message<br /> to parse. Being stricter could break existing setups.<br /> Connection tracking helpers are designed to allow traffic to<br /> pass, not to block it.<br /> <br /> Based on an earlier patch from Jenny Guanni Qu .

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netdevsim: zero initialize struct iphdr in dummy sk_buff<br /> <br /> Syzbot reports a KMSAN uninit-value originating from<br /> nsim_dev_trap_skb_build, with the allocation also<br /> being performed in the same function.<br /> <br /> Fix this by calling skb_put_zero instead of skb_put to<br /> guarantee zero initialization of the whole IP header.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: netem: fix queue limit check to include reordered packets<br /> <br /> The queue limit check in netem_enqueue() uses q-&gt;t_len which only<br /> counts packets in the internal tfifo. Packets placed in sch-&gt;q by<br /> the reorder path (__qdisc_enqueue_head) are not counted, allowing<br /> the total queue occupancy to exceed sch-&gt;limit under reordering.<br /> <br /> Include sch-&gt;q.qlen in the limit check.