Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hns: Fix double destruction of rsv_qp<br /> <br /> rsv_qp may be double destroyed in error flow, first in free_mr_init(),<br /> and then in hns_roce_exit(). Fix it by moving the free_mr_init() call<br /> into hns_roce_v2_init().<br /> <br /> list_del corruption, ffff589732eb9b50-&gt;next is LIST_POISON1 (dead000000000100)<br /> WARNING: CPU: 8 PID: 1047115 at lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240<br /> ...<br /> Call trace:<br /> __list_del_entry_valid+0x148/0x240<br /> hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2]<br /> hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2]<br /> hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2]<br /> free_mr_exit+0x6c/0x120 [hns_roce_hw_v2]<br /> hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2]<br /> hns_roce_exit+0x118/0x350 [hns_roce_hw_v2]<br /> __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2]<br /> hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2]<br /> hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2]<br /> hclge_notify_roce_client+0x6c/0x160 [hclge]<br /> hclge_reset_rebuild+0x150/0x5c0 [hclge]<br /> hclge_reset+0x10c/0x140 [hclge]<br /> hclge_reset_subtask+0x80/0x104 [hclge]<br /> hclge_reset_service_task+0x168/0x3ac [hclge]<br /> hclge_service_task+0x50/0x100 [hclge]<br /> process_one_work+0x250/0x9a0<br /> worker_thread+0x324/0x990<br /> kthread+0x190/0x210<br /> ret_from_fork+0x10/0x18

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix inode use after free in ext4_end_io_rsv_work()<br /> <br /> In ext4_io_end_defer_completion(), check if io_end-&gt;list_vec is empty to<br /> avoid adding an io_end that requires no conversion to the<br /> i_rsv_conversion_list, which in turn prevents starting an unnecessary<br /> worker. An ext4_emergency_state() check is also added to avoid attempting<br /> to abort the journal in an emergency state.<br /> <br /> Additionally, ext4_put_io_end_defer() is refactored to call<br /> ext4_io_end_defer_completion() directly instead of being open-coded.<br /> This also prevents starting an unnecessary worker when EXT4_IO_END_FAILED<br /> is set but data_err=abort is not enabled.<br /> <br /> This ensures that the check in ext4_put_io_end_defer() is consistent with<br /> the check in ext4_end_bio(). Otherwise, we might add an io_end to the<br /> i_rsv_conversion_list and then call ext4_finish_bio(), after which the<br /> inode could be freed before ext4_end_io_rsv_work() is called, triggering<br /> a use-after-free issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: reject malicious packets in ipv6_gso_segment()<br /> <br /> syzbot was able to craft a packet with very long IPv6 extension headers<br /> leading to an overflow of skb-&gt;transport_header.<br /> <br /> This 16bit field has a limited range.<br /> <br /> Add skb_reset_transport_header_careful() helper and use it<br /> from ipv6_gso_segment()<br /> <br /> WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline]<br /> WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025<br /> RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline]<br /> RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151<br /> Call Trace:<br /> <br /> skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53<br /> nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110<br /> skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53<br /> __skb_gso_segment+0x342/0x510 net/core/gso.c:124<br /> skb_gso_segment include/net/gso.h:83 [inline]<br /> validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950<br /> validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000<br /> sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329<br /> __dev_xmit_skb net/core/dev.c:4102 [inline]<br /> __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid UAF in f2fs_sync_inode_meta()<br /> <br /> syzbot reported an UAF issue as below: [1] [2]<br /> <br /> [1] https://syzkaller.appspot.com/text?tag=CrashReport&amp;x=16594c60580000<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62<br /> Read of size 8 at addr ffff888100567dc8 by task kworker/u4:0/8<br /> <br /> CPU: 1 PID: 8 Comm: kworker/u4:0 Tainted: G W 6.1.129-syzkaller-00017-g642656a36791 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025<br /> Workqueue: writeback wb_workfn (flush-7:0)<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x151/0x1b7 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:316 [inline]<br /> print_report+0x158/0x4e0 mm/kasan/report.c:427<br /> kasan_report+0x13c/0x170 mm/kasan/report.c:531<br /> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:351<br /> __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62<br /> __list_del_entry include/linux/list.h:134 [inline]<br /> list_del_init include/linux/list.h:206 [inline]<br /> f2fs_inode_synced+0x100/0x2e0 fs/f2fs/super.c:1553<br /> f2fs_update_inode+0x72/0x1c40 fs/f2fs/inode.c:588<br /> f2fs_update_inode_page+0x135/0x170 fs/f2fs/inode.c:706<br /> f2fs_write_inode+0x416/0x790 fs/f2fs/inode.c:734<br /> write_inode fs/fs-writeback.c:1460 [inline]<br /> __writeback_single_inode+0x4cf/0xb80 fs/fs-writeback.c:1677<br /> writeback_sb_inodes+0xb32/0x1910 fs/fs-writeback.c:1903<br /> __writeback_inodes_wb+0x118/0x3f0 fs/fs-writeback.c:1974<br /> wb_writeback+0x3da/0xa00 fs/fs-writeback.c:2081<br /> wb_check_background_flush fs/fs-writeback.c:2151 [inline]<br /> wb_do_writeback fs/fs-writeback.c:2239 [inline]<br /> wb_workfn+0xbba/0x1030 fs/fs-writeback.c:2266<br /> process_one_work+0x73d/0xcb0 kernel/workqueue.c:2299<br /> worker_thread+0xa60/0x1260 kernel/workqueue.c:2446<br /> kthread+0x26d/0x300 kernel/kthread.c:386<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295<br /> <br /> <br /> Allocated by task 298:<br /> kasan_save_stack mm/kasan/common.c:45 [inline]<br /> kasan_set_track+0x4b/0x70 mm/kasan/common.c:52<br /> kasan_save_alloc_info+0x1f/0x30 mm/kasan/generic.c:505<br /> __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:333<br /> kasan_slab_alloc include/linux/kasan.h:202 [inline]<br /> slab_post_alloc_hook+0x53/0x2c0 mm/slab.h:768<br /> slab_alloc_node mm/slub.c:3421 [inline]<br /> slab_alloc mm/slub.c:3431 [inline]<br /> __kmem_cache_alloc_lru mm/slub.c:3438 [inline]<br /> kmem_cache_alloc_lru+0x102/0x270 mm/slub.c:3454<br /> alloc_inode_sb include/linux/fs.h:3255 [inline]<br /> f2fs_alloc_inode+0x2d/0x350 fs/f2fs/super.c:1437<br /> alloc_inode fs/inode.c:261 [inline]<br /> iget_locked+0x18c/0x7e0 fs/inode.c:1373<br /> f2fs_iget+0x55/0x4ca0 fs/f2fs/inode.c:486<br /> f2fs_lookup+0x3c1/0xb50 fs/f2fs/namei.c:484<br /> __lookup_slow+0x2b9/0x3e0 fs/namei.c:1689<br /> lookup_slow+0x5a/0x80 fs/namei.c:1706<br /> walk_component+0x2e7/0x410 fs/namei.c:1997<br /> lookup_last fs/namei.c:2454 [inline]<br /> path_lookupat+0x16d/0x450 fs/namei.c:2478<br /> filename_lookup+0x251/0x600 fs/namei.c:2507<br /> vfs_statx+0x107/0x4b0 fs/stat.c:229<br /> vfs_fstatat fs/stat.c:267 [inline]<br /> vfs_lstat include/linux/fs.h:3434 [inline]<br /> __do_sys_newlstat fs/stat.c:423 [inline]<br /> __se_sys_newlstat+0xda/0x7c0 fs/stat.c:417<br /> __x64_sys_newlstat+0x5b/0x70 fs/stat.c:417<br /> x64_sys_call+0x52/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:7<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x3b/0x80 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x68/0xd2<br /> <br /> Freed by task 0:<br /> kasan_save_stack mm/kasan/common.c:45 [inline]<br /> kasan_set_track+0x4b/0x70 mm/kasan/common.c:52<br /> kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:516<br /> ____kasan_slab_free+0x131/0x180 mm/kasan/common.c:241<br /> __kasan_slab_free+0x11/0x20 mm/kasan/common.c:249<br /> kasan_slab_free include/linux/kasan.h:178 [inline]<br /> slab_free_hook mm/slub.c:1745 [inline]<br /> slab_free_freelist_hook mm/slub.c:1771 [inline]<br /> slab_free mm/slub.c:3686 [inline]<br /> kmem_cache_free+0x<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid panic in f2fs_evict_inode<br /> <br /> As syzbot [1] reported as below:<br /> <br /> R10: 0000000000000100 R11: 0000000000000206 R12: 00007ffe17473450<br /> R13: 00007f28b1c10854 R14: 000000000000dae5 R15: 00007ffe17474520<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> ==================================================================<br /> BUG: KASAN: use-after-free in __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62<br /> Read of size 8 at addr ffff88812d962278 by task syz-executor/564<br /> <br /> CPU: 1 PID: 564 Comm: syz-executor Tainted: G W 6.1.129-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025<br /> Call Trace:<br /> <br /> __dump_stack+0x21/0x24 lib/dump_stack.c:88<br /> dump_stack_lvl+0xee/0x158 lib/dump_stack.c:106<br /> print_address_description+0x71/0x210 mm/kasan/report.c:316<br /> print_report+0x4a/0x60 mm/kasan/report.c:427<br /> kasan_report+0x122/0x150 mm/kasan/report.c:531<br /> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:351<br /> __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62<br /> __list_del_entry include/linux/list.h:134 [inline]<br /> list_del_init include/linux/list.h:206 [inline]<br /> f2fs_inode_synced+0xf7/0x2e0 fs/f2fs/super.c:1531<br /> f2fs_update_inode+0x74/0x1c40 fs/f2fs/inode.c:585<br /> f2fs_update_inode_page+0x137/0x170 fs/f2fs/inode.c:703<br /> f2fs_write_inode+0x4ec/0x770 fs/f2fs/inode.c:731<br /> write_inode fs/fs-writeback.c:1460 [inline]<br /> __writeback_single_inode+0x4a0/0xab0 fs/fs-writeback.c:1677<br /> writeback_single_inode+0x221/0x8b0 fs/fs-writeback.c:1733<br /> sync_inode_metadata+0xb6/0x110 fs/fs-writeback.c:2789<br /> f2fs_sync_inode_meta+0x16d/0x2a0 fs/f2fs/checkpoint.c:1159<br /> block_operations fs/f2fs/checkpoint.c:1269 [inline]<br /> f2fs_write_checkpoint+0xca3/0x2100 fs/f2fs/checkpoint.c:1658<br /> kill_f2fs_super+0x231/0x390 fs/f2fs/super.c:4668<br /> deactivate_locked_super+0x98/0x100 fs/super.c:332<br /> deactivate_super+0xaf/0xe0 fs/super.c:363<br /> cleanup_mnt+0x45f/0x4e0 fs/namespace.c:1186<br /> __cleanup_mnt+0x19/0x20 fs/namespace.c:1193<br /> task_work_run+0x1c6/0x230 kernel/task_work.c:203<br /> exit_task_work include/linux/task_work.h:39 [inline]<br /> do_exit+0x9fb/0x2410 kernel/exit.c:871<br /> do_group_exit+0x210/0x2d0 kernel/exit.c:1021<br /> __do_sys_exit_group kernel/exit.c:1032 [inline]<br /> __se_sys_exit_group kernel/exit.c:1030 [inline]<br /> __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1030<br /> x64_sys_call+0x7b4/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:232<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x4c/0xa0 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x68/0xd2<br /> RIP: 0033:0x7f28b1b8e169<br /> Code: Unable to access opcode bytes at 0x7f28b1b8e13f.<br /> RSP: 002b:00007ffe174710a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7<br /> RAX: ffffffffffffffda RBX: 00007f28b1c10879 RCX: 00007f28b1b8e169<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001<br /> RBP: 0000000000000002 R08: 00007ffe1746ee47 R09: 00007ffe17472360<br /> R10: 0000000000000009 R11: 0000000000000246 R12: 00007ffe17472360<br /> R13: 00007f28b1c10854 R14: 000000000000dae5 R15: 00007ffe17474520<br /> <br /> <br /> Allocated by task 569:<br /> kasan_save_stack mm/kasan/common.c:45 [inline]<br /> kasan_set_track+0x4b/0x70 mm/kasan/common.c:52<br /> kasan_save_alloc_info+0x25/0x30 mm/kasan/generic.c:505<br /> __kasan_slab_alloc+0x72/0x80 mm/kasan/common.c:328<br /> kasan_slab_alloc include/linux/kasan.h:201 [inline]<br /> slab_post_alloc_hook+0x4f/0x2c0 mm/slab.h:737<br /> slab_alloc_node mm/slub.c:3398 [inline]<br /> slab_alloc mm/slub.c:3406 [inline]<br /> __kmem_cache_alloc_lru mm/slub.c:3413 [inline]<br /> kmem_cache_alloc_lru+0x104/0x220 mm/slub.c:3429<br /> alloc_inode_sb include/linux/fs.h:3245 [inline]<br /> f2fs_alloc_inode+0x2d/0x340 fs/f2fs/super.c:1419<br /> alloc_inode fs/inode.c:261 [inline]<br /> iget_locked+0x186/0x880 fs/inode.c:1373<br /> f2fs_iget+0x55/0x4c60 fs/f2fs/inode.c:483<br /> f2fs_lookup+0x366/0xab0 fs/f2fs/namei.c:487<br /> __lookup_slow+0x2a3/0x3d0 fs/namei.c:1690<br /> lookup_slow+0x57/0x70 fs/namei.c:1707<br /> walk_component+0x2e6/0x410 fs/namei<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/eeh: Make EEH driver device hotplug safe<br /> <br /> Multiple race conditions existed between the PCIe hotplug driver and the<br /> EEH driver, leading to a variety of kernel oopses of the same general<br /> nature:<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> A second class of oops is also seen when the underlying bus disappears<br /> during device recovery.<br /> <br /> Refactor the EEH module to be PCI rescan and remove safe. Also clean<br /> up a few minor formatting / readability issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pptp: ensure minimal skb length in pptp_xmit()<br /> <br /> Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb data<br /> on ppp_sync_txmung") fixed ppp_sync_txmunge()<br /> <br /> We need a similar fix in pptp_xmit(), otherwise we might<br /> read uninit data as reported by syzbot.<br /> <br /> BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193<br /> pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193<br /> ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline]<br /> ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314<br /> pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379<br /> sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148<br /> __release_sock+0x1d3/0x330 net/core/sock.c:3213<br /> release_sock+0x6b/0x270 net/core/sock.c:3767<br /> pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904<br /> sock_sendmsg_nosec net/socket.c:712 [inline]<br /> __sock_sendmsg+0x330/0x3d0 net/socket.c:727<br /> ____sys_sendmsg+0x893/0xd80 net/socket.c:2566<br /> ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620<br /> __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: cs42l43: Property entry should be a null-terminated array<br /> <br /> The software node does not specify a count of property entries, so the<br /> array must be null-terminated.<br /> <br /> When unterminated, this can lead to a fault in the downstream cs35l56<br /> amplifier driver, because the node parse walks off the end of the<br /> array into unknown memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/core: Exit early on perf_mmap() fail<br /> <br /> When perf_mmap() fails to allocate a buffer, it still invokes the<br /> event_mapped() callback of the related event. On X86 this might increase<br /> the perf_rdpmc_allowed reference counter. But nothing undoes this as<br /> perf_mmap_close() is never called in this case, which causes another<br /> reference count leak.<br /> <br /> Return early on failure to prevent that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> benet: fix BUG when creating VFs<br /> <br /> benet crashes as soon as SRIOV VFs are created:<br /> <br /> kernel BUG at mm/vmalloc.c:3457!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary)<br /> [...]<br /> RIP: 0010:vunmap+0x5f/0x70<br /> [...]<br /> Call Trace:<br /> <br /> __iommu_dma_free+0xe8/0x1c0<br /> be_cmd_set_mac_list+0x3fe/0x640 [be2net]<br /> be_cmd_set_mac+0xaf/0x110 [be2net]<br /> be_vf_eth_addr_config+0x19f/0x330 [be2net]<br /> be_vf_setup+0x4f7/0x990 [be2net]<br /> be_pci_sriov_configure+0x3a1/0x470 [be2net]<br /> sriov_numvfs_store+0x20b/0x380<br /> kernfs_fop_write_iter+0x354/0x530<br /> vfs_write+0x9b9/0xf60<br /> ksys_write+0xf3/0x1d0<br /> do_syscall_64+0x8c/0x3d0<br /> <br /> be_cmd_set_mac_list() calls dma_free_coherent() under a spin_lock_bh.<br /> Fix it by freeing only after the lock has been released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sunrpc: fix handling of server side tls alerts<br /> <br /> Scott Mayhew discovered a security exploit in NFS over TLS in<br /> tls_alert_recv() due to its assumption it can read data from<br /> the msg iterator&amp;#39;s kvec..<br /> <br /> kTLS implementation splits TLS non-data record payload between<br /> the control message buffer (which includes the type such as TLS<br /> aler or TLS cipher change) and the rest of the payload (say TLS<br /> alert&amp;#39;s level/description) which goes into the msg payload buffer.<br /> <br /> This patch proposes to rework how control messages are setup and<br /> used by sock_recvmsg().<br /> <br /> If no control message structure is setup, kTLS layer will read and<br /> process TLS data record types. As soon as it encounters a TLS control<br /> message, it would return an error. At that point, NFS can setup a<br /> kvec backed msg buffer and read in the control message such as a<br /> TLS alert. Msg iterator can advance the kvec pointer as a part of<br /> the copy process thus we need to revert the iterator before calling<br /> into the tls_alert_recv.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sunrpc: fix client side handling of tls alerts<br /> <br /> A security exploit was discovered in NFS over TLS in tls_alert_recv<br /> due to its assumption that there is valid data in the msghdr&amp;#39;s<br /> iterator&amp;#39;s kvec.<br /> <br /> Instead, this patch proposes the rework how control messages are<br /> setup and used by sock_recvmsg().<br /> <br /> If no control message structure is setup, kTLS layer will read and<br /> process TLS data record types. As soon as it encounters a TLS control<br /> message, it would return an error. At that point, NFS can setup a kvec<br /> backed control buffer and read in the control message such as a TLS<br /> alert. Scott found that a msg iterator can advance the kvec pointer<br /> as a part of the copy process thus we need to revert the iterator<br /> before calling into the tls_alert_recv.