Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix WARN_ON in tracing_buffers_mmap_close<br /> <br /> When a process forks, the child process copies the parent&amp;#39;s VMAs but the<br /> user_mapped reference count is not incremented. As a result, when both the<br /> parent and child processes exit, tracing_buffers_mmap_close() is called<br /> twice. On the second call, user_mapped is already 0, causing the function to<br /> return -ENODEV and triggering a WARN_ON.<br /> <br /> Normally, this isn&amp;#39;t an issue as the memory is mapped with VM_DONTCOPY set.<br /> But this is only a hint, and the application can call<br /> madvise(MADVISE_DOFORK) which resets the VM_DONTCOPY flag. When the<br /> application does that, it can trigger this issue on fork.<br /> <br /> Fix it by incrementing the user_mapped reference count without re-mapping<br /> the pages in the VMA&amp;#39;s open callback.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blktrace: fix __this_cpu_read/write in preemptible context<br /> <br /> tracing_record_cmdline() internally uses __this_cpu_read() and<br /> __this_cpu_write() on the per-CPU variable trace_cmdline_save, and<br /> trace_save_cmdline() explicitly asserts preemption is disabled via<br /> lockdep_assert_preemption_disabled(). These operations are only safe<br /> when preemption is off, as they were designed to be called from the<br /> scheduler context (probe_wakeup_sched_switch() / probe_wakeup()).<br /> <br /> __blk_add_trace() was calling tracing_record_cmdline(current) early in<br /> the blk_tracer path, before ring buffer reservation, from process<br /> context where preemption is fully enabled. This triggers the following<br /> using blktests/blktrace/002:<br /> <br /> blktrace/002 (blktrace ftrace corruption with sysfs trace) [failed]<br /> runtime 0.367s ... 0.437s<br /> something found in dmesg:<br /> [ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33<br /> [ 81.239580] null_blk: disk nullb1 created<br /> [ 81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516<br /> [ 81.362842] caller is tracing_record_cmdline+0x10/0x40<br /> [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full)<br /> [ 81.362877] Tainted: [N]=TEST<br /> [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014<br /> [ 81.362881] Call Trace:<br /> [ 81.362884] <br /> [ 81.362886] dump_stack_lvl+0x8d/0xb0<br /> ...<br /> (See &amp;#39;/mnt/sda/blktests/results/nodev/blktrace/002.dmesg&amp;#39; for the entire message)<br /> <br /> [ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33<br /> [ 81.239580] null_blk: disk nullb1 created<br /> [ 81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516<br /> [ 81.362842] caller is tracing_record_cmdline+0x10/0x40<br /> [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full)<br /> [ 81.362877] Tainted: [N]=TEST<br /> [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014<br /> [ 81.362881] Call Trace:<br /> [ 81.362884] <br /> [ 81.362886] dump_stack_lvl+0x8d/0xb0<br /> [ 81.362895] check_preemption_disabled+0xce/0xe0<br /> [ 81.362902] tracing_record_cmdline+0x10/0x40<br /> [ 81.362923] __blk_add_trace+0x307/0x5d0<br /> [ 81.362934] ? lock_acquire+0xe0/0x300<br /> [ 81.362940] ? iov_iter_extract_pages+0x101/0xa30<br /> [ 81.362959] blk_add_trace_bio+0x106/0x1e0<br /> [ 81.362968] submit_bio_noacct_nocheck+0x24b/0x3a0<br /> [ 81.362979] ? lockdep_init_map_type+0x58/0x260<br /> [ 81.362988] submit_bio_wait+0x56/0x90<br /> [ 81.363009] __blkdev_direct_IO_simple+0x16c/0x250<br /> [ 81.363026] ? __pfx_submit_bio_wait_endio+0x10/0x10<br /> [ 81.363038] ? rcu_read_lock_any_held+0x73/0xa0<br /> [ 81.363051] blkdev_read_iter+0xc1/0x140<br /> [ 81.363059] vfs_read+0x20b/0x330<br /> [ 81.363083] ksys_read+0x67/0xe0<br /> [ 81.363090] do_syscall_64+0xbf/0xf00<br /> [ 81.363102] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 81.363106] RIP: 0033:0x7f281906029d<br /> [ 81.363111] Code: 31 c0 e9 c6 fe ff ff 50 48 8d 3d 66 63 0a 00 e8 59 ff 01 00 66 0f 1f 84 00 00 00 00 00 80 3d 41 33 0e 00 00 74 17 31 c0 0f 05 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec<br /> [ 81.363113] RSP: 002b:00007ffca127dd48 EFLAGS: 00000246 ORIG_RAX: 0000000000000000<br /> [ 81.363120] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f281906029d<br /> [ 81.363122] RDX: 0000000000001000 RSI: 0000559f8bfae000 RDI: 0000000000000000<br /> [ 81.363123] RBP: 0000000000001000 R08: 0000002863a10a81 R09: 00007f281915f000<br /> [ 81.363124] R10: 00007f2818f77b60 R11: 0000000000000246 R12: 0000559f8bfae000<br /> [ 81.363126] R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000a<br /> [ 81.363142] <br /> <br /> The same BUG fires from blk_add_trace_plug(), blk_add_trace_unplug(),<br /> and blk_add_trace_rq() paths as well.<br /> <br /> The purpose of tracin<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz<br /> <br /> The only user of frag_size field in XDP RxQ info is<br /> bpf_xdp_frags_increase_tail(). It clearly expects whole buff size instead<br /> of DMA write size. Different assumptions in ice driver configuration lead<br /> to negative tailroom.<br /> <br /> This allows to trigger kernel panic, when using<br /> XDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver test and changing packet size to<br /> 6912 and the requested offset to a huge value, e.g.<br /> XSK_UMEM__MAX_FRAME_SIZE * 100.<br /> <br /> Due to other quirks of the ZC configuration in ice, panic is not observed<br /> in ZC mode, but tailroom growing still fails when it should not.<br /> <br /> Use fill queue buffer truesize instead of DMA write size in XDP RxQ info.<br /> Fix ZC mode too by using the new helper.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_ife: Fix metalist update behavior<br /> <br /> Whenever an ife action replace changes the metalist, instead of<br /> replacing the old data on the metalist, the current ife code is appending<br /> the new metadata. Aside from being innapropriate behavior, this may lead<br /> to an unbounded addition of metadata to the metalist which might cause an<br /> out of bounds error when running the encode op:<br /> <br /> [ 138.423369][ C1] ==================================================================<br /> [ 138.424317][ C1] BUG: KASAN: slab-out-of-bounds in ife_tlv_meta_encode (net/ife/ife.c:168)<br /> [ 138.424906][ C1] Write of size 4 at addr ffff8880077f4ffe by task ife_out_out_bou/255<br /> [ 138.425778][ C1] CPU: 1 UID: 0 PID: 255 Comm: ife_out_out_bou Not tainted 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(full)<br /> [ 138.425795][ C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> [ 138.425800][ C1] Call Trace:<br /> [ 138.425804][ C1] <br /> [ 138.425808][ C1] dump_stack_lvl (lib/dump_stack.c:122)<br /> [ 138.425828][ C1] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)<br /> [ 138.425839][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 138.425844][ C1] ? __virt_addr_valid (./arch/x86/include/asm/preempt.h:95 (discriminator 1) ./include/linux/rcupdate.h:975 (discriminator 1) ./include/linux/mmzone.h:2207 (discriminator 1) arch/x86/mm/physaddr.c:54 (discriminator 1))<br /> [ 138.425853][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168)<br /> [ 138.425859][ C1] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:597)<br /> [ 138.425868][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168)<br /> [ 138.425878][ C1] kasan_check_range (mm/kasan/generic.c:186 (discriminator 1) mm/kasan/generic.c:200 (discriminator 1))<br /> [ 138.425884][ C1] __asan_memset (mm/kasan/shadow.c:84 (discriminator 2))<br /> [ 138.425889][ C1] ife_tlv_meta_encode (net/ife/ife.c:168)<br /> [ 138.425893][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:171)<br /> [ 138.425898][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 138.425903][ C1] ife_encode_meta_u16 (net/sched/act_ife.c:57)<br /> [ 138.425910][ C1] ? __pfx_do_raw_spin_lock (kernel/locking/spinlock_debug.c:114)<br /> [ 138.425916][ C1] ? __asan_memcpy (mm/kasan/shadow.c:105 (discriminator 3))<br /> [ 138.425921][ C1] ? __pfx_ife_encode_meta_u16 (net/sched/act_ife.c:45)<br /> [ 138.425927][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 138.425931][ C1] tcf_ife_act (net/sched/act_ife.c:847 net/sched/act_ife.c:879)<br /> <br /> To solve this issue, fix the replace behavior by adding the metalist to<br /> the ife rcu data structure.