Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> packet: use consistent hard_header_len in TX_RING send path<br /> <br /> tpacket_snd() reads dev-&gt;hard_header_len independently for skb<br /> allocation and header construction in tpacket_fill_skb(). Concurrent<br /> netdevice reconfiguration can therefore make the reserved headroom<br /> smaller than the amount later pushed, or make copylen - hard_header_len<br /> negative.<br /> <br /> Snapshot hard_header_len once before processing ring frames and use it<br /> for the frame limit, headroom allocation, copy length, and skb<br /> construction. Pass the snapshot to tpacket_fill_skb().<br /> <br /> The separate SOCK_DGRAM consistency problem between hard_header_len and<br /> header_ops-&gt;create is not addressed here.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: clear IPv4 options after rebasing tunnel ICMP errors<br /> <br /> ip_vs_in_icmp() rebases an skb from the outer ICMP packet to the<br /> quoted original request before passing it to icmp_send(). However,<br /> IPCB(skb)-&gt;opt still describes the outer IPv4 header.<br /> <br /> A timestamp option in the outer header can therefore leave an offset<br /> that points into the quoted transport header after the rebase.<br /> __ip_options_echo() treats a byte at that stale location as the option<br /> length and copies it into the fixed-size option storage on the<br /> __icmp_send() stack, causing a stack out-of-bounds write.<br /> <br /> Clear the stale option metadata after resetting the network header.<br /> Keep the remaining control block fields, including the ingress<br /> interface used by the ICMP response path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: stop estimator after disabled calc phase<br /> <br /> IPVS estimator kthread 0 starts with zeroed chain and tick limits until<br /> its initial calculation phase completes. If network namespace teardown<br /> clears ipvs-&gt;enable during that phase, ip_vs_est_calc_phase() can return<br /> without installing positive limits.<br /> <br /> The kthread can then continue into its main loop and drain<br /> est_temp_list with zero chain_max, tick_max and est_max_count values.<br /> Each enqueue consumes one available tick row, but est_count never<br /> reaches the zero est_max_count value. After all rows are consumed, the<br /> row lookup returns IPVS_EST_NTICKS and ip_vs_enqueue_estimator() writes<br /> past the ticks and tick_len arrays.<br /> <br /> Exit kthread 0 after the calculation phase if the kthread is stopping or<br /> IPVS has been disabled. That keeps temporary estimators from being<br /> drained after the limits failed to initialize.<br /> <br /> Estimator kthreads can now self-exit before teardown or reload stops<br /> kd-&gt;task. Keep an extra task reference after creation and release it<br /> with kthread_stop_put(), so kd-&gt;task remains valid until the stop paths<br /> consume that reference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: reallocate update replies for mismatched IDs<br /> <br /> ovs_flow_cmd_new() preallocates the optional reply skb before it takes<br /> ovs_mutex and before it knows which existing flow will be updated.<br /> <br /> That is normally fine because the skb is sized from the request flow<br /> identifier. That identifier also becomes the inserted flow&amp;#39;s identifier.<br /> For updates, however, a request with a UFID may miss the UFID lookup and<br /> then fall back to the flow key lookup. That lookup can legitimately find<br /> an existing key-identified flow. UFIDs are optional and the flow key is<br /> the primary identifier.<br /> <br /> For echoed replies, ovs_flow_cmd_fill_info() writes the matched flow&amp;#39;s<br /> identifier, not the request identifier used for the preallocation. A short<br /> request UFID can therefore leave too little room for the key identifier.<br /> The fill can then fail with -EMSGSIZE and hit the BUG_ON(error

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: qcom-geni: fix TX DMA buffer flush<br /> <br /> When transmit flushing a qcom-geni UART during an ongoing TX DMA, the<br /> UART gets stuck infinitely repeating corrupted TX DMA frames.<br /> <br /> The DMA-mode uart_ops does not provide a flush_buffer callback, so an<br /> in-flight transfer can complete after serial core has reset the transmit<br /> kfifo, underflowing its length and resubmitting page-sized transfers<br /> indefinitely. Add one that stops the transfer and clears tx_remaining<br /> and tx_queued.<br /> <br /> The stop path was also broken: it unmapped the buffer while the serial<br /> engine could still read it, and never reset the TX DMA state machine.<br /> Cancel the main sequencer command first, then reset the state machine<br /> and wait for it before unmapping. Drop the early return so a pending<br /> mapping is also cleaned up when the main command is inactive.<br /> <br /> The bug can be triggered from userspace with a large write immediately<br /> followed by TCOFLUSH. A following tcdrain will hang forever. The bug was<br /> reproduced and this fix was validated on Arduino Uno Q (QRB2210)<br /> using /dev/ttyHS1.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: fix use-after-free in fib_nhc_update_mtu()<br /> <br /> fib_nhc_update_mtu() walks the nexthop exception table under RTNL, but<br /> RTNL does not serialize this walk with PMTU exception updates. The walk<br /> uses rcu_dereference_protected() with a constant true condition without<br /> holding fnhe_lock.<br /> <br /> The following interleaving can therefore occur:<br /> <br /> CPU 0 CPU 1<br /> fib_nhc_update_mtu() update_or_create_fnhe()<br /> load fnhe spin_lock_bh(&amp;fnhe_lock)<br /> fnhe_remove_oldest()<br /> unlink fnhe<br /> kfree_rcu(fnhe, rcu)<br /> <br /> access fnhe after grace period<br /> <br /> KASAN reported:<br /> <br /> BUG: KASAN: slab-use-after-free in fib_nhc_update_mtu+0x3df/0x410<br /> Read of size 8 at addr ffff888107d49000 by task poc/90<br /> Call Trace:<br /> fib_nhc_update_mtu+0x3df/0x410<br /> fib_sync_mtu+0x7a/0xd0<br /> fib_netdev_event+0x229/0x3f0<br /> netif_set_mtu_ext+0x33a/0x570<br /> dev_set_mtu+0x88/0x120<br /> <br /> The same walk updates fnhe_pmtu and fnhe_mtu_locked. These fields form a<br /> pair and other writers serialize them with fnhe_lock. RCU alone prevents<br /> reclamation, but would still allow concurrent writers to leave a mixed<br /> pair.<br /> <br /> Walk the table under RCU and acquire fnhe_lock only while updating each<br /> exception. RCU keeps the current entry alive while the short critical<br /> section serializes its paired PMTU fields. This avoids holding the global<br /> lock while scanning all 2048 buckets for every nexthop.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ebt_nflog: pin the NFLOG backend<br /> <br /> nf_log_unregister() runs after the per-net teardown so its final RCU<br /> grace period also drains readers that obtained the logger from a per-net<br /> binding. However, ebt_nflog passes an explicit ULOG log type to<br /> nf_log_packet() without holding a reference on the selected logger module,<br /> unlike the xt_NFLOG and nft_log frontends.<br /> <br /> An ebtables nflog rule can therefore remain callable while nfnetlink_log<br /> is unloaded. The resulting interleaving is:<br /> <br /> CPU 0 CPU 1<br /> nfnetlink_log_fini()<br /> unregister_pernet_subsys()<br /> kfree(nfnl_log_pernet(net))<br /> ebt_nflog_tg()<br /> nf_log_packet()<br /> nfulnl_log_packet()<br /> instance_lookup_get_rcu()<br /> <br /> The global ULOG logger is still registered at this point, so CPU 1<br /> dereferences the per-net state after CPU 0 has freed it. KASAN reported:<br /> <br /> BUG: KASAN: slab-use-after-free in instance_lookup_get_rcu<br /> Read of size 8 at addr ff110001052e6210 by task poc/92<br /> Call Trace:<br /> instance_lookup_get_rcu+0x1ce/0x1f0 [nfnetlink_log]<br /> nfulnl_log_packet+0x248/0x2fb0 [nfnetlink_log]<br /> nf_log_packet+0x204/0x300<br /> ebt_nflog_tg+0x351/0x550<br /> ebt_do_table+0xedf/0x22b0<br /> Allocated by task 90:<br /> __kmalloc_noprof+0x186/0x470<br /> ops_init+0x6d/0x420<br /> register_pernet_operations+0x2f6/0x670<br /> register_pernet_subsys+0x23/0x40<br /> Freed by task 93:<br /> kfree+0x131/0x3c0<br /> ops_undo_list+0x3e3/0x700<br /> unregister_pernet_operations+0x232/0x490<br /> unregister_pernet_subsys+0x1c/0x30<br /> nfnetlink_log_fini+0x34/0x450 [nfnetlink_log]<br /> <br /> Acquire the ULOG logger module reference when an ebt_nflog rule is<br /> validated and release it when the rule is destroyed. Request the NFLOG<br /> backend for legacy callers when needed, matching xt_NFLOG. This prevents<br /> module teardown until all ebt_nflog rules have stopped using the logger.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac802154: fix netdev use-after-free in beacon worker<br /> <br /> mac802154_beacon_worker() reads local-&gt;beacon_req under RCU and derives<br /> the sub-interface from the request, but then drops the RCU read lock and<br /> continues to use both sdata and the embedded wpan_dev.<br /> <br /> mac802154_stop_beacons_locked() cancels only pending beacon work, clears<br /> local-&gt;beacon_req and frees the request. A beacon worker that is already<br /> running can therefore continue after interface teardown and dereference<br /> the freed netdev private area.<br /> <br /> The scan worker already pins the netdev before leaving RCU. Apply the<br /> same lifetime rule to the beacon worker: take a netdev reference while<br /> the request is still protected by RCU, and release it on all paths that<br /> continue after the reference is acquired.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> inet: frags: publish queues before arming timer<br /> <br /> inet_frag_create() arms the fragment queue timer before inserting the<br /> queue into the fqdir rhashtable. If the namespace fragment timeout is<br /> zero or negative, the timer can run before the queue is published.<br /> <br /> The timer callback then marks the queue complete, tries to remove a node<br /> that is not in the hash table yet, and drops the anticipated hash<br /> reference. Creation can subsequently publish the completed queue without<br /> restoring that reference, leaving a stale hash node after the caller drops<br /> the remaining reference.<br /> <br /> Publish the queue first and arm the timer while holding the queue lock.<br /> This makes timer expiry wait until the queue is visible in the hash table,<br /> so inet_frag_kill() can remove the node and balance the hash reference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: Fix fib_nlmsg_size() for RTA_VIA nexthops<br /> <br /> fib_nlmsg_size() still estimates nexthop space as if every gateway is<br /> encoded as an IPv4 RTA_GATEWAY attribute. IPv4 routes can also carry an<br /> IPv6 gateway, which fib_nexthop_info() dumps as RTA_VIA.<br /> <br /> As a result, route notifications can allocate an skb that is too small.<br /> fib_dump_info() then fails with -EMSGSIZE and rtmsg_fib() hits the<br /> WARN_ON() that marks such failures as a fib_nlmsg_size() bug. With<br /> panic_on_warn set, this becomes a kernel panic.<br /> <br /> Mirror the actual nexthop dump layout in fib_nlmsg_size(): account for<br /> IPv6 nexthop gateways dumped as RTA_VIA, for the no-header rtnexthop<br /> layout used inside RTA_MULTIPATH, and for RTA_FLOW only when it is<br /> actually present.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> futex: Prevent robust futex exit race some more<br /> <br /> A robust futex unlock stores 0 over the whole futex value - wiping<br /> FUTEX_WAITERS - and wakes a single waiter. That wakeup is a one-shot<br /> notification: the protocol relies on its recipient to either acquire the<br /> futex (and eventually unlock while aware of the remaining contention) or<br /> re-arm FUTEX_WAITERS before sleeping again. If the woken waiter is killed<br /> before it can do either, the kernel must jump in and wake the next task<br /> down the line.<br /> <br /> This is a known complication of the futex protocol with a previous<br /> partial fix in commit ca16d5bee598 ("futex: Prevent robust futex exit<br /> race"). Unfortunately, that fix is insufficient.<br /> <br /> If a third task re-acquired the futex through the uncontended fast<br /> path in the meantime, the notification is lost: robust exit processing<br /> sees that it is owned by another task and does nothing, while the new<br /> owner sees no FUTEX_WAITERS when it unlocks and wakes nobody.<br /> The remaining waiters sleep forever behind a free futex:<br /> <br /> A owns the futex, B and C sleep in FUTEX_WAIT<br /> uval == A | FUTEX_WAITERS<br /> A robust unlock: store 0, FUTEX_WAKE(1) wakes B<br /> uval == 0<br /> D fast path acquire: cmpxchg(0 -&gt; D)<br /> uval == D, no FUTEX_WAITERS<br /> B killed before acting on the wakeup<br /> B exit walk, pending op: owner D != B -&gt; no action<br /> D unlock: no FUTEX_WAITERS -&gt; no wake<br /> C sleeps forever<br /> <br /> This is clearly a shortcoming in the implementation, which fails to keep<br /> the FUTEX_WAITERS bit consistent.<br /> <br /> Work around this by augmenting the robust list exit processing to also<br /> perform the extra wakeup if the futex word is owned by another thread but<br /> FUTEX_WAITERS is not set.<br /> <br /> This does not fix the problem of a non-contended take over/release and free<br /> sequence, which has been discussed for years and has been addressed by<br /> commit 3ca9595d9fb6 ("futex: Add support for unlocking robust futexes") and<br /> subsequent changes, but failed to take the problem described above into<br /> account.<br /> <br /> A more complete solution which is based on the in kernel unlock of<br /> contended robust futexes has been discussed in the context of this change<br /> and should show up in mainline sooner than later.<br /> <br /> [ tglx: Amend change log slightly and fixup coding style ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bridge: mrp: fix uninitialised bytes on the wire<br /> <br /> br_mrp_alloc_test_skb() builds MRP test frames on an skb from<br /> dev_alloc_skb(), which does not clear the linear data area. On the MRA<br /> ring-role branch the sub-option TLV header is appended with<br /> <br /> sub_tlv = skb_put(skb, sizeof(*sub_tlv));<br /> sub_tlv-&gt;type = BR_MRP_SUB_TLV_HEADER_TEST_AUTO_MGR;<br /> <br /> so sub_tlv-&gt;length is never written, and the two trailing alignment bytes<br /> are appended with a bare skb_put() that does not clear them either. The<br /> neighbouring oui and sub_opt regions are explicitly zeroed, so three<br /> uninitialised bytes are left in every MRA MRP_Test frame that goes out.<br /> <br /> Put the sub-option TLV header and the alignment padding in a single<br /> skb_put_zero(), which clears both. The AUTO_MGR sub-TLV carries no<br /> payload, so the zeroed length field is already the value it should have.