Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pmbus/adm1266) reject short block-read responses in the GPIO accessors<br /> <br /> adm1266_gpio_get() and adm1266_gpio_get_multiple() both compose the<br /> pin-status word as<br /> <br /> pins_status = read_buf[0] + (read_buf[1]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/statmount: fix slab out-of-bounds write in statmount_mnt_idmap<br /> <br /> statmount_mnt_idmap() writes one mapping with seq_printf() and then<br /> manually advances seq-&gt;count to include the NUL separator.<br /> <br /> If seq_printf() overflows, seq_set_overflow() sets seq-&gt;count to<br /> seq-&gt;size. The manual seq-&gt;count++ changes this to seq-&gt;size + 1.<br /> seq_has_overflowed() then no longer detects the overflow. The corrupted<br /> count returns to statmount_string(), which later executes:<br /> <br /> seq-&gt;buf[seq-&gt;count++] = &amp;#39;\0&amp;#39;;<br /> <br /> This causes a 1-byte NULL out-of-bounds write on the dynamically<br /> allocated seq buffer.<br /> <br /> Fix this by checking for overflow immediately after seq_printf().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: bridge: eb_tables: close module init race<br /> <br /> sashiko reports for unrelated patch:<br /> Does the core ebtables initialization in ebtables.c suffer from a similar race?<br /> Once nf_register_sockopt() completes, the sockopts are exposed globally.<br /> <br /> sockopt has to be registered last, just like in ip/ip6/arptables.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ebtables: move to two-stage removal scheme<br /> <br /> Like previous patches for x_tables, follow same pattern in ebtables.<br /> We can&amp;#39;t reuse xt helpers: ebt_table struct layout is incompatible.<br /> <br /> table-&gt;ops assignment is now done while still holding the ebt mutex<br /> to make sure we never expose partially-filled table struct.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: x_tables: add and use xtables_unregister_table_exit<br /> <br /> Previous change added xtables_unregister_table_pre_exit to detach the<br /> table from the packetpath and to unlink it from the active table list.<br /> In case of rmmod, userspace that is doing set/getsockopt for this table<br /> will not be able to re-instantiate the table:<br /> 1. The larval table has been removed already<br /> 2. existing instantiated table is no longer on the xt pernet table list.<br /> <br /> This adds the second stage helper:<br /> <br /> unlink the table from the dying list, free the hook ops (if any) and do<br /> the audit notification. It replaces xt_unregister_table().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_ffa: Snapshot notifier callbacks under lock<br /> <br /> Both notification handlers currently look up a notifier callback under<br /> notify_lock, drop the lock, and then dereference the returned<br /> notifier entry. A concurrent unregister can delete and free that<br /> entry in the gap, leaving the handler to dereference stale memory.<br /> <br /> Copy the callback pointer and callback data while notify_lock is<br /> still held and invoke the callback only after the lock is dropped.<br /> This keeps the existing callback execution model while removing the<br /> use-after-free window in both the framework and non-framework<br /> notification paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_ffa: Validate framework notification message layout<br /> <br /> Framework notifications carry an indirect message in the shared RX<br /> buffer. Validate the reported offset and size before using them, reject<br /> zero-length payloads, and ensure that any non-header payload starts at<br /> the UUID field rather than in the middle of the message header.<br /> <br /> Use the validated offset and size values for both kmemdup() and the UUID<br /> parsing path so malformed firmware data cannot drive an out-of-bounds<br /> read or an oversized allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: Fix register corruption from uninitialized cregs on error<br /> <br /> compat_riscv_gpr_set() calls cregs_to_regs() unconditionally, even when<br /> user_regset_copyin() fails. Since cregs is an uninitialized stack<br /> variable, a copyin failure causes uninitialized stack data to be written<br /> into the target task&amp;#39;s pt_regs, corrupting its register state and<br /> potentially leaking kernel stack contents.<br /> <br /> compat_restore_sigcontext() has the same issue: it calls cregs_to_regs()<br /> even when __copy_from_user() fails, leading to the same corruption of<br /> the signal-returning task&amp;#39;s register state on error.<br /> <br /> Only call cregs_to_regs() when the user copy succeeds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: fix VM_BUG_ON_FOLIO() issue in netfs_write_begin() call<br /> <br /> The multiple runs of generic/013 test-case is capable<br /> to reproduce a kernel BUG at mm/filemap.c:1504 with<br /> probability of 30%.<br /> <br /> while true; do<br /> sudo ./check generic/013<br /> done<br /> <br /> [ 9849.452376] page: refcount:3 mapcount:0 mapping:00000000e58ff252 index:0x10781 pfn:0x1c322<br /> [ 9849.452412] memcg:ffff8881a1915800<br /> [ 9849.452417] aops:ceph_aops ino:1000058db9e dentry name(?):"f9XXXXXX"<br /> [ 9849.452432] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)<br /> [ 9849.452441] raw: 0017ffffc0000000 0000000000000000 dead000000000122 ffff88816110d248<br /> [ 9849.452445] raw: 0000000000010781 0000000000000000 00000003ffffffff ffff8881a1915800<br /> [ 9849.452447] page dumped because: VM_BUG_ON_FOLIO(!folio_test_locked(folio))<br /> [ 9849.452474] ------------[ cut here ]------------<br /> [ 9849.452476] kernel BUG at mm/filemap.c:1504!<br /> [ 9849.478635] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> [ 9849.481772] CPU: 2 UID: 0 PID: 84223 Comm: fsstress Not tainted 7.0.0-rc1+ #18 PREEMPT(full)<br /> [ 9849.482881] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-9.fc43 06/1<br /> 0/2025<br /> [ 9849.484539] RIP: 0010:folio_unlock+0x85/0xa0<br /> [ 9849.485076] Code: 89 df 31 f6 e8 1c f3 ff ff 48 8b 5d f8 c9 31 c0 31 d2 31 f6 31 ff c3 cc<br /> cc cc cc 48 c7 c6 80 6c d9 a7 48 89 df e8 4b b3 10 00 0b 48 89 df e8 21 e6 2c 00 eb 9d 0f 1f 40 00 66 66 2e 0f 1f 84<br /> [ 9849.493818] RSP: 0018:ffff8881bb8076b0 EFLAGS: 00010246<br /> [ 9849.495740] RAX: 0000000000000000 RBX: ffffea00070c8980 RCX: 0000000000000000<br /> [ 9849.498678] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> [ 9849.500559] RBP: ffff8881bb8076b8 R08: 0000000000000000 R09: 0000000000000000<br /> [ 9849.501097] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000010782000<br /> [ 9849.502108] R13: ffff8881935de738 R14: ffff88816110d010 R15: 0000000000001000<br /> [ 9849.502516] FS: 00007e36cbe94740(0000) GS:ffff88824a899000(0000) knlGS:0000000000000000<br /> [ 9849.502996] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 9849.503810] CR2: 000000c0002b0000 CR3: 000000011bbf6004 CR4: 0000000000772ef0<br /> [ 9849.504459] PKRU: 55555554<br /> [ 9849.504626] Call Trace:<br /> [ 9849.505242] <br /> [ 9849.505379] netfs_write_begin+0x7c8/0x10a0<br /> [ 9849.505877] ? __kasan_check_read+0x11/0x20<br /> [ 9849.506384] ? __pfx_netfs_write_begin+0x10/0x10<br /> [ 9849.507178] ceph_write_begin+0x8c/0x1c0<br /> [ 9849.507934] generic_perform_write+0x391/0x8f0<br /> [ 9849.508503] ? __pfx_generic_perform_write+0x10/0x10<br /> [ 9849.509062] ? file_update_time_flags+0x19a/0x4b0<br /> [ 9849.509581] ? ceph_get_caps+0x63/0xf0<br /> [ 9849.510259] ? ceph_get_caps+0x63/0xf0<br /> [ 9849.510530] ceph_write_iter+0xe79/0x1ae0<br /> [ 9849.511282] ? __pfx_ceph_write_iter+0x10/0x10<br /> [ 9849.511839] ? lock_acquire+0x1ad/0x310<br /> [ 9849.512334] ? ksys_write+0xf9/0x230<br /> [ 9849.512582] ? lock_is_held_type+0xaa/0x140<br /> [ 9849.513128] vfs_write+0x512/0x1110<br /> [ 9849.513634] ? __fget_files+0x33/0x350<br /> [ 9849.513893] ? __pfx_vfs_write+0x10/0x10<br /> [ 9849.514143] ? mutex_lock_nested+0x1b/0x30<br /> [ 9849.514394] ksys_write+0xf9/0x230<br /> [ 9849.514621] ? __pfx_ksys_write+0x10/0x10<br /> [ 9849.514887] ? do_syscall_64+0x25e/0x1520<br /> [ 9849.515122] ? __kasan_check_read+0x11/0x20<br /> [ 9849.515366] ? trace_hardirqs_on_prepare+0x178/0x1c0<br /> [ 9849.515655] __x64_sys_write+0x72/0xd0<br /> [ 9849.515885] ? trace_hardirqs_on+0x24/0x1c0<br /> [ 9849.516130] x64_sys_call+0x22f/0x2390<br /> [ 9849.516341] do_syscall_64+0x12b/0x1520<br /> [ 9849.516545] ? do_syscall_64+0x27c/0x1520<br /> [ 9849.516783] ? do_syscall_64+0x27c/0x1520<br /> [ 9849.517003] ? lock_release+0x318/0x480<br /> [ 9849.517220] ? __x64_sys_io_getevents+0x143/0x2d0<br /> [ 9849.517479] ? percpu_ref_put_many.constprop.0+0x8f/0x210<br /> [ 9849.517779] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 9849.518073] ? do_syscall_64+0x25e/0x1520<br /> [ 9849.518291] ? __kasan_check_read+0x11/0x20<br /> [ 9849.518519] ? trace_hardirqs_on_prepare+0x178/0x1c0<br /> [ 9849.518799] ? do_syscall_64+0x27c/0x1520<br /> [ 9<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/hv-gpci: fix preempt count leak in sysfs show paths<br /> <br /> Four sysfs show() callbacks in hv-gpci take get_cpu_var(hv_gpci_reqb)<br /> (which calls preempt_disable()) but only call the matching put_cpu_var()<br /> on the error path under the &amp;#39;out:&amp;#39; label. Every successful read leaks<br /> one preempt_disable():<br /> <br /> processor_bus_topology_show()<br /> processor_config_show()<br /> affinity_domain_via_virtual_processor_show()<br /> affinity_domain_via_domain_show()<br /> <br /> (affinity_domain_via_partition_show() was already correct.)<br /> <br /> On a CONFIG_PREEMPT=y kernel, repeated reads raise preempt_count and<br /> eventually return to userspace with preemption still disabled. The<br /> next user-mode page fault then hits faulthandler_disabled() == 1,<br /> gets forced to SIGSEGV, and the resulting coredump trips<br /> &amp;#39;BUG: scheduling while atomic&amp;#39; in call_usermodehelper_exec -&gt;<br /> wait_for_completion_state -&gt; schedule:<br /> <br /> BUG: scheduling while atomic: //0x00000004<br /> ...<br /> __schedule_bug+0x6c/0x90<br /> __schedule+0x58c/0x13a0<br /> schedule+0x48/0x1a0<br /> schedule_timeout+0x104/0x170<br /> wait_for_completion_state+0x16c/0x330<br /> call_usermodehelper_exec+0x254/0x2d0<br /> vfs_coredump+0x1050/0x2590<br /> get_signal+0xb9c/0xc80<br /> do_notify_resume+0xf8/0x470<br /> <br /> Add an out_success label that calls put_cpu_var() before returning<br /> the byte count, mirroring affinity_domain_via_partition_show().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: fix use-after-free in nvme_free_host_mem()<br /> <br /> nvme_free_host_mem() frees dev-&gt;hmb_sgt via dma_free_noncontiguous()<br /> but never clears the pointer afterward. This leads to a use-after-free<br /> if nvme_free_host_mem() is called twice in the same error path.<br /> <br /> This can happen during nvme_probe() when nvme_setup_host_mem() succeeds<br /> in allocating the HMB (setting dev-&gt;hmb_sgt) but nvme_set_host_mem()<br /> fails with an I/O error:<br /> <br /> nvme_setup_host_mem()<br /> nvme_alloc_host_mem_single() -&gt; sets dev-&gt;hmb_sgt<br /> nvme_set_host_mem() -&gt; fails with -EIO<br /> nvme_free_host_mem() -&gt; frees hmb_sgt, but does NOT NULL it<br /> return error<br /> <br /> nvme_probe() error path:<br /> nvme_free_host_mem() -&gt; dev-&gt;hmb_sgt is stale, use-after-free<br /> <br /> The second call dereferences the freed sgt, causing a NULL pointer<br /> dereference in iommu_dma_free_noncontiguous() when it accesses<br /> sgt-&gt;sgl-&gt;dma_address (the backing memory has been freed and zeroed).<br /> <br /> This is reproducible on Thunderbolt-attached NVMe devices (e.g., OWC<br /> Envoy Express behind a Dell WD22TB4 dock) where the device intermittently<br /> returns I/O errors during HMB setup due to PCIe link instability.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> RIP: 0010:iommu_dma_free_noncontiguous+0x22/0x80<br /> Call Trace:<br /> <br /> dma_free_noncontiguous+0x3b/0x130<br /> nvme_free_host_mem+0x30/0xf0 [nvme]<br /> nvme_probe.cold+0xcc/0x275 [nvme]<br /> local_pci_probe+0x43/0xa0<br /> pci_device_probe+0xeea/0x290<br /> really_probe+0xf9/0x3b0<br /> __driver_probe_device+0x8b/0x170<br /> driver_probe_device+0x24/0xd0<br /> __driver_attach_async_helper+0x6b/0x110<br /> async_run_entry_fn+0x37/0x170<br /> process_one_work+0x1ac/0x3d0<br /> worker_thread+0x1b8/0x360<br /> kthread+0xf7/0x130<br /> ret_from_fork+0x2d8/0x3a0<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Fix this by setting dev-&gt;hmb_sgt to NULL after freeing it, so the<br /> second call takes the multi-descriptor path which safely handles the<br /> already-cleaned-up state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: fix bio leak on mapping failure<br /> <br /> The local bio is always NULL, so we&amp;#39;d leak the bio if the integrity<br /> mapping failed. Just get it directly from the request.