Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: stream: fully roll back denied add-stream state<br /> <br /> When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and<br /> then lowers outcnt. That leaves removed stream metadata behind, so a<br /> later re-add can reuse a stale ext and hit a null-pointer dereference in<br /> the scheduler get path.<br /> <br /> Fix the rollback by tearing down the removed stream state the same way<br /> other stream resizes do. Unschedule the current scheduler state, drop<br /> the removed stream ext state with sctp_stream_outq_migrate(), and then<br /> reschedule the remaining streams.<br /> <br /> This keeps scheduler-private RR/FC/PRIO lists consistent while fully<br /> rolling back denied outgoing stream additions.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: tvlv: reject oversized TVLV packets<br /> <br /> batadv_tvlv_container_ogm_append() builds a TVLV packet section from<br /> the tvlv.container_list. The total size of this section is computed by<br /> batadv_tvlv_container_list_size(), which sums the sizes of all registered<br /> containers.<br /> <br /> The return type and accumulator in batadv_tvlv_container_list_size() were<br /> u16. If the accumulated size exceeds U16_MAX, the value wraps around,<br /> causing the subsequent allocation in batadv_tvlv_container_ogm_append()<br /> to be undersized. The memcpy-style copy that follows would then write<br /> beyond the end of the allocated buffer, corrupting kernel memory.<br /> <br /> Fix this by widening the return type of batadv_tvlv_container_list_size()<br /> to size_t. In batadv_tvlv_container_ogm_append(), check the computed length<br /> against U16_MAX before proceeding, and bail out as if the allocation had<br /> failed when the limit is exceeded.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: purge outqueue on stale COOKIE-ECHO handling<br /> <br /> sctp_stream_update() is only invoked when the association is moved into<br /> COOKIE_WAIT during association setup/reconfiguration. In this path, the<br /> outbound stream scheduler state (stream-&gt;out_curr) is expected to be<br /> clean, since no user data should have been transmitted yet unless the<br /> state machine has already partially progressed.<br /> <br /> However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a<br /> Stale Cookie ERROR is received, the association is rolled back from<br /> COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already<br /> have been queued and even bundled with the COOKIE-ECHO chunk.<br /> <br /> During the rollback, sctp_stream_update() frees the old stream table<br /> and installs a new one, but it does not invalidate stream-&gt;out_curr.<br /> As a result, out_curr may still point to a freed sctp_stream_out<br /> entry from the previous stream state.<br /> <br /> Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on<br /> stream-&gt;out_curr-&gt;ext, which can lead to use-after-free once the old<br /> stream state has been released via sctp_stream_free().<br /> <br /> This results in crashes such as (reported by Yuqi):<br /> <br /> BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140<br /> Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312<br /> CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted<br /> 7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full)<br /> sctp_sched_fcfs_dequeue+0x13a/0x140<br /> sctp_outq_flush+0x1603/0x33e0<br /> sctp_do_sm+0x31c9/0x5d30<br /> sctp_assoc_bh_rcv+0x392/0x6f0<br /> sctp_inq_push+0x1db/0x270<br /> sctp_rcv+0x138d/0x3c10<br /> <br /> Fix this by fully purging the association outqueue when handling the<br /> Stale Cookie case. This ensures all pending transmit and retransmit<br /> state is dropped, and any scheduler cached pointers are invalidated,<br /> making it safe to rebuild stream state during COOKIE_WAIT restart.<br /> <br /> Updating only stream-&gt;out_curr would be insufficient, since queued<br /> and retransmittable data would still reference the old stream state and<br /> trigger later use-after-free in dequeue paths.

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