Vulnerabilidades

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: airoha: fix BQL imbalance in TX path<br /> <br /> Fix a possible BQL imbalance in airoha_dev_xmit(), where inflight<br /> packets are accounted only for the AIROHA_NUM_TX_RING netdev TX<br /> queues. The queue index is computed as:<br /> <br /> qid = skb_get_queue_mapping(skb) % ARRAY_SIZE(qdma-&gt;q_tx)<br /> txq = netdev_get_tx_queue(dev, qid);<br /> <br /> However, airoha_qdma_tx_napi_poll() accounts completions across all<br /> netdev TX queues (num_tx_queues), leading to inconsistent BQL<br /> accounting.<br /> <br /> Also reset all netdev TX queues in the ndo_stop callback.

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

*** 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 /> net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit()<br /> <br /> syzbot reported a KASAN slab-use-after-free read in rtl8150_start_xmit()<br /> when accessing skb-&gt;len for tx statistics after usb_submit_urb() has<br /> been called:<br /> <br /> BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760<br /> drivers/net/usb/rtl8150.c:712<br /> Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226<br /> <br /> The URB completion handler write_bulk_callback() frees the skb via<br /> dev_kfree_skb_irq(dev-&gt;tx_skb). The URB may complete on another CPU<br /> in softirq context before usb_submit_urb() returns in the submitter,<br /> so by the time the submitter reads skb-&gt;len the skb has already been<br /> queued to the per-CPU completion_queue and freed by net_tx_action():<br /> <br /> CPU A (xmit) CPU B (USB completion softirq)<br /> ------------ ------------------------------<br /> dev-&gt;tx_skb = skb;<br /> usb_submit_urb() --+<br /> |-------&gt; write_bulk_callback()<br /> | dev_kfree_skb_irq(dev-&gt;tx_skb)<br /> | net_tx_action()<br /> | napi_skb_cache_put() stats.tx_bytes |<br /> += skb-&gt;len; len before submitting the URB and using the<br /> cached value when updating the tx_bytes counter.<br /> <br /> The pre-existing tx_bytes semantics are preserved: the counter tracks<br /> the original frame length (skb-&gt;len), not the ETH_ZLEN/USB-alignment<br /> padded "count" value that is handed to the device. Changing that<br /> would be a user-visible accounting change and is out of scope for<br /> this UAF fix.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> neigh: let neigh_xmit take skb ownership<br /> <br /> neigh_xmit always releases the skb, except when no neighbour table is<br /> found. But even the first added user of neigh_xmit (mpls) relied on<br /> neigh_xmit to release the skb (or queue it for tx).<br /> <br /> sashiko reported:<br /> If neigh_xmit() is called with an uninitialized neighbor table (for<br /> example, NEIGH_ND_TABLE when IPv6 is disabled), it returns -EAFNOSUPPORT<br /> and bypasses its internal out_kfree_skb error path. Because the return<br /> value of neigh_xmit() is ignored here, does this leak the SKB?<br /> <br /> Assume full ownership and remove the last code path that doesn&amp;#39;t<br /> xmit or free skb.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/fair: Clear rel_deadline when initializing forked entities<br /> <br /> A yield-triggered crash can happen when a newly forked sched_entity<br /> enters the fair class with se-&gt;rel_deadline unexpectedly set.<br /> <br /> The failing sequence is:<br /> <br /> 1. A task is forked while se-&gt;rel_deadline is still set.<br /> 2. __sched_fork() initializes vruntime, vlag and other sched_entity<br /> state, but does not clear rel_deadline.<br /> 3. On the first enqueue, enqueue_entity() calls place_entity().<br /> 4. Because se-&gt;rel_deadline is set, place_entity() treats se-&gt;deadline<br /> as a relative deadline and converts it to an absolute deadline by<br /> adding the current vruntime.<br /> 5. However, the forked entity&amp;#39;s deadline is not a valid inherited<br /> relative deadline for this new scheduling instance, so the conversion<br /> produces an abnormally large deadline.<br /> 6. If the task later calls sched_yield(), yield_task_fair() advances<br /> se-&gt;vruntime to se-&gt;deadline.<br /> 7. The inflated vruntime is then used by the following enqueue path,<br /> where the vruntime-derived key can overflow when multiplied by the<br /> entity weight.<br /> 8. This corrupts cfs_rq-&gt;sum_w_vruntime, breaks EEVDF eligibility<br /> calculation, and can eventually make all entities appear ineligible.<br /> pick_next_entity() may then return NULL unexpectedly, leading to a<br /> later NULL dereference.<br /> <br /> A captured trace shows the effect clearly. Before yield, the entity&amp;#39;s<br /> vruntime was around:<br /> <br /> 9834017729983308<br /> <br /> After yield_task_fair() executed:<br /> <br /> se-&gt;vruntime = se-&gt;deadline<br /> <br /> the vruntime jumped to:<br /> <br /> 19668035460670230<br /> <br /> and the deadline was later advanced further to:<br /> <br /> 19668035463470230<br /> <br /> This shows that the deadline had already become abnormally large before<br /> yield_task_fair() copied it into vruntime.<br /> <br /> rel_deadline is only meaningful when se-&gt;deadline really carries a<br /> relative deadline that still needs to be placed against vruntime. A<br /> freshly forked sched_entity should not inherit or retain this state.<br /> Clear se-&gt;rel_deadline in __sched_fork(), together with the other<br /> sched_entity runtime state, so that the first enqueue does not interpret<br /> the new entity&amp;#39;s deadline as a stale relative deadline.