Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> migrate: correct lock ordering for hugetlb file folios<br /> <br /> Syzbot has found a deadlock (analyzed by Lance Yang):<br /> <br /> 1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock).<br /> 2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire<br /> folio_lock.<br /> <br /> migrate_pages()<br /> -&gt; migrate_hugetlbs()<br /> -&gt; unmap_and_move_huge_page() remove_migration_ptes()<br /> -&gt; __rmap_walk_file()<br /> -&gt; i_mmap_lock_read() hugetlbfs_punch_hole() hugetlbfs_zero_partial_page()<br /> -&gt; filemap_lock_hugetlb_folio()<br /> -&gt; filemap_lock_folio()<br /> -&gt; __filemap_get_folio

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uacce: fix cdev handling in the cleanup path<br /> <br /> When cdev_device_add fails, it internally releases the cdev memory,<br /> and if cdev_device_del is then executed, it will cause a hang error.<br /> To fix it, we check the return value of cdev_device_add() and clear<br /> uacce-&gt;cdev to avoid calling cdev_device_del in the uacce_remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> leds: led-class: Only Add LED to leds_list when it is fully ready<br /> <br /> Before this change the LED was added to leds_list before led_init_core()<br /> gets called adding it the list before led_classdev.set_brightness_work gets<br /> initialized.<br /> <br /> This leaves a window where led_trigger_register() of a LED&amp;#39;s default<br /> trigger will call led_trigger_set() which calls led_set_brightness()<br /> which in turn will end up queueing the *uninitialized*<br /> led_classdev.set_brightness_work.<br /> <br /> This race gets hit by the lenovo-thinkpad-t14s EC driver which registers<br /> 2 LEDs with a default trigger provided by snd_ctl_led.ko in quick<br /> succession. The first led_classdev_register() causes an async modprobe of<br /> snd_ctl_led to run and that async modprobe manages to exactly hit<br /> the window where the second LED is on the leds_list without led_init_core()<br /> being called for it, resulting in:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390<br /> Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025<br /> ...<br /> Call trace:<br /> __flush_work+0x344/0x390 (P)<br /> flush_work+0x2c/0x50<br /> led_trigger_set+0x1c8/0x340<br /> led_trigger_register+0x17c/0x1c0<br /> led_trigger_register_simple+0x84/0xe8<br /> snd_ctl_led_init+0x40/0xf88 [snd_ctl_led]<br /> do_one_initcall+0x5c/0x318<br /> do_init_module+0x9c/0x2b8<br /> load_module+0x7e0/0x998<br /> <br /> Close the race window by moving the adding of the LED to leds_list to<br /> after the led_init_core() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: fix hugetlb_pmd_shared()<br /> <br /> Patch series "mm/hugetlb: fixes for PMD table sharing (incl. using<br /> mmu_gather)", v3.<br /> <br /> One functional fix, one performance regression fix, and two related<br /> comment fixes.<br /> <br /> I cleaned up my prototype I recently shared [1] for the performance fix,<br /> deferring most of the cleanups I had in the prototype to a later point. <br /> While doing that I identified the other things.<br /> <br /> The goal of this patch set is to be backported to stable trees "fairly"<br /> easily. At least patch #1 and #4.<br /> <br /> Patch #1 fixes hugetlb_pmd_shared() not detecting any sharing<br /> Patch #2 + #3 are simple comment fixes that patch #4 interacts with.<br /> Patch #4 is a fix for the reported performance regression due to excessive<br /> IPI broadcasts during fork()+exit().<br /> <br /> The last patch is all about TLB flushes, IPIs and mmu_gather.<br /> Read: complicated<br /> <br /> There are plenty of cleanups in the future to be had + one reasonable<br /> optimization on x86. But that&amp;#39;s all out of scope for this series.<br /> <br /> Runtime tested, with a focus on fixing the performance regression using<br /> the original reproducer [2] on x86.<br /> <br /> <br /> This patch (of 4):<br /> <br /> We switched from (wrongly) using the page count to an independent shared<br /> count. Now, shared page tables have a refcount of 1 (excluding<br /> speculative references) and instead use ptdesc-&gt;pt_share_count to identify<br /> sharing.<br /> <br /> We didn&amp;#39;t convert hugetlb_pmd_shared(), so right now, we would never<br /> detect a shared PMD table as such, because sharing/unsharing no longer<br /> touches the refcount of a PMD table.<br /> <br /> Page migration, like mbind() or migrate_pages() would allow for migrating<br /> folios mapped into such shared PMD tables, even though the folios are not<br /> exclusive. In smaps we would account them as "private" although they are<br /> "shared", and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the<br /> pagemap interface.<br /> <br /> Fix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gue: Fix skb memleak with inner IP protocol 0.<br /> <br /> syzbot reported skb memleak below. [0]<br /> <br /> The repro generated a GUE packet with its inner protocol 0.<br /> <br /> gue_udp_recv() returns -guehdr-&gt;proto_ctype for "resubmit"<br /> in ip_protocol_deliver_rcu(), but this only works with<br /> non-zero protocol number.<br /> <br /> Let&amp;#39;s drop such packets.<br /> <br /> Note that 0 is a valid number (IPv6 Hop-by-Hop Option).<br /> <br /> I think it is not practical to encap HOPOPT in GUE, so once<br /> someone starts to complain, we could pass down a resubmit<br /> flag pointer to distinguish two zeros from the upper layer:<br /> <br /> * no error<br /> * resubmit HOPOPT<br /> <br /> [0]<br /> BUG: memory leak<br /> unreferenced object 0xffff888109695a00 (size 240):<br /> comm "syz.0.17", pid 6088, jiffies 4294943096<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@..............<br /> backtrace (crc a84b336f):<br /> kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]<br /> slab_post_alloc_hook mm/slub.c:4958 [inline]<br /> slab_alloc_node mm/slub.c:5263 [inline]<br /> kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270<br /> __build_skb+0x23/0x60 net/core/skbuff.c:474<br /> build_skb+0x20/0x190 net/core/skbuff.c:490<br /> __tun_build_skb drivers/net/tun.c:1541 [inline]<br /> tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636<br /> tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770<br /> tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999<br /> new_sync_write fs/read_write.c:593 [inline]<br /> vfs_write+0x45d/0x710 fs/read_write.c:686<br /> ksys_write+0xa7/0x170 fs/read_write.c:738<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netrom: fix double-free in nr_route_frame()<br /> <br /> In nr_route_frame(), old_skb is immediately freed without checking if<br /> nr_neigh-&gt;ax25 pointer is NULL. Therefore, if nr_neigh-&gt;ax25 is NULL,<br /> the caller function will free old_skb again, causing a double-free bug.<br /> <br /> Therefore, to prevent this, we need to modify it to check whether<br /> nr_neigh-&gt;ax25 is NULL before freeing old_skb.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> intel_th: fix device leak on output open()<br /> <br /> Make sure to drop the reference taken when looking up the th device<br /> during output device open() on errors and on close().<br /> <br /> Note that a recent commit fixed the leak in a couple of open() error<br /> paths but not all of them, and the reference is still leaking on<br /> successful open().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slimbus: core: fix device reference leak on report present<br /> <br /> Slimbus devices can be allocated dynamically upon reception of<br /> report-present messages.<br /> <br /> Make sure to drop the reference taken when looking up already registered<br /> devices.<br /> <br /> Note that this requires taking an extra reference in case the device has<br /> not yet been registered and has to be allocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free()<br /> <br /> When snd_usb_create_mixer() fails, snd_usb_mixer_free() frees<br /> mixer-&gt;id_elems but the controls already added to the card still<br /> reference the freed memory. Later when snd_card_register() runs,<br /> the OSS mixer layer calls their callbacks and hits a use-after-free read.<br /> <br /> Call trace:<br /> get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411<br /> get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241<br /> mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381<br /> snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887<br /> ...<br /> snd_card_register+0x4ed/0x6d0 sound/core/init.c:923<br /> usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025<br /> <br /> Fix by calling snd_ctl_remove() for all mixer controls before freeing<br /> id_elems. We save the next pointer first because snd_ctl_remove()<br /> frees the current element.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix crash on synthetic stacktrace field usage<br /> <br /> When creating a synthetic event based on an existing synthetic event that<br /> had a stacktrace field and the new synthetic event used that field a<br /> kernel crash occurred:<br /> <br /> ~# cd /sys/kernel/tracing<br /> ~# echo &amp;#39;s:stack unsigned long stack[];&amp;#39; &gt; dynamic_events<br /> ~# echo &amp;#39;hist:keys=prev_pid:s0=common_stacktrace if prev_state &amp; 3&amp;#39; &gt;&gt; events/sched/sched_switch/trigger<br /> ~# echo &amp;#39;hist:keys=next_pid:s1=$s0:onmatch(sched.sched_switch).trace(stack,$s1)&amp;#39; &gt;&gt; events/sched/sched_switch/trigger<br /> <br /> The above creates a synthetic event that takes a stacktrace when a task<br /> schedules out in a non-running state and passes that stacktrace to the<br /> sched_switch event when that task schedules back in. It triggers the<br /> "stack" synthetic event that has a stacktrace as its field (called "stack").<br /> <br /> ~# echo &amp;#39;s:syscall_stack s64 id; unsigned long stack[];&amp;#39; &gt;&gt; dynamic_events<br /> ~# echo &amp;#39;hist:keys=common_pid:s2=stack&amp;#39; &gt;&gt; events/synthetic/stack/trigger<br /> ~# echo &amp;#39;hist:keys=common_pid:s3=$s2,i0=id:onmatch(synthetic.stack).trace(syscall_stack,$i0,$s3)&amp;#39; &gt;&gt; events/raw_syscalls/sys_exit/trigger<br /> <br /> The above makes another synthetic event called "syscall_stack" that<br /> attaches the first synthetic event (stack) to the sys_exit trace event and<br /> records the stacktrace from the stack event with the id of the system call<br /> that is exiting.<br /> <br /> When enabling this event (or using it in a historgram):<br /> <br /> ~# echo 1 &gt; events/synthetic/syscall_stack/enable<br /> <br /> Produces a kernel crash!<br /> <br /> BUG: unable to handle page fault for address: 0000000000400010<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP PTI<br /> CPU: 6 UID: 0 PID: 1257 Comm: bash Not tainted 6.16.3+deb14-amd64 #1 PREEMPT(lazy) Debian 6.16.3-1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014<br /> RIP: 0010:trace_event_raw_event_synth+0x90/0x380<br /> Code: c5 00 00 00 00 85 d2 0f 84 e1 00 00 00 31 db eb 34 0f 1f 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 8b 04 24 48 83 c3 01 8d 0c c5 08 00 00 00 01 cd 41 3b 5d 40 0f<br /> RSP: 0018:ffffd2670388f958 EFLAGS: 00010202<br /> RAX: ffff8ba1065cc100 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: fffff266ffda7b90 RDI: ffffd2670388f9b0<br /> RBP: 0000000000000010 R08: ffff8ba104e76000 R09: ffffd2670388fa50<br /> R10: ffff8ba102dd42e0 R11: ffffffff9a908970 R12: 0000000000400010<br /> R13: ffff8ba10a246400 R14: ffff8ba10a710220 R15: fffff266ffda7b90<br /> FS: 00007fa3bc63f740(0000) GS:ffff8ba2e0f48000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000400010 CR3: 0000000107f9e003 CR4: 0000000000172ef0<br /> Call Trace:<br /> <br /> ? __tracing_map_insert+0x208/0x3a0<br /> action_trace+0x67/0x70<br /> event_hist_trigger+0x633/0x6d0<br /> event_triggers_call+0x82/0x130<br /> trace_event_buffer_commit+0x19d/0x250<br /> trace_event_raw_event_sys_exit+0x62/0xb0<br /> syscall_exit_work+0x9d/0x140<br /> do_syscall_64+0x20a/0x2f0<br /> ? trace_event_raw_event_sched_switch+0x12b/0x170<br /> ? save_fpregs_to_fpstate+0x3e/0x90<br /> ? _raw_spin_unlock+0xe/0x30<br /> ? finish_task_switch.isra.0+0x97/0x2c0<br /> ? __rseq_handle_notify_resume+0xad/0x4c0<br /> ? __schedule+0x4b8/0xd00<br /> ? restore_fpregs_from_fpstate+0x3c/0x90<br /> ? switch_fpu_return+0x5b/0xe0<br /> ? do_syscall_64+0x1ef/0x2f0<br /> ? do_fault+0x2e9/0x540<br /> ? __handle_mm_fault+0x7d1/0xf70<br /> ? count_memcg_events+0x167/0x1d0<br /> ? handle_mm_fault+0x1d7/0x2e0<br /> ? do_user_addr_fault+0x2c3/0x7f0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The reason is that the stacktrace field is not labeled as such, and is<br /> treated as a normal field and not as a dynamic event that it is.<br /> <br /> In trace_event_raw_event_synth() the event is field is still treated as a<br /> dynamic array, but the retrieval of the data is considered a normal field,<br /> and the reference is just the meta data:<br /> <br /> // Meta data is retrieved instead of a dynamic array<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: xen: scsiback: Fix potential memory leak in scsiback_remove()<br /> <br /> Memory allocated for struct vscsiblk_info in scsiback_probe() is not<br /> freed in scsiback_remove() leading to potential memory leaks on remove,<br /> as well as in the scsiback_probe() error paths. Fix that by freeing it<br /> in scsiback_remove().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: cap TX credit to local buffer size<br /> <br /> The virtio transports derives its TX credit directly from peer_buf_alloc,<br /> which is set from the remote endpoint&amp;#39;s SO_VM_SOCKETS_BUFFER_SIZE value.<br /> <br /> On the host side this means that the amount of data we are willing to<br /> queue for a connection is scaled by a guest-chosen buffer size, rather<br /> than the host&amp;#39;s own vsock configuration. A malicious guest can advertise<br /> a large buffer and read slowly, causing the host to allocate a<br /> correspondingly large amount of sk_buff memory.<br /> The same thing would happen in the guest with a malicious host, since<br /> virtio transports share the same code base.<br /> <br /> Introduce a small helper, virtio_transport_tx_buf_size(), that<br /> returns min(peer_buf_alloc, buf_alloc), and use it wherever we consume<br /> peer_buf_alloc.<br /> <br /> This ensures the effective TX window is bounded by both the peer&amp;#39;s<br /> advertised buffer and our own buf_alloc (already clamped to<br /> buffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer<br /> cannot force the other to queue more data than allowed by its own<br /> vsock settings.<br /> <br /> On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with<br /> 32 guest vsock connections advertising 2 GiB each and reading slowly<br /> drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only<br /> recovered after killing the QEMU process. That said, if QEMU memory is<br /> limited with cgroups, the maximum memory used will be limited.<br /> <br /> With this patch applied:<br /> <br /> Before:<br /> MemFree: ~61.6 GiB<br /> Slab: ~142 MiB<br /> SUnreclaim: ~117 MiB<br /> <br /> After 32 high-credit connections:<br /> MemFree: ~61.5 GiB<br /> Slab: ~178 MiB<br /> SUnreclaim: ~152 MiB<br /> <br /> Only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest<br /> remains responsive.<br /> <br /> Compatibility with non-virtio transports:<br /> <br /> - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per<br /> socket based on the local vsk-&gt;buffer_* values; the remote side<br /> cannot enlarge those queues beyond what the local endpoint<br /> configured.<br /> <br /> - Hyper-V&amp;#39;s vsock transport uses fixed-size VMBus ring buffers and<br /> an MTU bound; there is no peer-controlled credit field comparable<br /> to peer_buf_alloc, and the remote endpoint cannot drive in-flight<br /> kernel memory above those ring sizes.<br /> <br /> - The loopback path reuses virtio_transport_common.c, so it<br /> naturally follows the same semantics as the virtio transport.<br /> <br /> This change is limited to virtio_transport_common.c and thus affects<br /> virtio-vsock, vhost-vsock, and loopback, bringing them in line with the<br /> "remote window intersected with local policy" behaviour that VMCI and<br /> Hyper-V already effectively have.<br /> <br /> [Stefano: small adjustments after changing the previous patch]<br /> [Stefano: tweak the commit message]