Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()<br /> <br /> ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers.<br /> Let&amp;#39;s recompute nh pointer to make sure any change won&amp;#39;t mess things up.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macsec: fix replay protection at XPN lower-PN wrap<br /> <br /> In macsec_post_decrypt(), when pn is U32_MAX, pn + 1 overflows u32 to 0<br /> and the first branch never fires. If next_pn_halves.lower is also in the<br /> upper half, pn_same_half(pn, lower) is true and the XPN else-if does not<br /> fire either, leaving next_pn_halves unchanged. An attacker that captures<br /> the legitimate frame carrying pn == 0xFFFFFFFF on an XPN association<br /> can then replay it indefinitely, since lowest_pn never rises above<br /> the captured pn and macsec_decrypt() reconstructs the same IV.<br /> <br /> Extend the XPN else-if to also fire when pn + 1 wraps to 0, so receipt<br /> of pn == U32_MAX advances next_pn_halves to (upper + 1, 0).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: sockmap: fix tail fragment offset in bpf_msg_push_data<br /> <br /> When bpf_msg_push_data() inserts data in the middle of a scatterlist<br /> entry, it splits the original entry into a left fragment and a right<br /> fragment.<br /> <br /> The right fragment offset is page-local, but the code advances it with<br /> `start`, which is the message-global insertion point. For inserts into a<br /> non-first SG entry, this over-advances the offset and leaves the split<br /> layout inconsistent.<br /> <br /> Advance the right fragment offset by the fragment-local delta,<br /> `start - offset`, which matches the length removed from the front of the<br /> original entry.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: esp: restore combined single-frag length gate<br /> <br /> The ESP out-of-place fast path appends the trailer in esp_output_head()<br /> before esp_output_tail() allocates the destination page frag. The<br /> head-side gate currently checks skb-&gt;data_len and tailen separately, but<br /> the tail code allocates a single destination frag from the combined<br /> post-trailer skb-&gt;data_len.<br /> <br /> Reject the page-frag fast path when the combined aligned length exceeds a<br /> page. Otherwise skb_page_frag_refill() may fall back to a single page while<br /> the destination sg still spans the combined skb-&gt;data_len.<br /> <br /> Restore this combined-length page gate for both IPv4 and IPv6.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without direction check<br /> <br /> An unintended behavior in the TCP conntrack state machine allows a<br /> connection to be forced into the CLOSE state using an RST packet with an<br /> invalid sequence number.<br /> <br /> Specifically, after a SYN packet is observed, an RST with an invalid SEQ<br /> can transition the conntrack entry to TCP_CONNTRACK_CLOSE, regardless of<br /> whether the RST corresponds to the expected reply direction. The relevant<br /> code path assumes the RST is a response to an outgoing SYN, but does not<br /> validate packet direction or ensure that a matching SYN was actually sent<br /> in the opposite direction.<br /> <br /> As a result, a crafted packet sequence consisting of a SYN followed by an<br /> invalid-sequence RST can prematurely terminate an active NAT entry. This<br /> makes connection teardown easier than intended.<br /> <br /> So, tighten the state transition logic to ensure that RST-triggered<br /> CLOSE transitions only occur when the RST is a valid response to a<br /> previously observed SYN in the correct direction.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: route MIGRATE notifications to caller&amp;#39;s netns<br /> <br /> xfrm_send_migrate() in net/xfrm/xfrm_user.c and pfkey_send_migrate()<br /> in net/key/af_key.c both hardcode &amp;init_net for the multicast that<br /> announces a successful XFRM_MSG_MIGRATE / SADB_X_MIGRATE.<br /> <br /> XFRM_MSG_MIGRATE arrives on a per-netns NETLINK_XFRM socket, and the<br /> rest of the xfrm/af_key netlink path was made netns-aware in 2008.<br /> The other 14 multicast paths in xfrm_user.c route their event using<br /> xs_net(x), xp_net(xp) or sock_net(skb-&gt;sk); only the migrate path<br /> was missed.<br /> <br /> Two consequences of the init_net hardcoding:<br /> <br /> 1. The notification (selector, old/new endpoint addresses, and the<br /> km_address) is delivered to listeners on init_net&amp;#39;s<br /> XFRMNLGRP_MIGRATE / pfkey BROADCAST_ALL groups rather than on<br /> the issuing netns. An IKE daemon running in init_net therefore<br /> receives migration notifications originating from any other<br /> netns on the host.<br /> <br /> 2. An IKE daemon running inside a non-init netns and subscribed<br /> to its own XFRMNLGRP_MIGRATE / pfkey groups never receives the<br /> notification of its own migration. IKEv2 MOBIKE / address-update<br /> handling inside a netns is silently broken.<br /> <br /> Thread struct net through km_migrate() and the xfrm_mgr.migrate<br /> function pointer, drop the &amp;init_net override in xfrm_send_migrate()<br /> and pfkey_send_migrate(), and pass the caller&amp;#39;s net (already in<br /> scope in xfrm_migrate() via sock_net(skb-&gt;sk)) all the way down.<br /> struct xfrm_mgr is in-tree only and not exported as a stable API,<br /> so the function-pointer signature change is internal.<br /> <br /> pfkey_broadcast() is already netns-aware via net_generic(net,<br /> pfkey_net_id) since the pernet conversion. The five other<br /> pfkey_broadcast() callers in af_key.c already pass xs_net(x),<br /> sock_net(sk) or a per-netns net, so this only removes the<br /> &amp;init_net outlier.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: hci: fix out-of-bounds read in HCP header parsing<br /> <br /> Both nfc_hci_recv_from_llc() and nci_hci_data_received_cb() read<br /> packet-&gt;header from skb-&gt;data at function entry without first checking<br /> that the buffer holds at least one byte. A malicious NFC peer can send<br /> a 0-byte HCP frame that passes through the SHDLC layer and reaches<br /> these functions, causing an out-of-bounds heap read of packet-&gt;header.<br /> The same 0-byte frame, if queued as a non-final fragment, also causes<br /> the reassembly loop to underflow msg_len to UINT_MAX, triggering<br /> skb_over_panic() when the reassembled skb is written.<br /> <br /> Fix this by adding a pskb_may_pull() check at the entry of each<br /> function before packet-&gt;header is first accessed. The existing<br /> pskb_may_pull() checks before the reassembled hcp_skb is cast to<br /> struct hcp_packet remain in place to guard the 2-byte HCP message<br /> header.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: wacom: Fix OOB write in wacom_hid_set_device_mode()<br /> <br /> wacom_hid_set_device_mode() currently assumes that the HID_DG_INPUTMODE<br /> usage is always located in the first field (field[0]) of the feature report.<br /> However, a device can specify HID_DG_INPUTMODE in a different field.<br /> <br /> If HID_DG_INPUTMODE is in a field other than the first one and the first<br /> field has a report_count smaller than the usage_index of HID_DG_INPUTMODE,<br /> this leads to an out-of-bounds write to r-&gt;field[0]-&gt;value.<br /> <br /> Fix this by storing the field index of HID_DG_INPUTMODE in &amp;#39;struct<br /> hid_data&amp;#39; during feature mapping. In wacom_hid_set_device_mode(), use<br /> this stored field index to access the correct field and add bounds<br /> checks to ensure both the field index and the value index are within<br /> valid ranges before writing.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip6: vti: Use ip6_tnl.net in vti6_changelink().<br /> <br /> ip netns add ns1<br /> ip netns add ns2<br /> ip -n ns1 link add vti6_test type vti6 remote ::1 local ::2 key 7<br /> ip -n ns1 link set vti6_test netns ns2<br /> ip -n ns2 link set vti6_test type vti6 remote ::3 local ::4 key 9<br /> ip netns del ns2<br /> ip netns del ns1<br /> [ 132.495484] ------------[ cut here ]------------<br /> [ 132.497609] kernel BUG at net/core/dev.c:12376!<br /> <br /> Commit 61220ab34948 ("vti6: Enable namespace changing") dropped<br /> NETIF_F_NETNS_LOCAL from vti6 devices. A vti6 tunnel can then<br /> move through IFLA_NET_NS_FD. After the move dev_net(dev) points<br /> at the new netns while t-&gt;net stays at the creation netns.<br /> <br /> vti6_changelink() and vti6_update() still use dev_net(dev) and<br /> dev_net(t-&gt;dev). They unlink from one per netns hash and relink<br /> into another. The creation netns is left with a stale entry.<br /> cleanup_net() of that netns later walks freed memory.<br /> <br /> Reachable from an unprivileged user namespace (unshare --user<br /> --map-root-user --net). Cross tenant scope on container hosts.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: use refcount_inc_not_zero in l2tp_session_get_by_ifname<br /> <br /> A reader in l2tp_session_get_by_ifname() can return a pointer to a<br /> session whose refcount has reached zero. The getter takes its<br /> reference with plain refcount_inc(), but every other session getter<br /> in the same file (l2tp_v2_session_get, l2tp_v3_session_get, and the<br /> corresponding _get_next variants) uses refcount_inc_not_zero()<br /> because the IDR/RCU lookup can race with refcount_dec_and_test() -&gt;<br /> l2tp_session_free() -&gt; kfree_rcu(). The ifname getter is the only<br /> outlier; the inconsistency was raised on-list after 979c017803c4<br /> ("l2tp: use list_del_rcu in l2tp_session_unhash").<br /> <br /> A reader inside rcu_read_lock_bh() that matches session-&gt;ifname can<br /> be preempted between the strcmp() and the refcount_inc(). If the<br /> last reference drops on another CPU in that window, the reader&amp;#39;s<br /> refcount_inc() runs on a counter that has reached zero. refcount_t<br /> catches the addition-on-zero, prints "refcount_t: addition on 0;<br /> use-after-free", saturates the counter, and returns the saturated<br /> pointer to the caller. Session memory is held live by the in-flight<br /> RCU read section, but the kfree_rcu() callback queued from<br /> l2tp_session_free() will free it once the grace period closes; a<br /> caller that dereferences the returned session past that point hits<br /> a slab-use-after-free. On PREEMPT_RT local_bh_disable() is a per-CPU<br /> sleeping lock and the preemption window is real; on stock PREEMPT<br /> kernels local_bh_disable() is a preempt_count increment that closes<br /> the cross-CPU race in practice (see below).<br /> <br /> Use refcount_inc_not_zero() and continue the list walk on failure,<br /> matching the other session getters in the file. The ifname getter<br /> is the only session getter in net/l2tp/ that still uses the bare<br /> refcount_inc() pattern; this change restores file-internal<br /> consistency. The success path is unchanged.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: musb: omap2430: Fix use-after-free in omap2430_probe()<br /> <br /> In omap2430_probe(), of_node_put(np) is called prematurely before the<br /> last access to np, leading to a use-after-free if the node&amp;#39;s reference<br /> count drops to zero. Move the of_node_put() calls after the last use of<br /> np in both the success and error paths.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: OOB read regression in smb_check_perm_dacl() ACE-walk loops<br /> <br /> Commit d07b26f39246 ("ksmbd: require minimum ACE size in<br /> smb_check_perm_dacl()") introduced a transposed bounds check:<br /> <br /> if (offsetof(struct smb_ace, sid) + aces_size