Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: smbd: fix dma_unmap_sg() nents<br /> <br /> The dma_unmap_sg() functions should be called with the same nents as the<br /> dma_map_sg(), not the value the map function returned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uacce: fix isolate sysfs check condition<br /> <br /> uacce supports the device isolation feature. If the driver<br /> implements the isolate_err_threshold_read and<br /> isolate_err_threshold_write callback functions, uacce will create<br /> sysfs files now. Users can read and configure the isolation policy<br /> through sysfs. Currently, sysfs files are created as long as either<br /> isolate_err_threshold_read or isolate_err_threshold_write callback<br /> functions are present.<br /> <br /> However, accessing a non-existent callback function may cause the<br /> system to crash. Therefore, intercept the creation of sysfs if<br /> neither read nor write exists; create sysfs if either is supported,<br /> but intercept unsupported operations at the call site.

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 /> 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 /> 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 /> 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 /> bonding: limit BOND_MODE_8023AD to Ethernet devices<br /> <br /> BOND_MODE_8023AD makes sense for ARPHRD_ETHER only.<br /> <br /> syzbot reported:<br /> <br /> BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline]<br /> BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118<br /> Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497<br /> <br /> CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full)<br /> Tainted: [L]=SOFTLOCKUP<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xca/0x240 mm/kasan/report.c:482<br /> kasan_report+0x118/0x150 mm/kasan/report.c:595<br /> check_region_inline mm/kasan/generic.c:-1 [inline]<br /> kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200<br /> __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105<br /> __hw_addr_create net/core/dev_addr_lists.c:63 [inline]<br /> __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118<br /> __dev_mc_add net/core/dev_addr_lists.c:868 [inline]<br /> dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886<br /> bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180<br /> do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963<br /> do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165<br /> rtnl_changelink net/core/rtnetlink.c:3776 [inline]<br /> __rtnl_newlink net/core/rtnetlink.c:3935 [inline]<br /> rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072<br /> rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958<br /> netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]<br /> netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344<br /> netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg+0x21c/0x270 net/socket.c:742<br /> ____sys_sendmsg+0x505/0x820 net/socket.c:2592<br /> ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646<br /> __sys_sendmsg+0x164/0x220 net/socket.c:2678<br /> do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]<br /> __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307<br /> do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332<br /> entry_SYSENTER_compat_after_hwframe+0x84/0x8e<br /> <br /> <br /> The buggy address belongs to the variable:<br /> lacpdu_mcast_addr+0x0/0x40

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 /> 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 /> can: gs_usb: gs_usb_receive_bulk_callback(): unanchor URL on usb_submit_urb() error<br /> <br /> In commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix<br /> URB memory leak"), the URB was re-anchored before usb_submit_urb() in<br /> gs_usb_receive_bulk_callback() to prevent a leak of this URB during<br /> cleanup.<br /> <br /> However, this patch did not take into account that usb_submit_urb() could<br /> fail. The URB remains anchored and<br /> usb_kill_anchored_urbs(&amp;parent-&gt;rx_submitted) in gs_can_close() loops<br /> infinitely since the anchor list never becomes empty.<br /> <br /> To fix the bug, unanchor the URB when an usb_submit_urb() error occurs,<br /> also print an info message.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fou: Don&amp;#39;t allow 0 for FOU_ATTR_IPPROTO.<br /> <br /> fou_udp_recv() has the same problem mentioned in the previous<br /> patch.<br /> <br /> If FOU_ATTR_IPPROTO is set to 0, skb is not freed by<br /> fou_udp_recv() nor "resubmit"-ted in ip_protocol_deliver_rcu().<br /> <br /> Let&amp;#39;s forbid 0 for FOU_ATTR_IPPROTO.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list<br /> <br /> When the parameter pmac_id_valid argument of be_cmd_get_mac_from_list() is<br /> set to false, the driver may request the PMAC_ID from the firmware of the<br /> network card, and this function will store that PMAC_ID at the provided<br /> address pmac_id. This is the contract of this function.<br /> <br /> However, there is a location within the driver where both<br /> pmac_id_valid == false and pmac_id == NULL are being passed. This could<br /> result in dereferencing a NULL pointer.<br /> <br /> To resolve this issue, it is necessary to pass the address of a stub<br /> variable to the function.