Vulnerabilities

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)

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.

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.

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

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.

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.

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.

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.

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;

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: v: stop OGMv2 on disabled interface<br /> <br /> When a batadv_hard_iface is disabled, its mesh_iface pointer is set to<br /> NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via<br /> batadv_v_ogm_queue_on_if() for interfaces that have since lost their<br /> mesh_iface association. This results in a NULL pointer dereference when<br /> batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the<br /> now NULL hard_iface-&gt;mesh_iface to retrieve the batadv_priv.<br /> <br /> It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that<br /> it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was<br /> called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: xt_policy: fix strict mode inbound policy matching<br /> <br /> match_policy_in() walks sec_path entries from the last transform to the<br /> first one, but strict policy matching needs to consume info-&gt;pol[] in<br /> the same forward order as the rule layout.<br /> <br /> Derive the strict-match policy position from the number of transforms<br /> already consumed so that multi-element inbound rules are matched<br /> consistently.