Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vt: stabilize tty reference in kbd_keycode with tty_port_tty_get<br /> <br /> kbd_keycode() reads vc-&gt;port.tty without acquiring a tty reference,<br /> racing against con_shutdown() which clears port.tty under a different<br /> lock. Use tty_port_tty_get()/tty_kref_put() to hold a proper reference<br /> for the duration the tty pointer is needed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vt: add permission check for KDSKBMETA ioctl<br /> <br /> KDSKBMETA modifies keyboard meta mode but lacks the !perm check that all<br /> other keyboard setter ioctls in vt_k_ioctl() enforce, allowing a process<br /> to change meta mode on a non-controlling console without authorization.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: ipheth: fix carrier_work UAF on disconnect<br /> <br /> ipheth_sndbulk_callback() re-arms the carrier-check work on any<br /> non-zero URB status:<br /> <br /> else<br /> schedule_delayed_work(&amp;dev-&gt;carrier_work, 0);<br /> <br /> Nothing ties that to the interface being up, so the work can be armed<br /> again after ipheth_close() has already drained it, and stay armed<br /> until the netdev whose private area embeds it is freed.<br /> <br /> On unplug with a TX URB in flight, ipheth_disconnect() drains the work<br /> through unregister_netdev() -&gt; ipheth_close() -&gt;<br /> cancel_delayed_work_sync() and only then calls ipheth_kill_urbs().<br /> usb_kill_urb() completes the in-flight TX URB with -ENOENT, so<br /> ipheth_sndbulk_callback() runs after the drain and re-arms<br /> carrier_work.<br /> <br /> The same completion also re-arms the work if the interface is only<br /> brought down while a TX URB is in flight, and<br /> ipheth_carrier_check_work() then keeps re-queueing itself once a<br /> second. unregister_netdev() does not call ipheth_close() for an<br /> already-down interface, so nothing drains it on the later unplug<br /> either.<br /> <br /> In both cases free_netdev() frees the netdev while carrier_work is<br /> still pending, and ipheth_carrier_check_work() dereferences freed<br /> memory.<br /> <br /> Tie the work to the interface state instead of chasing the completion:<br /> disable it in ipheth_close() and enable it in ipheth_open(), so a<br /> schedule_delayed_work() from the URB completion is a no-op whenever<br /> the interface is not up. disable_delayed_work_sync() also waits for a<br /> running instance, so it fully replaces the cancel_delayed_work_sync()<br /> it takes the place of. The work starts out disabled in ipheth_probe()<br /> so the enable/disable counts balance from the first open.<br /> <br /> Reproduced under KASAN on linux-next (next-20260731) with dummy_hcd and<br /> raw-gadget standing in for the device, driving the second path above (the<br /> interface is already down, so unregister_netdev() does not call<br /> ipheth_close()): 15 of 15 unpatched boots report a slab-use-after-free in<br /> __run_timers(), freed by ipheth_disconnect() and re-armed from<br /> ipheth_sndbulk_callback() via queue_delayed_work_on(). The<br /> same trigger on a kernel differing only by this patch reports 0 of 15,<br /> and the carrier check still functions across open/close cycles.<br /> <br /> The reproducer needs an attached USB device that stops draining bulk OUT,<br /> plus a link down and unplug, driven as root. It is not a privilege<br /> boundary crossing and no exploit primitive was developed.<br /> <br /> Found by 0sec (https://0sec.ai).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: ax88179_178a: fix skb leak in ax88179_tx_fixup()<br /> <br /> When the interface has NETIF_F_SG enabled and skb_linearize() fails in<br /> ax88179_tx_fixup(), the function returns NULL without freeing the skb.<br /> <br /> usbnet_start_xmit() treats a NULL return from tx_fixup() as a drop<br /> (info-&gt;flags does not set FLAG_MULTI_PACKET for this driver), jumping<br /> to the "drop" label where it does `if (skb) dev_kfree_skb_any(skb)`.<br /> Because tx_fixup() returned NULL, the local skb variable in<br /> usbnet_start_xmit() is NULL, so the original skb is never freed — a<br /> memory leak on every TX frame whose linearization fails (i.e. under<br /> memory pressure).<br /> <br /> Free the skb before returning, matching the error handling already used<br /> for the pskb_expand_head() failure path in the same function.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: reject overly deep qdisc hierarchies<br /> <br /> Deep qdisc hierarchies can lead to excessive recursion in qdisc tree<br /> walkers and exhaust the kernel stack. The existing loop check does not<br /> cover the create-and-graft path, so a hierarchy can still be extended by<br /> creating a new child qdisc below an already deep parent.<br /> <br /> Store the hierarchy depth in struct Qdisc and update it when qdiscs are<br /> grafted. Reject new child qdiscs once the parent is already at the maximum<br /> allowed depth.

*** 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 /> net: fix skb length accounting after generic XDP frag adjustment<br /> <br /> Generic XDP exposes non-linear skb fragments through an xdp_buff. If an<br /> XDP program adjusts the fragment area, bpf_prog_run_generic_xdp() copies<br /> xdp_frags_size back to skb-&gt;data_len but leaves skb-&gt;len containing the<br /> old fragment contribution.<br /> <br /> After a fragment shrink, this makes skb_headlen() larger than the actual<br /> linear area. In the reproduced UDP receive path, __skb_datagram_iter()<br /> copied 1024 bytes past the actual linear tail to userspace, starting at<br /> struct skb_shared_info. The copied bytes included the affected skb&amp;#39;s<br /> nr_frags, xdp_frags_size and a kernel pointer from<br /> skb_shinfo(skb)-&gt;frags[0]. Real packet data was displaced by the same<br /> amount and truncated at the end.<br /> <br /> Subtract the old data_len before replacing it and add the new data_len<br /> afterwards, keeping skb-&gt;len and skb-&gt;data_len synchronized.<br /> <br /> A 60000-byte UDP datagram on a veth pair with MTU 64000 was shortened by<br /> 1024 bytes from its fragment area. Before the fix, all 10 runs produced<br /> corrupted payloads. After the fix, all 10 runs matched the expected<br /> payload exactly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> packet: synchronize pressure clearing with ring reconfiguration<br /> <br /> packet_set_ring() updates the RX ring state under sk_receive_queue.lock,<br /> but used to publish the tpacket receive mode through po-&gt;prot_hook.func<br /> after releasing that lock. packet_poll() and packet_recvmsg() can then<br /> run the pressure clearing path after the ring has been cleared while<br /> still seeing tpacket_rcv, causing __packet_rcv_has_room() to dereference<br /> stale or NULL ring storage.<br /> <br /> Move the existing receive hook assignment into the same<br /> sk_receive_queue.lock section as the ring state update. Keep the<br /> assignment otherwise unchanged, including on TX ring reconfiguration, to<br /> avoid adding behavior changes that are not required for the fix.<br /> <br /> Serialize packet_recvmsg() pressure clearing with the same queue lock<br /> only after PACKET_SOCK_PRESSURE has been observed. If the flag is clear<br /> and the socket has moved away from tpacket_rcv, packet_set_ring() has<br /> already detached the socket and waited for synchronize_net(), so no new<br /> packet input can set the flag again.<br /> <br /> packet_poll() already holds sk_receive_queue.lock, so it uses the new<br /> unlocked helper directly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/packet: reset the MAC header on the packet-socket transmit path<br /> <br /> packet_parse_headers() resets the MAC header only for a SOCK_RAW frame<br /> whose socket did not bind a protocol. A protocol-bound SOCK_RAW socket,<br /> any SOCK_DGRAM frame, and the legacy SOCK_PACKET path therefore leave<br /> skb-&gt;mac_header unset here.<br /> <br /> For frames sent via __dev_queue_xmit() this is harmless: it resets the<br /> MAC header unconditionally. But the packet-socket PACKET_QDISC_BYPASS<br /> path uses dev_direct_xmit(), which does not, so the frame reaches<br /> ndo_start_xmit() with the MAC header unset. A driver that reads<br /> eth_hdr(skb) on transmit then dereferences skb-&gt;head + (u16)~0, an<br /> out-of-bounds access ~64 KiB past the head -- the same class fixed for<br /> one consumer in commit f5089008f90c ("macsec: do not read an unset MAC<br /> header in macsec_encrypt()").<br /> <br /> packet_parse_headers() runs only on the transmit path, where skb-&gt;data<br /> points at the start of the L2 header for every packet-socket type<br /> regardless of its length: SOCK_RAW and SOCK_PACKET carry a user-supplied<br /> header and SOCK_DGRAM has one built by dev_hard_header(). Reset the MAC<br /> header unconditionally, mirroring __dev_queue_xmit(), so the frame is<br /> anchored on the bypass path too.<br /> <br /> Found by 0sec (https://0sec.ai) using automated source analysis;<br /> verified against source and matched to the macsec KASAN report in<br /> f5089008f90c. Compile-tested.

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