Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/dma: Cap dma_map_sg tracepoint arrays to prevent buffer overflow<br /> <br /> The dma_map_sg tracepoint can trigger a perf buffer overflow when<br /> tracing large scatter-gather lists. With devices like virtio-gpu<br /> creating large DRM buffers, nents can exceed 1000 entries, resulting<br /> in:<br /> <br /> phys_addrs: 1000 * 8 bytes = 8,000 bytes<br /> dma_addrs: 1000 * 8 bytes = 8,000 bytes<br /> lengths: 1000 * 4 bytes = 4,000 bytes<br /> Total: ~20,000 bytes<br /> <br /> This exceeds PERF_MAX_TRACE_SIZE (8192 bytes), causing:<br /> <br /> WARNING: CPU: 0 PID: 5497 at kernel/trace/trace_event_perf.c:405<br /> perf buffer not large enough, wanted 24620, have 8192<br /> <br /> Cap all three dynamic arrays at 128 entries using min() in the array<br /> size calculation. This ensures arrays are only as large as needed<br /> (up to the cap), avoiding unnecessary memory allocation for small<br /> operations while preventing overflow for large ones.<br /> <br /> The tracepoint now records the full nents/ents counts and a truncated<br /> flag so users can see when data has been capped.<br /> <br /> Changes in v2:<br /> - Use min(nents, DMA_TRACE_MAX_ENTRIES) for dynamic array sizing<br /> instead of fixed DMA_TRACE_MAX_ENTRIES allocation (feedback from<br /> Steven Rostedt)<br /> - This allocates only what&amp;#39;s needed up to the cap, avoiding waste<br /> for small operations<br /> <br /> Reviwed-by: Sean Anderson

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: xt_CT: drop pending enqueued packets on template removal<br /> <br /> Templates refer to objects that can go away while packets are sitting in<br /> nfqueue refer to:<br /> <br /> - helper, this can be an issue on module removal.<br /> - timeout policy, nfnetlink_cttimeout might remove it.<br /> <br /> The use of templates with zone and event cache filter are safe, since<br /> this just copies values.<br /> <br /> Flush these enqueued packets in case the template rule gets removed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: release flowtable after rcu grace period on error<br /> <br /> Call synchronize_rcu() after unregistering the hooks from error path,<br /> since a hook that already refers to this flowtable can be already<br /> registered, exposing this flowtable to packet path and nfnetlink_hook<br /> control plane.<br /> <br /> This error path is rare, it should only happen by reaching the maximum<br /> number hooks or by failing to set up to hardware offload, just call<br /> synchronize_rcu().<br /> <br /> There is a check for already used device hooks by different flowtable<br /> that could result in EEXIST at this late stage. The hook parser can be<br /> updated to perform this check earlier to this error path really becomes<br /> rarely exercised.<br /> <br /> Uncovered by KASAN reported as use-after-free from nfnetlink_hook path<br /> when dumping hooks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: cirrus: cs42l43: Fix double-put in cs42l43_pin_probe()<br /> <br /> devm_add_action_or_reset() already invokes the action on failure,<br /> so the explicit put causes a double-put.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Squashfs: check metadata block offset is within range<br /> <br /> Syzkaller reports a "general protection fault in squashfs_copy_data"<br /> <br /> This is ultimately caused by a corrupted index look-up table, which<br /> produces a negative metadata block offset.<br /> <br /> This is subsequently passed to squashfs_copy_data (via<br /> squashfs_read_metadata) where the negative offset causes an out of bounds<br /> access.<br /> <br /> The fix is to check that the offset is within range in<br /> squashfs_read_metadata. This will trap this and other cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix memory leak in ice_set_ringparam()<br /> <br /> In ice_set_ringparam, tx_rings and xdp_rings are allocated before<br /> rx_rings. If the allocation of rx_rings fails, the code jumps to<br /> the done label leaking both tx_rings and xdp_rings. Furthermore, if<br /> the setup of an individual Rx ring fails during the loop, the code jumps<br /> to the free_tx label which releases tx_rings but leaks xdp_rings.<br /> <br /> Fix this by introducing a free_xdp label and updating the error paths to<br /> ensure both xdp_rings and tx_rings are properly freed if rx_rings<br /> allocation or setup fails.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled<br /> <br /> When booting with the &amp;#39;ipv6.disable=1&amp;#39; parameter, the nd_tbl is never<br /> initialized because inet6_init() exits before ndisc_init() is called<br /> which initializes it. Then, if neigh_suppress is enabled and an ICMPv6<br /> Neighbor Discovery packet reaches the bridge, br_do_suppress_nd() will<br /> dereference ipv6_stub-&gt;nd_tbl which is NULL, passing it to<br /> neigh_lookup(). This causes a kernel NULL pointer dereference.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000268<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [...]<br /> RIP: 0010:neigh_lookup+0x16/0xe0<br /> [...]<br /> Call Trace:<br /> <br /> ? neigh_lookup+0x16/0xe0<br /> br_do_suppress_nd+0x160/0x290 [bridge]<br /> br_handle_frame_finish+0x500/0x620 [bridge]<br /> br_handle_frame+0x353/0x440 [bridge]<br /> __netif_receive_skb_core.constprop.0+0x298/0x1110<br /> __netif_receive_skb_one_core+0x3d/0xa0<br /> process_backlog+0xa0/0x140<br /> __napi_poll+0x2c/0x170<br /> net_rx_action+0x2c4/0x3a0<br /> handle_softirqs+0xd0/0x270<br /> do_softirq+0x3f/0x60<br /> <br /> Fix this by replacing IS_ENABLED(IPV6) call with ipv6_mod_enabled() in<br /> the callers. This is in essence disabling NS/NA suppression when IPv6 is<br /> disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them<br /> <br /> In commit 2ff5baa9b527 ("HID: appleir: Fix potential NULL dereference at<br /> raw event handle"), we handle the fact that raw event callbacks<br /> can happen even for a HID device that has not been "claimed" causing a<br /> crash if a broken device were attempted to be connected to the system.<br /> <br /> Fix up the remaining in-tree HID drivers that forgot to add this same<br /> check to resolve the same issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing<br /> <br /> struct bpf_plt contains a u64 target field. Currently, the BPF JIT<br /> allocator requests an alignment of 4 bytes (sizeof(u32)) for the JIT<br /> buffer.<br /> <br /> Because the base address of the JIT buffer can be 4-byte aligned (e.g.,<br /> ending in 0x4 or 0xc), the relative padding logic in build_plt() fails<br /> to ensure that target lands on an 8-byte boundary.<br /> <br /> This leads to two issues:<br /> 1. UBSAN reports misaligned-access warnings when dereferencing the<br /> structure.<br /> 2. More critically, target is updated concurrently via WRITE_ONCE() in<br /> bpf_arch_text_poke() while the JIT&amp;#39;d code executes ldr. On arm64,<br /> 64-bit loads/stores are only guaranteed to be single-copy atomic if<br /> they are 64-bit aligned. A misaligned target risks a torn read,<br /> causing the JIT to jump to a corrupted address.<br /> <br /> Fix this by increasing the allocation alignment requirement to 8 bytes<br /> (sizeof(u64)) in bpf_jit_binary_pack_alloc(). This anchors the base of<br /> the JIT buffer to an 8-byte boundary, allowing the relative padding math<br /> in build_plt() to correctly align the target field.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/ionic: Fix kernel stack leak in ionic_create_cq()<br /> <br /> struct ionic_cq_resp resp {<br /> __u32 cqid[2]; // offset 0 - PARTIALLY SET (see below)<br /> __u8 udma_mask; // offset 8 - SET (resp.udma_mask = vcq-&gt;udma_mask)<br /> __u8 rsvd[7]; // offset 9 - NEVER SET udma_mask &amp; BIT(udma_idx)). The array has 2 entries but<br /> udma_count could be 1, meaning cqid[1] might never be written via<br /> ionic_create_cq_common(). If udma_mask only has bit 0 set, cqid[1] (4<br /> bytes) is also leaked. So potentially 11 bytes leaked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: clone set on flush only<br /> <br /> Syzbot with fault injection triggered a failing memory allocation with<br /> GFP_KERNEL which results in a WARN splat:<br /> <br /> iter.err<br /> WARNING: net/netfilter/nf_tables_api.c:845 at nft_map_deactivate+0x34e/0x3c0 net/netfilter/nf_tables_api.c:845, CPU#0: syz.0.17/5992<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 5992 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026<br /> RIP: 0010:nft_map_deactivate+0x34e/0x3c0 net/netfilter/nf_tables_api.c:845<br /> Code: 8b 05 86 5a 4e 09 48 3b 84 24 a0 00 00 00 75 62 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc e8 63 6d fa f7 90 0b 90 43<br /> +80 7c 35 00 00 0f 85 23 fe ff ff e9 26 fe ff ff 89 d9<br /> RSP: 0018:ffffc900045af780 EFLAGS: 00010293<br /> RAX: ffffffff89ca45bd RBX: 00000000fffffff4 RCX: ffff888028111e40<br /> RDX: 0000000000000000 RSI: 00000000fffffff4 RDI: 0000000000000000<br /> RBP: ffffc900045af870 R08: 0000000000400dc0 R09: 00000000ffffffff<br /> R10: dffffc0000000000 R11: fffffbfff1d141db R12: ffffc900045af7e0<br /> R13: 1ffff920008b5f24 R14: dffffc0000000000 R15: ffffc900045af920<br /> FS: 000055557a6a5500(0000) GS:ffff888125496000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fb5ea271fc0 CR3: 000000003269e000 CR4: 00000000003526f0<br /> Call Trace:<br /> <br /> __nft_release_table+0xceb/0x11f0 net/netfilter/nf_tables_api.c:12115<br /> nft_rcv_nl_event+0xc25/0xdb0 net/netfilter/nf_tables_api.c:12187<br /> notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85<br /> blocking_notifier_call_chain+0x6a/0x90 kernel/notifier.c:380<br /> netlink_release+0x123b/0x1ad0 net/netlink/af_netlink.c:761<br /> __sock_release net/socket.c:662 [inline]<br /> sock_close+0xc3/0x240 net/socket.c:1455<br /> <br /> Restrict set clone to the flush set command in the preparation phase.<br /> Add NFT_ITER_UPDATE_CLONE and use it for this purpose, update the rbtree<br /> and pipapo backends to only clone the set when this iteration type is<br /> used.<br /> <br /> As for the existing NFT_ITER_UPDATE type, update the pipapo backend to<br /> use the existing set clone if available, otherwise use the existing set<br /> representation. After this update, there is no need to clone a set that<br /> is being deleted, this includes bound anonymous set.<br /> <br /> An alternative approach to NFT_ITER_UPDATE_CLONE is to add a .clone<br /> interface and call it from the flush set path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gve: fix incorrect buffer cleanup in gve_tx_clean_pending_packets for QPL<br /> <br /> In DQ-QPL mode, gve_tx_clean_pending_packets() incorrectly uses the RDA<br /> buffer cleanup path. It iterates num_bufs times and attempts to unmap<br /> entries in the dma array.<br /> <br /> This leads to two issues:<br /> 1. The dma array shares storage with tx_qpl_buf_ids (union).<br /> Interpreting buffer IDs as DMA addresses results in attempting to<br /> unmap incorrect memory locations.<br /> 2. num_bufs in QPL mode (counting 2K chunks) can significantly exceed<br /> the size of the dma array, causing out-of-bounds access warnings<br /> (trace below is how we noticed this issue).<br /> <br /> UBSAN: array-index-out-of-bounds in<br /> drivers/net/ethernet/drivers/net/ethernet/google/gve/gve_tx_dqo.c:178:5 index 18 is out of<br /> range for type &amp;#39;dma_addr_t[18]&amp;#39; (aka &amp;#39;unsigned long long[18]&amp;#39;)<br /> Workqueue: gve gve_service_task [gve]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x33/0xa0<br /> __ubsan_handle_out_of_bounds+0xdc/0x110<br /> gve_tx_stop_ring_dqo+0x182/0x200 [gve]<br /> gve_close+0x1be/0x450 [gve]<br /> gve_reset+0x99/0x120 [gve]<br /> gve_service_task+0x61/0x100 [gve]<br /> process_scheduled_works+0x1e9/0x380<br /> <br /> Fix this by properly checking for QPL mode and delegating to<br /> gve_free_tx_qpl_bufs() to reclaim the buffers.