Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Reject SIOCATMARK on non-stream sockets<br /> <br /> SIOCATMARK reports whether the receive queue is at the urgent mark for<br /> MSG_OOB.<br /> <br /> In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets.<br /> SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(),<br /> so they should not support SIOCATMARK either.<br /> <br /> Return -EOPNOTSUPP for non-stream sockets before checking the receive<br /> queue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ebtables: fix OOB read in compat_mtw_from_user<br /> <br /> Luxiao Xu says:<br /> <br /> The function compat_mtw_from_user() converts ebtables extensions from<br /> 32-bit user structures to kernel native structures. However, it lacks<br /> proper validation of the user-supplied match_size/target_size.<br /> <br /> When certain extensions are processed, the kernel-side translation<br /> logic may perform memory accesses based on the extension&amp;#39;s expected<br /> size. If the user provides a size smaller than what the extension<br /> requires, it results in an out-of-bounds read as reported by KASAN.<br /> <br /> This fix introduces a check to ensure match_size is at least as large<br /> as the extension&amp;#39;s required compatsize. This covers matches, watchers,<br /> and targets, while maintaining compatibility with standard targets.<br /> <br /> AFAIU this is relevant for matches that need to go though<br /> match-&gt;compat_from_user() call. Those that use plain memcpy with the<br /> user-provided size are ok because the caller checks that size vs the<br /> start of the next rule entry offset (which itself is checked vs. total<br /> size copied from userspace).<br /> <br /> The -&gt;compat_from_user() callbacks assume they can read compatsize bytes,<br /> so they need this extra check.<br /> <br /> Based on an earlier patch from Luxiao Xu.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: clear current gateway during teardown<br /> <br /> batadv_gw_node_free() removes the gateway list entries during mesh teardown,<br /> but it does not clear the currently selected gateway. This leaves stale<br /> gateway state behind across cleanup and can break a later mesh recreation.<br /> <br /> Clear bat_priv-&gt;gw.curr_gw before walking the gateway list so the selected<br /> gateway reference is dropped as part of teardown.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vrf: Fix a potential NPD when removing a port from a VRF<br /> <br /> RCU readers that identified a net device as a VRF port using<br /> netif_is_l3_slave() assume that a subsequent call to<br /> netdev_master_upper_dev_get_rcu() will return a VRF device. They then<br /> continue to dereference its l3mdev operations.<br /> <br /> This assumption is not always correct and can result in a NPD [1]. There<br /> is no RCU synchronization when removing a port from a VRF, so it is<br /> possible for an RCU reader to see a new master device (e.g., a bridge)<br /> that does not have l3mdev operations.<br /> <br /> Fix by adding RCU synchronization after clearing the IFF_L3MDEV_SLAVE<br /> flag. Skip this synchronization when a net device is removed from a VRF<br /> as part of its deletion and when the VRF device itself is deleted. In<br /> the latter case an RCU grace period will pass by the time RTNL is<br /> released.<br /> <br /> [1]<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [...]<br /> RIP: 0010:l3mdev_fib_table_rcu (net/l3mdev/l3mdev.c:181)<br /> [...]<br /> Call Trace:<br /> <br /> l3mdev_fib_table_by_index (net/l3mdev/l3mdev.c:201 net/l3mdev/l3mdev.c:189)<br /> __inet_bind (net/ipv4/af_inet.c:499 (discriminator 3))<br /> inet_bind_sk (net/ipv4/af_inet.c:469)<br /> __sys_bind (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:1951 (discriminator 1))<br /> __x64_sys_bind (net/socket.c:1969 (discriminator 1) net/socket.c:1967 (discriminator 1) net/socket.c:1967 (discriminator 1))<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: dat: handle forward allocation error<br /> <br /> batadv_dat_forward_data() calls pskb_copy_for_clone() to duplicate an skb<br /> for each DHT candidate, but does not check the return value before passing<br /> it to batadv_send_skb_prepare_unicast_4addr(). That function dereferences<br /> the skb unconditionally, so a failed allocation triggers a NULL pointer<br /> dereference.<br /> <br /> Skip forwarding to the current DHT candidate on allocation failure.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ipset: stop hash:* range iteration at end<br /> <br /> The following hash set variants:<br /> <br /> hash:ip,mark<br /> hash:ip,port<br /> hash:ip,port,ip<br /> hash:ip,port,net<br /> <br /> iterate IPv4 ranges with a 32-bit iterator.<br /> <br /> The iterator must stop once the last address in the requested range has<br /> been processed. Advancing it once more can move the traversal state past<br /> the end of the request, so a later retry may continue from an unintended<br /> position.<br /> <br /> Handle the iterator increment explicitly at the end of the loop and stop<br /> once the upper bound has been processed. This keeps the existing retry<br /> behaviour intact for valid ranges while preventing traversal from<br /> continuing past the original boundary.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipc: limit next_id allocation to the valid ID range<br /> <br /> The checkpoint/restore sysctl path can request the next SysV IPC id<br /> through ids-&gt;next_id. ipc_idr_alloc() currently forwards that request to<br /> idr_alloc() with an open-ended upper bound.<br /> <br /> If the valid tail of the SysV IPC id space is full, the allocation can<br /> spill beyond ipc_mni. The returned SysV IPC id still uses the normal<br /> index encoding, so later lookup and removal can target the wrong slot. <br /> This leaves the real IDR entry behind and breaks the IDR state for the<br /> object.<br /> <br /> The bug is in ipc_idr_alloc() in the checkpoint/restore path.<br /> <br /> 1. ids-&gt;next_id is passed to:<br /> <br /> idr_alloc(&amp;ids-&gt;ipcs_idr, new, ipcid_to_idx(next_id), 0, ...)<br /> <br /> 2. The zero upper bound makes the allocation effectively open-ended.<br /> Once the valid SysV IPC tail is occupied, idr_alloc() can spill past<br /> ipc_mni and allocate an entry beyond the valid IPC id range.<br /> <br /> 3. The new object id is still encoded with the narrower SysV IPC index<br /> width:<br /> <br /> new-&gt;id = (new-&gt;seq

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: serialize accept_q access<br /> <br /> bt_sock_poll() walks the accept queue without synchronization, while<br /> child teardown can unlink the same socket and drop its last reference.<br /> The unsynchronized accept queue walk has existed since the initial<br /> Bluetooth import.<br /> <br /> Protect accept_q with a dedicated lock for queue updates and polling.<br /> Also rework bt_accept_dequeue() to take temporary child references under<br /> the queue lock before dropping it and locking the child socket.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: diag: reject stale associations in dump_one path<br /> <br /> The SCTP exact sock_diag lookup can hold a transport reference, block on<br /> lock_sock(sk), and then resume after sctp_association_free() has marked<br /> the association dead and freed its bind address list.<br /> <br /> When that happens, inet_assoc_attr_size() and<br /> inet_diag_msg_sctpasoc_fill() can still dereference association state<br /> that is no longer valid for reporting. In particular,<br /> inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a<br /> real sctp_sockaddr_entry and trigger an out-of-bounds read from<br /> unrelated association memory.<br /> <br /> Reject the association after taking the socket lock if it has been<br /> reaped or detached from the endpoint, and report the lookup as stale.<br /> This keeps the exact dump-one path from formatting torn association<br /> state.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: frag: disallow unicast fragment in fragment<br /> <br /> batadv_frag_skb_buffer() is called by batadv_batman_skb_recv() when a<br /> BATADV_UNICAST_FRAG packet is received. Once all fragments are collected<br /> and the packet is reassembled, batadv_recv_frag_packet() calls<br /> batadv_batman_skb_recv() again to process the defragmented payload.<br /> <br /> A malicious sender can craft a BATADV_UNICAST_FRAG packet whose reassembled<br /> payload is itself a BATADV_UNICAST_FRAG packet (matryoshka-style nesting).<br /> Each nesting level recurses through batadv_batman_skb_recv() without bound,<br /> growing the kernel stack until it is exhausted.<br /> <br /> Since refragmentation or fragments in fragments are not actually allowed,<br /> discard all packets which are still BATADV_UNICAST_FRAG packets after the<br /> defragmentation process.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ip6t_hbh: reject oversized option lists<br /> <br /> struct ip6t_opts stores at most IP6T_OPTS_OPTSNR option descriptors,<br /> but hbh_mt6_check() does not reject larger optsnr values supplied from<br /> userspace.<br /> <br /> Validate optsnr in the rule setup path so only match data that fits the<br /> fixed-size opts array can be installed. This follows the existing xtables<br /> pattern of rejecting invalid user-provided counts in checkentry() and<br /> keeps the packet matching path unchanged.<br /> <br /> `struct ip6t_opts` has a fixed `opts[IP6T_OPTS_OPTSNR]` array,<br /> where `IP6T_OPTS_OPTSNR` is 16, then off-by-one array access is possible:<br /> <br /> [ 137.924693][ T8692] UBSAN: array-index-out-of-bounds in ../net/ipv6/netfilter/ip6t_hbh.c:110:29<br /> [ 137.926167][ T8692] index 16 is out of range for type &amp;#39;__u16 [16]&amp;#39;

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: fix fragment reassembly length accounting<br /> <br /> batman-adv keeps a running payload length for queued fragments and uses it<br /> to validate a fragment chain before reassembly.<br /> <br /> That accounting currently allows the accumulated fragment length to be<br /> truncated during updates. As a result, malformed fragment chains can<br /> bypass the intended validation and drive reassembly with inconsistent<br /> length state, leading to a local denial of service.<br /> <br /> Fix the accounting by storing the accumulated length in a length-typed<br /> field and rejecting update overflows before the existing validation logic<br /> runs.<br /> <br /> The fix was verified against the original reproducer and against valid<br /> fragment reassembly paths.