Description Quality Assurance 2025-11-17 13:00:31 CET

New Debian linux 6.1.158-1 fixes:
This update addresses the following issues:
* Improper initialization of CPU cache memory could allow a privileged  attacker with hypervisor access to overwrite SEV-SNP guest memory resulting  in loss of data integrity. (CVE-2024-36331)
* In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT &  HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res  without initializing hpo_dp_link_enc and it is necessary to check for null  before dereferencing. This fixes 2 FORWARD_NULL issues reported by  Coverity. (CVE-2024-47704)
* In the Linux kernel, the following vulnerability has been resolved: fs:  relax assertions on failure to encode file handles Encoding file handles is  usually performed by a filesystem >encode_fh() method that may fail for  various reasons. The legacy users of exportfs_encode_fh(), namely, nfsd and  name_to_handle_at(2) syscall are ready to cope with the possibility of  failure to encode a file handle. There are a few other users of  exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when  ->encode_fh() fails. Relax those assertions because they are wrong. The  second linked bug report states commit 16aac5ad1fa9 ("ovl: support encoding  non-decodable file handles") in v6.6 as the regressing commit, but this is  not accurate. The aforementioned commit only increases the chances of the  assertion and allows triggering the assertion with the reproducer using  overlayfs, inotify and drop_caches. Triggering this assertion was always  possible with other filesystems and other reasons of ->encode_fh() failures  and more particularly, it was also possible with the exact same reproducer  using overlayfs that is mounted with options index=on,nfs_export=on also on  kernels < v6.6. Therefore, I am not listing the aforementioned commit as a  Fixes commit. Backport hint: this patch will have a trivial conflict  applying to v6.6.y, and other trivial conflicts applying to stable kernels  < v6.6. (CVE-2024-57924)
* In the Linux kernel, the following vulnerability has been resolved: tls:  separate no-async decryption request handling from async If we're not doing  async, the handling is much simpler. There's no reference counting, we just  need to wait for the completion to wake us up and return its result. We  should preferably also use a separate crypto_wait. I'm not seeing a UAF as  I did in the past, I think aec7961916f3 ("tls: fix race between async  notify and socket close") took care of it. This will make the next fix  easier. (CVE-2024-58240)
* In the Linux kernel, the following vulnerability has been resolved: net:  Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod. When I ran  the repro [0] and waited a few seconds, I observed two LOCKDEP splats: a  warning immediately followed by a null-ptr-deref. [1] Reproduction Steps:  1) Mount CIFS 2) Add an iptables rule to drop incoming FIN packets for CIFS  3) Unmount CIFS 4) Unload the CIFS module 5) Remove the iptables rule At  step 3), the CIFS module calls sock_release() for the underlying TCP  socket, and it returns quickly. However, the socket remains in FIN_WAIT_1  because incoming FIN packets are dropped. At this point, the module's  refcnt is 0 while the socket is still alive, so the following rmmod command  succeeds. # ss -tan State Recv-Q Send-Q Local Address:Port Peer  Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445 # lsmod | grep  cifs cifs 1159168 0 This highlights a discrepancy between the lifetime of  the CIFS module and the underlying TCP socket. Even after CIFS calls  sock_release() and it returns, the TCP socket does not die immediately in  order to close the connection gracefully. While this is generally fine, it  causes an issue with LOCKDEP because CIFS assigns a different lock class to  the TCP socket's sk->sk_lock using sock_lock_init_class_and_name(). Once an  incoming packet is processed for the socket or a timer fires, sk->sk_lock  is acquired. Then, LOCKDEP checks the lock context in check_wait_context(),  where hlock_class() is called to retrieve the lock class. However, since  the module has already been unloaded, hlock_class() logs a warning and  returns NULL, triggering the null-ptr-deref. If LOCKDEP is enabled, we must  ensure that a module calling sock_lock_init_class_and_name() (CIFS, NFS,  etc) cannot be unloaded while such a socket is still alive to prevent this  issue. Let's hold the module reference in sock_lock_init_class_and_name()  and release it when the socket is freed in sk_prot_free(). Note that  sock_lock_init() clears sk->sk_owner for svc_create_socket() that calls  sock_lock_init_class_and_name() for a listening socket, which clones a  socket by sk_clone_lock() without GFP_ZERO. [0]: CIFS_SERVER="10.0.0.137"  CIFS_PATH="//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST"  DEV="enp0s3" CRED="/root/WindowsCredential.txt" MNT=$(mktemp -d  /tmp/XXXXXX) mount -t cifs ${CIFS_PATH} ${MNT} -o  vers=3.0,credentials=${CRED},cache=none,echo_interval=1 iptables -A INPUT  -s ${CIFS_SERVER} -j DROP for i in $(seq 10); do umount ${MNT} rmmod cifs  sleep 1 done rm -r ${MNT} iptables -D INPUT -s ${CIFS_SERVER} -j DROP [1]:  DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 10 PID: 0 at  kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234  kernel/locking/lockdep.c:223) Modules linked in: cifs_arc4 nls_ucs2_utils  cifs_md4 [last unloaded: cifs] CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not  tainted 6.14.0 #36 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),  BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP:  0010:hlock_class (kernel/locking/lockdep.c:234  kernel/locking/lockdep.c:223) ... Call Trace: <IRQ> __lock_acquire  (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lock_acquire  (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853  kernel/locking/lockdep.c:5816) _raw_spin_lock_nested  (kernel/locking/spinlock.c:379) tcp_v4_rcv (./include/linux/skbuff.h:1678  ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350) ... BUG: kernel NULL  pointer dereference, address: 00000000000000c4 PF: supervisor read access  in kernel mode PF: error_code(0x0000) - not-present page PGD 0 Oops: Oops:  0000 [#1] PREEMPT SMP NOPTI CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted:  G W 6.14.0 #36 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX +  PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014  RIP: 0010:__lock_acquire (kernel/ ---truncated--- (CVE-2025-23143)
* In the Linux kernel, the following vulnerability has been resolved: media:  mediatek: vcodec: Fix a resource leak related to the scp device in FW  initialization On Mediatek devices with a system companion processor (SCP)  the mtk_scp structure has to be removed explicitly to avoid a resource  leak. Free the structure in case the allocation of the firmware structure  fails during the firmware initialization. (CVE-2025-23160)
* In the Linux kernel, the following vulnerability has been resolved: jfs:  reject on-disk inodes of an unsupported type Syzbot has reported the  following BUG: kernel BUG at fs/inode.c:668! Oops: invalid opcode: 0000  [#1] PREEMPT SMP KASAN PTI CPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not  tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0 Hardware name: QEMU  Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 RIP:  0010:clear_inode+0x168/0x190 Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff  44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7 0b e8  01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f RSP:  0018:ffffc900027dfae8 EFLAGS: 00010093 RAX: ffffffff82157a87 RBX:  0000000000000001 RCX: ffff888104d4b980 RDX: 0000000000000000 RSI:  0000000000000001 RDI: 0000000000000000 RBP: ffffc900027dfc90 R08:  ffffffff82157977 R09: fffff520004fbf38 R10: dffffc0000000000 R11:  fffff520004fbf38 R12: dffffc0000000000 R13: ffff88811315bc00 R14:  ffff88811315bda8 R15: ffff88811315bb80 FS: 0000000000000000(0000)  GS:ffff888135f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000  CR0: 0000000080050033 CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4:  00000000000006f0 Call Trace: <TASK> ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0  ? do_trap+0x15a/0x3a0 ? clear_inode+0x168/0x190 ? do_error_trap+0x1dc/0x2c0  ? clear_inode+0x168/0x190 ? __pfx_do_error_trap+0x10/0x10 ?  report_bug+0x3cd/0x500 ? handle_invalid_op+0x34/0x40 ?  clear_inode+0x168/0x190 ? exc_invalid_op+0x38/0x50 ?  asm_exc_invalid_op+0x1a/0x20 ? clear_inode+0x57/0x190 ?  clear_inode+0x167/0x190 ? clear_inode+0x168/0x190 ? clear_inode+0x167/0x190  jfs_evict_inode+0xb5/0x440 ? __pfx_jfs_evict_inode+0x10/0x10  evict+0x4ea/0x9b0 ? __pfx_evict+0x10/0x10 ? iput+0x713/0xa50  txUpdateMap+0x931/0xb10 ? __pfx_txUpdateMap+0x10/0x10  jfs_lazycommit+0x49a/0xb80 ? _raw_spin_unlock_irqrestore+0x8f/0x140 ?  lockdep_hardirqs_on+0x99/0x150 ? __pfx_jfs_lazycommit+0x10/0x10 ?  __pfx_default_wake_function+0x10/0x10 ? __kthread_parkme+0x169/0x1d0 ?  __pfx_jfs_lazycommit+0x10/0x10 kthread+0x2f2/0x390 ?  __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_kthread+0x10/0x10  ret_from_fork+0x4d/0x80 ? __pfx_kthread+0x10/0x10  ret_from_fork_asm+0x1a/0x30 </TASK> This happens when 'clear_inode()' makes  an attempt to finalize an underlying JFS inode of unknown type. According  to JFS layout description from  https://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5  to 15 are reserved for future extensions and should not be encountered on a  valid filesystem. So add an extra check for valid inode type in  'copy_from_dinode()'. (CVE-2025-37925)
* In the Linux kernel, the following vulnerability has been resolved: btrfs:  adjust subpage bit start based on sectorsize When running machines with 64k  page size and a 16k nodesize we started seeing tree log corruption in  production. This turned out to be because we were not writing out dirty  blocks sometimes, so this in fact affects all metadata writes. When writing  out a subpage EB we scan the subpage bitmap for a dirty range. If the range  isn't dirty we do bit_start++; to move onto the next bit. The problem is  the bitmap is based on the number of sectors that an EB has. So in this  case, we have a 64k pagesize, 16k nodesize, but a 4k sectorsize. This means  our bitmap is 4 bits for every node. With a 64k page size we end up with 4  nodes per page. To make this easier this is how everything looks [0 16k 32k  48k ] logical address [0 4 8 12 ] radix tree offset [ 64k page ] folio [  16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers [ | | | | | | | | | |  | | | | | | ] bitmap Now we use all of our addressing based on  fs_info->sectorsize_bits, so as you can see the above our 16k eb->start  turns into radix entry 4. When we find a dirty range for our eb, we  correctly do bit_start += sectors_per_node, because if we start at bit 0,  the next bit for the next eb is 4, to correspond to eb->start 16k. However  if our range is clean, we will do bit_start++, which will now put us offset  from our radix tree entries. In our case, assume that the first time we  check the bitmap the block is not dirty, we increment bit_start so now it  == 1, and then we loop around and check again. This time it is dirty, and  we go to find that start using the following equation start = folio_start +  bit_start * fs_info->sectorsize; so in the case above, eb->start 0 is now  dirty, and we calculate start as 0 + 1 * fs_info->sectorsize = 4096 4096 >>  12 = 1 Now we're looking up the radix tree for 1, and we won't find an eb.  What's worse is now we're using bit_start == 1, so we do bit_start +=  sectors_per_node, which is now 5. If that eb is dirty we will run into the  same thing, we will look at an offset that is not populated in the radix  tree, and now we're skipping the writeout of dirty extent buffers. The best  fix for this is to not use sectorsize_bits to address nodes, but that's a  larger change. Since this is a fs corruption problem fix it simply by  always using sectors_per_node to increment the start bit. (CVE-2025-37931)
* In the Linux kernel, the following vulnerability has been resolved: iio:  light: opt3001: fix deadlock due to concurrent flag access The threaded IRQ  function in this driver is reading the flag twice: once to lock a mutex and  once to unlock it. Even though the code setting the flag is designed to  prevent it, there are subtle cases where the flag could be true at the  mutex_lock stage and false at the mutex_unlock stage. This results in the  mutex not being unlocked, resulting in a deadlock. Fix it by making the  opt3001_irq() code generally more robust, reading the flag into a variable  and using the variable value at both stages. (CVE-2025-37968)
* In the Linux kernel, the following vulnerability has been resolved:  perf/x86/intel: Fix crash in icl_update_topdown_event() The perf_fuzzer  found a hard-lockup crash on a RaptorLake machine: Oops: general protection  fault, maybe for address 0xffff89aeceab400: 0000 CPU: 23 UID: 0 PID: 0  Comm: swapper/23 Tainted: [W]=WARN Hardware name: Dell Inc. Precision  9660/0VJ762 RIP: 0010:native_read_pmc+0x7/0x40 Code: cc e8 8d a9 01 00 48  89 03 5b cd cc cc cc cc 0f 1f ... RSP: 000:fffb03100273de8 EFLAGS: 00010046  .... Call Trace: <TASK> icl_update_topdown_event+0x165/0x190 ?  ktime_get+0x38/0xd0 intel_pmu_read_event+0xf9/0x210  __perf_event_read+0xf9/0x210 CPUs 16-23 are E-core CPUs that don't support  the perf metrics feature. The icl_update_topdown_event() should not be  invoked on these CPUs. It's a regression of commit: f9bdf1f95339  ("perf/x86/intel: Avoid disable PMU if !cpuc->enabled in sample read") The  bug introduced by that commit is that the is_topdown_event() function is  mistakenly used to replace the is_topdown_count() call to check if the  topdown functions for the perf metrics feature should be invoked. Fix it.  (CVE-2025-38322)
* In the Linux kernel, the following vulnerability has been resolved: Input:  gpio-keys - fix a sleep while atomic with PREEMPT_RT When enabling  PREEMPT_RT, the gpio_keys_irq_timer() callback runs in hard irq context,  but the input_event() takes a spin_lock, which isn't allowed there as it is  converted to a rt_spin_lock(). [ 4054.289999] BUG: sleeping function called  from invalid context at kernel/locking/spinlock_rt.c:48 [ 4054.290028]  in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0  ... [ 4054.290195] __might_resched+0x13c/0x1f4 [ 4054.290209]  rt_spin_lock+0x54/0x11c [ 4054.290219] input_event+0x48/0x80 [ 4054.290230]  gpio_keys_irq_timer+0x4c/0x78 [ 4054.290243]  __hrtimer_run_queues+0x1a4/0x438 [ 4054.290257]  hrtimer_interrupt+0xe4/0x240 [ 4054.290269]  arch_timer_handler_phys+0x2c/0x44 [ 4054.290283]  handle_percpu_devid_irq+0x8c/0x14c [ 4054.290297] handle_irq_desc+0x40/0x58  [ 4054.290307] generic_handle_domain_irq+0x1c/0x28 [ 4054.290316]  gic_handle_irq+0x44/0xcc Considering the gpio_keys_irq_isr() can run in any  context, e.g. it can be threaded, it seems there's no point in requesting  the timer isr to run in hard irq context. Relax the hrtimer not to use the  hard context. (CVE-2025-38335)
* In the Linux kernel, the following vulnerability has been resolved: f2fs:  fix to do sanity check on ino and xnid syzbot reported a f2fs bug as below:  INFO: task syz-executor140:5308 blocked for more than 143 seconds. Not  tainted 6.14.0-rc7-syzkaller-00069-g81e4f8d68c66 #0 "echo 0 >  /proc/sys/kernel/hung_task_timeout_secs" disables this message.  task:syz-executor140 state:D stack:24016 pid:5308 tgid:5308 ppid:5306  task_flags:0x400140 flags:0x00000006 Call Trace: <TASK> context_switch  kernel/sched/core.c:5378 [inline] __schedule+0x190e/0x4c90  kernel/sched/core.c:6765 __schedule_loop kernel/sched/core.c:6842 [inline]  schedule+0x14b/0x320 kernel/sched/core.c:6857 io_schedule+0x8d/0x110  kernel/sched/core.c:7690 folio_wait_bit_common+0x839/0xee0  mm/filemap.c:1317 __folio_lock mm/filemap.c:1664 [inline] folio_lock  include/linux/pagemap.h:1163 [inline] __filemap_get_folio+0x147/0xb40  mm/filemap.c:1917 pagecache_get_page+0x2c/0x130 mm/folio-compat.c:87  find_get_page_flags include/linux/pagemap.h:842 [inline]  f2fs_grab_cache_page+0x2b/0x320 fs/f2fs/f2fs.h:2776  __get_node_page+0x131/0x11b0 fs/f2fs/node.c:1463  read_xattr_block+0xfb/0x190 fs/f2fs/xattr.c:306 lookup_all_xattrs  fs/f2fs/xattr.c:355 [inline] f2fs_getxattr+0x676/0xf70 fs/f2fs/xattr.c:533  __f2fs_get_acl+0x52/0x870 fs/f2fs/acl.c:179 f2fs_acl_create  fs/f2fs/acl.c:375 [inline] f2fs_init_acl+0xd7/0x9b0 fs/f2fs/acl.c:418  f2fs_init_inode_metadata+0xa0f/0x1050 fs/f2fs/dir.c:539  f2fs_add_inline_entry+0x448/0x860 fs/f2fs/inline.c:666  f2fs_add_dentry+0xba/0x1e0 fs/f2fs/dir.c:765 f2fs_do_add_link+0x28c/0x3a0  fs/f2fs/dir.c:808 f2fs_add_link fs/f2fs/f2fs.h:3616 [inline]  f2fs_mknod+0x2e8/0x5b0 fs/f2fs/namei.c:766 vfs_mknod+0x36d/0x3b0  fs/namei.c:4191 unix_bind_bsd net/unix/af_unix.c:1286 [inline]  unix_bind+0x563/0xe30 net/unix/af_unix.c:1379 __sys_bind_socket  net/socket.c:1817 [inline] __sys_bind+0x1e4/0x290 net/socket.c:1848  __do_sys_bind net/socket.c:1853 [inline] __se_sys_bind net/socket.c:1851  [inline] __x64_sys_bind+0x7a/0x90 net/socket.c:1851 do_syscall_x64  arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230  arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Let's  dump and check metadata of corrupted inode, it shows its xattr_nid is the  same to its i_ino. dump.f2fs -i 3 chaseyu.img.raw i_xattr_nid [0x 3 : 3] So  that, during mknod in the corrupted directory, it tries to get and lock  inode page twice, result in deadlock. - f2fs_mknod - f2fs_add_inline_entry  - f2fs_get_inode_page --- lock dir's inode page - f2fs_init_acl -  f2fs_acl_create(dir,..) - __f2fs_get_acl - f2fs_getxattr -  lookup_all_xattrs - __get_node_page --- try to lock dir's inode page In  order to fix this, let's add sanity check on ino and xnid. (CVE-2025-38347)
* In the Linux kernel, the following vulnerability has been resolved: mptcp:  make fallback action and fallback decision atomic Syzkaller reported the  following splat: WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223  __mptcp_do_fallback net/mptcp/protocol.h:1223 [inline] WARNING: CPU: 1 PID:  7704 at net/mptcp/protocol.h:1223 mptcp_do_fallback  net/mptcp/protocol.h:1244 [inline] WARNING: CPU: 1 PID: 7704 at  net/mptcp/protocol.h:1223 check_fully_established net/mptcp/options.c:982  [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223  mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153 Modules  linked in: CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted  6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary) Hardware name: QEMU Ubuntu  24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP:  0010:__mptcp_do_fallback net/mptcp/protocol.h:1223 [inline] RIP:  0010:mptcp_do_fallback net/mptcp/protocol.h:1244 [inline] RIP:  0010:check_fully_established net/mptcp/options.c:982 [inline] RIP:  0010:mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153 Code: 24  18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac  24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 <0f> 0b 90 e9 b8 f4 ff ff  e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00 RSP: 0018:ffff8880a3f08448  EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880180a8000 RCX:  ffffffff84afcf45 RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI:  0000000000000001 RBP: ffff888017955780 R08: 0000000000000001 R09:  0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12:  0000000000000000 R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15:  0000000000000000 FS: 00005555791b8500(0000) GS:ffff88811c495000(0000)  knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0 Call  Trace: <IRQ> tcp_reset+0x26f/0x2b0 net/ipv4/tcp_input.c:4432  tcp_validate_incoming+0x1057/0x1b60 net/ipv4/tcp_input.c:5975  tcp_rcv_established+0x5b5/0x21f0 net/ipv4/tcp_input.c:6166  tcp_v4_do_rcv+0x5dc/0xa70 net/ipv4/tcp_ipv4.c:1925 tcp_v4_rcv+0x3473/0x44a0  net/ipv4/tcp_ipv4.c:2363 ip_protocol_deliver_rcu+0xba/0x480  net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2f1/0x500  net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:317 [inline]  NF_HOOK include/linux/netfilter.h:311 [inline] ip_local_deliver+0x1be/0x560  net/ipv4/ip_input.c:254 dst_input include/net/dst.h:469 [inline]  ip_rcv_finish net/ipv4/ip_input.c:447 [inline] NF_HOOK  include/linux/netfilter.h:317 [inline] NF_HOOK  include/linux/netfilter.h:311 [inline] ip_rcv+0x514/0x810  net/ipv4/ip_input.c:567 __netif_receive_skb_one_core+0x197/0x1e0  net/core/dev.c:5975 __netif_receive_skb+0x1f/0x120 net/core/dev.c:6088  process_backlog+0x301/0x1360 net/core/dev.c:6440  __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7453 napi_poll  net/core/dev.c:7517 [inline] net_rx_action+0xb44/0x1010 net/core/dev.c:7644  handle_softirqs+0x1d0/0x770 kernel/softirq.c:579 do_softirq+0x3f/0x90  kernel/softirq.c:480 </IRQ> <TASK> __local_bh_enable_ip+0xed/0x110  kernel/softirq.c:407 local_bh_enable include/linux/bottom_half.h:33  [inline] inet_csk_listen_stop+0x2c5/0x1070  net/ipv4/inet_connection_sock.c:1524  mptcp_check_listen_stop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985  mptcp_check_listen_stop net/mptcp/mib.h:118 [inline]  __mptcp_close+0x9b9/0xbd0 net/mptcp/protocol.c:3000 mptcp_close+0x2f/0x140  net/mptcp/protocol.c:3066 inet_release+0xed/0x200 net/ipv4/af_inet.c:435  inet6_release+0x4f/0x70 net/ipv6/af_inet6.c:487 __sock_release+0xb3/0x270  net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x402/0xb70  fs/file_table.c:465 task_work_run+0x150/0x240 kernel/task_work.c:227  resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]  exit_to_user_mode_loop+0xd4 ---truncated--- (CVE-2025-38491)
* In the Linux kernel, the following vulnerability has been resolved: xfrm:  interface: fix use-after-free after changing collect_md xfrm interface  collect_md property on xfrm interfaces can only be set on device creation,  thus xfrmi_changelink() should fail when called on such interfaces. The  check to enforce this was done only in the case where the xi was returned  from xfrmi_locate() which doesn't look for the collect_md interface, and  thus the validation was never reached. Calling changelink would thus  errornously place the special interface xi in the xfrmi_net->xfrmi hash,  but since it also exists in the xfrmi_net->collect_md_xfrmi pointer it  would lead to a double free when the net namespace was taken down [1].  Change the check to use the xi from netdev_priv which is available earlier  in the function to prevent changes in xfrm collect_md interfaces. [1]  resulting oops: [ 8.516540] kernel BUG at net/core/dev.c:12029! [ 8.516552]  Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 8.516559] CPU: 0 UID: 0 PID: 12  Comm: kworker/u80:0 Not tainted 6.15.0-virtme #5 PREEMPT(voluntary) [  8.516565] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS  1.16.3-debian-1.16.3-2 04/01/2014 [ 8.516569] Workqueue: netns cleanup_net  [ 8.516579] RIP: 0010:unregister_netdevice_many_notify+0x101/0xab0 [  8.516590] Code: 90 0f 0b 90 48 8b b0 78 01 00 00 48 8b 90 80 01 00 00 48 89  56 08 48 89 32 4c 89 80 78 01 00 00 48 89 b8 80 01 00 00 eb ac 90 <0f> 0b  48 8b 45 00 4c 8d a0 88 fe ff ff 48 39 c5 74 5c 41 80 bc 24 [ 8.516593]  RSP: 0018:ffffa93b8006bd30 EFLAGS: 00010206 [ 8.516598] RAX:  ffff98fe4226e000 RBX: ffffa93b8006bd58 RCX: ffffa93b8006bc60 [ 8.516601]  RDX: 0000000000000004 RSI: 0000000000000000 RDI: dead000000000122 [  8.516603] RBP: ffffa93b8006bdd8 R08: dead000000000100 R09: ffff98fe4133c100  [ 8.516605] R10: 0000000000000000 R11: 00000000000003d2 R12:  ffffa93b8006be00 [ 8.516608] R13: ffffffff96c1a510 R14: ffffffff96c1a510  R15: ffffa93b8006be00 [ 8.516615] FS: 0000000000000000(0000)  GS:ffff98fee73b7000(0000) knlGS:0000000000000000 [ 8.516619] CS: 0010 DS:  0000 ES: 0000 CR0: 0000000080050033 [ 8.516622] CR2: 00007fcd2abd0700 CR3:  000000003aa40000 CR4: 0000000000752ef0 [ 8.516625] PKRU: 55555554 [  8.516627] Call Trace: [ 8.516632] <TASK> [ 8.516635] ?  rtnl_is_locked+0x15/0x20 [ 8.516641] ? unregister_netdevice_queue+0x29/0xf0  [ 8.516650] ops_undo_list+0x1f2/0x220 [ 8.516659] cleanup_net+0x1ad/0x2e0 [  8.516664] process_one_work+0x160/0x380 [ 8.516673]  worker_thread+0x2aa/0x3c0 [ 8.516679] ? __pfx_worker_thread+0x10/0x10 [  8.516686] kthread+0xfb/0x200 [ 8.516690] ? __pfx_kthread+0x10/0x10 [  8.516693] ? __pfx_kthread+0x10/0x10 [ 8.516697] ret_from_fork+0x82/0xf0 [  8.516705] ? __pfx_kthread+0x10/0x10 [ 8.516709] ret_from_fork_asm+0x1a/0x30  [ 8.516718] </TASK> (CVE-2025-38500)
* In the Linux kernel, the following vulnerability has been resolved: ksmbd:  limit repeated connections from clients with the same IP Repeated  connections from clients with the same IP address may exhaust the max  connections and prevent other normal client connections. This patch limit  repeated connections from clients with the same IP. (CVE-2025-38501)
* In the Linux kernel, the following vulnerability has been resolved: bpf:  Fix oob access in cgroup local storage Lonial reported that an  out-of-bounds access in cgroup local storage can be crafted via tail calls.  Given two programs each utilizing a cgroup local storage with a different  value size, and one program doing a tail call into the other. The verifier  will validate each of the indivial programs just fine. However, in the  runtime context the bpf_cg_run_ctx holds an bpf_prog_array_item which  contains the BPF program as well as any cgroup local storage flavor the  program uses. Helpers such as bpf_get_local_storage() pick this up from the  runtime context: ctx = container_of(current->bpf_ctx, struct  bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype];  if (stype == BPF_CGROUP_STORAGE_SHARED) ptr =  &READ_ONCE(storage->buf)->data[0]; else ptr =  this_cpu_ptr(storage->percpu_buf); For the second program which was called  from the originally attached one, this means bpf_get_local_storage() will  pick up the former program's map, not its own. With mismatching sizes, this  can result in an unintended out-of-bounds access. To fix this issue, we  need to extend bpf_map_owner with an array of storage_cookie[] to match on  i) the exact maps from the original program if the second program was using  bpf_get_local_storage(), or ii) allow the tail call combination if the  second program was not using any of the cgroup local storage maps.  (CVE-2025-38502)
* In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: Don't call mmput from MMU notifier callback If the process is  exiting, the mmput inside mmu notifier callback from compactd or fork or  numa balancing could release the last reference of mm struct to call  exit_mmap and free_pgtable, this triggers deadlock with below backtrace.  The deadlock will leak kfd process as mmu notifier release is not called  and cause VRAM leaking. The fix is to take mm reference mmget_non_zero when  adding prange to the deferred list to pair with mmput in deferred list  work. If prange split and add into pchild list, the pchild work_item.mm is  not used, so remove the mm parameter from svm_range_unmap_split and  svm_range_add_child. The backtrace of hung task: INFO: task python:348105  blocked for more than 64512 seconds. Call Trace: __schedule+0x1c3/0x550  schedule+0x46/0xb0 rwsem_down_write_slowpath+0x24b/0x4c0  unlink_anon_vmas+0xb1/0x1c0 free_pgtables+0xa9/0x130 exit_mmap+0xbc/0x1a0  mmput+0x5a/0x140 svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu]  mn_itree_invalidate+0x72/0xc0  __mmu_notifier_invalidate_range_start+0x48/0x60  try_to_unmap_one+0x10fa/0x1400 rmap_walk_anon+0x196/0x460  try_to_unmap+0xbb/0x210 migrate_page_unmap+0x54d/0x7e0  migrate_pages_batch+0x1c3/0xae0 migrate_pages_sync+0x98/0x240  migrate_pages+0x25c/0x520 compact_zone+0x29d/0x590  compact_zone_order+0xb6/0xf0 try_to_compact_pages+0xbe/0x220  __alloc_pages_direct_compact+0x96/0x1a0 __alloc_pages_slowpath+0x410/0x930  __alloc_pages_nodemask+0x3a9/0x3e0 do_huge_pmd_anonymous_page+0xd7/0x3e0  __handle_mm_fault+0x5e3/0x5f0 handle_mm_fault+0xf7/0x2e0  hmm_vma_fault.isra.0+0x4d/0xa0 walk_pmd_range.isra.0+0xa8/0x310  walk_pud_range+0x167/0x240 walk_pgd_range+0x55/0x100  __walk_page_range+0x87/0x90 walk_page_range+0xf6/0x160  hmm_range_fault+0x4f/0x90 amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu]  amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu] init_user_pages+0xb1/0x2a0  [amdgpu] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu]  kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu] kfd_ioctl+0x29d/0x500  [amdgpu] (cherry picked from commit  a29e067bd38946f752b0ef855f3dfff87e77bec7) (CVE-2025-38520)
* In the Linux kernel, the following vulnerability has been resolved: mptcp:  plug races between subflow fail and subflow creation We have races similar  to the one addressed by the previous patch between subflow failing and  additional subflow creation. They are just harder to trigger. The solution  is similar. Use a separate flag to track the condition 'socket state  prevent any additional subflow creation' protected by the fallback lock.  The socket fallback makes such flag true, and also receiving or sending an  MP_FAIL option. The field 'allow_infinite_fallback' is now always touched  under the relevant lock, we can drop the ONCE annotation on write.  (CVE-2025-38552)
* In the Linux kernel, the following vulnerability has been resolved:  net/sched: Restrict conditions for adding duplicating netems to qdisc tree  netem_enqueue's duplication prevention logic breaks when a netem resides in  a qdisc tree with other netems - this can lead to a soft lockup and OOM  loop in netem_dequeue, as seen in [1]. Ensure that a duplicating netem  cannot exist in a tree with other netems. Previous approaches suggested in  discussions in chronological order: 1) Track duplication status or ttl in  the sk_buff struct. Considered too specific a use case to extend such a  struct, though this would be a resilient fix and address other previous and  potential future DOS bugs like the one described in loopy fun [2]. 2)  Restrict netem_enqueue recursion depth like in act_mirred with a per cpu  variable. However, netem_dequeue can call enqueue on its child, and the  depth restriction could be bypassed if the child is a netem. 3) Use the  same approach as in 2, but add metadata in netem_skb_cb to handle the  netem_dequeue case and track a packet's involvement in duplication. This is  an overly complex approach, and Jamal notes that the skb cb can be  overwritten to circumvent this safeguard. 4) Prevent the addition of a  netem to a qdisc tree if its ancestral path contains a netem. However,  filters and actions can cause a packet to change paths when re-enqueued to  the root from netem duplication, leading us to the current solution:  prevent a duplicating netem from inhabiting the same tree as other netems.  [1]  https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/  [2] https://lwn.net/Articles/719297/ (CVE-2025-38553)
* In the Linux kernel, the following vulnerability has been resolved: usb:  gadget : fix use-after-free in composite_dev_cleanup() 1. In func  configfs_composite_bind() -> composite_os_desc_req_prepare(): if kmalloc  fails, the pointer cdev->os_desc_req will be freed but not set to NULL.  Then it will return a failure to the upper-level function. 2. in func  configfs_composite_bind() -> composite_dev_cleanup(): it will checks  whether cdev->os_desc_req is NULL. If it is not NULL, it will attempt to  use it.This will lead to a use-after-free issue. BUG: KASAN: use-after-free  in composite_dev_cleanup+0xf4/0x2c0 Read of size 8 at addr 0000004827837a00  by task init/1 CPU: 10 PID: 1 Comm: init Tainted: G O 5.10.97-oh #1  kasan_report+0x188/0x1cc __asan_load8+0xb4/0xbc  composite_dev_cleanup+0xf4/0x2c0 configfs_composite_bind+0x210/0x7ac  udc_bind_to_driver+0xb4/0x1ec usb_gadget_probe_driver+0xec/0x21c  gadget_dev_desc_UDC_store+0x264/0x27c (CVE-2025-38555)
* In the Linux kernel, the following vulnerability has been resolved:  x86/sev: Evict cache lines during SNP memory validation An SNP cache  coherency vulnerability requires a cache line eviction mitigation when  validating memory after a page state change to private. The specific  mitigation is to touch the first and last byte of each 4K page that is  being validated. There is no need to perform the mitigation when performing  a page state change to shared and rescinding validation. CPUID bit  Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit that, when set,  indicates that the software mitigation for this vulnerability is not  needed. Implement the mitigation and invoke it when validating memory  (making it private) and the COHERENCY_SFW_NO bit is not set, indicating the  SNP guest is vulnerable. (CVE-2025-38560)
* In the Linux kernel, the following vulnerability has been resolved: ksmbd:  fix Preauh_HashValue race condition If client send multiple session setup  requests to ksmbd, Preauh_HashValue race condition could happen. There is  no need to free sess->Preauh_HashValue at session setup phase. It can be  freed together with session at connection termination phase.  (CVE-2025-38561)
* In the Linux kernel, the following vulnerability has been resolved: ksmbd:  fix null pointer dereference error in generate_encryptionkey If client send  two session setups with krb5 authenticate to ksmbd, null pointer  dereference error in generate_encryptionkey could happen.  sess->Preauth_HashValue is set to NULL if session is valid. So this patch  skip generate encryption key if session is valid. (CVE-2025-38562)
* In the Linux kernel, the following vulnerability has been resolved:  perf/core: Prevent VMA split of buffer mappings The perf mmap code is  careful about mmap()'ing the user page with the ringbuffer and additionally  the auxiliary buffer, when the event supports it. Once the first mapping is  established, subsequent mapping have to use the same offset and the same  size in both cases. The reference counting for the ringbuffer and the  auxiliary buffer depends on this being correct. Though perf does not  prevent that a related mapping is split via mmap(2), munmap(2) or  mremap(2). A split of a VMA results in perf_mmap_open() calls, which take  reference counts, but then the subsequent perf_mmap_close() calls are not  longer fulfilling the offset and size checks. This leads to reference count  leaks. As perf already has the requirement for subsequent mappings to match  the initial mapping, the obvious consequence is that VMA splits, caused by  resizing of a mapping or partial unmapping, have to be prevented. Implement  the vm_operations_struct::may_split() callback and return unconditionally  -EINVAL. That ensures that the mapping offsets and sizes cannot be changed  after the fact. Remapping to a different fixed address with the same size  is still possible as it takes the references for the new mapping and drops  those of the old mapping. (CVE-2025-38563)
* In the Linux kernel, the following vulnerability has been resolved:  perf/core: Exit early on perf_mmap() fail When perf_mmap() fails to  allocate a buffer, it still invokes the event_mapped() callback of the  related event. On X86 this might increase the perf_rdpmc_allowed reference  counter. But nothing undoes this as perf_mmap_close() is never called in  this case, which causes another reference count leak. Return early on  failure to prevent that. (CVE-2025-38565)
* In the Linux kernel, the following vulnerability has been resolved: benet:  fix BUG when creating VFs benet crashes as soon as SRIOV VFs are created:  kernel BUG at mm/vmalloc.c:3457! Oops: invalid opcode: 0000 [#1] SMP KASAN  NOPTI CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted  6.16.0+ #1 PREEMPT(voluntary) [...] RIP: 0010:vunmap+0x5f/0x70 [...] Call  Trace: <TASK> __iommu_dma_free+0xe8/0x1c0 be_cmd_set_mac_list+0x3fe/0x640  [be2net] be_cmd_set_mac+0xaf/0x110 [be2net]  be_vf_eth_addr_config+0x19f/0x330 [be2net] be_vf_setup+0x4f7/0x990 [be2net]  be_pci_sriov_configure+0x3a1/0x470 [be2net] sriov_numvfs_store+0x20b/0x380  kernfs_fop_write_iter+0x354/0x530 vfs_write+0x9b9/0xf60  ksys_write+0xf3/0x1d0 do_syscall_64+0x8c/0x3d0 be_cmd_set_mac_list() calls  dma_free_coherent() under a spin_lock_bh. Fix it by freeing only after the  lock has been released. (CVE-2025-38569)
* In the Linux kernel, the following vulnerability has been resolved: ipv6:  reject malicious packets in ipv6_gso_segment() syzbot was able to craft a  packet with very long IPv6 extension headers leading to an overflow of  skb->transport_header. This 16bit field has a limited range. Add  skb_reset_transport_header_careful() helper and use it from  ipv6_gso_segment() WARNING: CPU: 0 PID: 5871 at  ./include/linux/skbuff.h:3032 skb_reset_transport_header  include/linux/skbuff.h:3032 [inline] WARNING: CPU: 0 PID: 5871 at  ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0  net/ipv6/ip6_offload.c:151 Modules linked in: CPU: 0 UID: 0 PID: 5871 Comm:  syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0  PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute  Engine, BIOS Google 07/12/2025 RIP: 0010:skb_reset_transport_header  include/linux/skbuff.h:3032 [inline] RIP:  0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Call Trace:  <TASK> skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53  nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110  skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53  __skb_gso_segment+0x342/0x510 net/core/gso.c:124 skb_gso_segment  include/net/gso.h:83 [inline] validate_xmit_skb+0x857/0x11b0  net/core/dev.c:3950 validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000  sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329 __dev_xmit_skb  net/core/dev.c:4102 [inline] __dev_queue_xmit+0x17b6/0x3a70  net/core/dev.c:4679 (CVE-2025-38572)
* In the Linux kernel, the following vulnerability has been resolved: pptp:  ensure minimal skb length in pptp_xmit() Commit aabc6596ffb3 ("net: ppp:  Add bound checking for skb data on ppp_sync_txmung") fixed  ppp_sync_txmunge() We need a similar fix in pptp_xmit(), otherwise we might  read uninit data as reported by syzbot. BUG: KMSAN: uninit-value in  pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptp_xmit+0xc34/0x2720  drivers/net/ppp/pptp.c:193 ppp_channel_bridge_input  drivers/net/ppp/ppp_generic.c:2290 [inline] ppp_input+0x1d6/0xe60  drivers/net/ppp/ppp_generic.c:2314 pppoe_rcv_core+0x1e8/0x760  drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x142/0x420  include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213  release_sock+0x6b/0x270 net/core/sock.c:3767 pppoe_sendmsg+0x15d/0xcb0  drivers/net/ppp/pppoe.c:904 sock_sendmsg_nosec net/socket.c:712 [inline]  __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x893/0xd80  net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620  __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709 (CVE-2025-38574)
* In the Linux kernel, the following vulnerability has been resolved:  powerpc/eeh: Make EEH driver device hotplug safe Multiple race conditions  existed between the PCIe hotplug driver and the EEH driver, leading to a  variety of kernel oopses of the same general nature: <pcie device unplug>  <eeh driver trigger> <hotplug removal trigger> <pcie tree reconfiguration>  <eeh recovery next step> <oops in EEH driver bus iteration loop> A second  class of oops is also seen when the underlying bus disappears during device  recovery. Refactor the EEH module to be PCI rescan and remove safe. Also  clean up a few minor formatting / readability issues. (CVE-2025-38576)
* In the Linux kernel, the following vulnerability has been resolved: f2fs:  fix to avoid panic in f2fs_evict_inode As syzbot [1] reported as below:  R10: 0000000000000100 R11: 0000000000000206 R12: 00007ffe17473450 R13:  00007f28b1c10854 R14: 000000000000dae5 R15: 00007ffe17474520 </TASK> ---[  end trace 0000000000000000 ]---  ================================================================== BUG:  KASAN: use-after-free in __list_del_entry_valid+0xa6/0x130  lib/list_debug.c:62 Read of size 8 at addr ffff88812d962278 by task  syz-executor/564 CPU: 1 PID: 564 Comm: syz-executor Tainted: G W  6.1.129-syzkaller #0 Hardware name: Google Google Compute Engine/Google  Compute Engine, BIOS Google 02/12/2025 Call Trace: <TASK>  __dump_stack+0x21/0x24 lib/dump_stack.c:88 dump_stack_lvl+0xee/0x158  lib/dump_stack.c:106 print_address_description+0x71/0x210  mm/kasan/report.c:316 print_report+0x4a/0x60 mm/kasan/report.c:427  kasan_report+0x122/0x150 mm/kasan/report.c:531  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:351  __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 __list_del_entry  include/linux/list.h:134 [inline] list_del_init include/linux/list.h:206  [inline] f2fs_inode_synced+0xf7/0x2e0 fs/f2fs/super.c:1531  f2fs_update_inode+0x74/0x1c40 fs/f2fs/inode.c:585  f2fs_update_inode_page+0x137/0x170 fs/f2fs/inode.c:703  f2fs_write_inode+0x4ec/0x770 fs/f2fs/inode.c:731 write_inode  fs/fs-writeback.c:1460 [inline] __writeback_single_inode+0x4a0/0xab0  fs/fs-writeback.c:1677 writeback_single_inode+0x221/0x8b0  fs/fs-writeback.c:1733 sync_inode_metadata+0xb6/0x110  fs/fs-writeback.c:2789 f2fs_sync_inode_meta+0x16d/0x2a0  fs/f2fs/checkpoint.c:1159 block_operations fs/f2fs/checkpoint.c:1269  [inline] f2fs_write_checkpoint+0xca3/0x2100 fs/f2fs/checkpoint.c:1658  kill_f2fs_super+0x231/0x390 fs/f2fs/super.c:4668  deactivate_locked_super+0x98/0x100 fs/super.c:332  deactivate_super+0xaf/0xe0 fs/super.c:363 cleanup_mnt+0x45f/0x4e0  fs/namespace.c:1186 __cleanup_mnt+0x19/0x20 fs/namespace.c:1193  task_work_run+0x1c6/0x230 kernel/task_work.c:203 exit_task_work  include/linux/task_work.h:39 [inline] do_exit+0x9fb/0x2410  kernel/exit.c:871 do_group_exit+0x210/0x2d0 kernel/exit.c:1021  __do_sys_exit_group kernel/exit.c:1032 [inline] __se_sys_exit_group  kernel/exit.c:1030 [inline] __x64_sys_exit_group+0x3f/0x40  kernel/exit.c:1030 x64_sys_call+0x7b4/0x9a0  arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64  arch/x86/entry/common.c:51 [inline] do_syscall_64+0x4c/0xa0  arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 RIP:  0033:0x7f28b1b8e169 Code: Unable to access opcode bytes at 0x7f28b1b8e13f.  RSP: 002b:00007ffe174710a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX:  ffffffffffffffda RBX: 00007f28b1c10879 RCX: 00007f28b1b8e169 RDX:  0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001 RBP:  0000000000000002 R08: 00007ffe1746ee47 R09: 00007ffe17472360 R10:  0000000000000009 R11: 0000000000000246 R12: 00007ffe17472360 R13:  00007f28b1c10854 R14: 000000000000dae5 R15: 00007ffe17474520 </TASK>  Allocated by task 569: kasan_save_stack mm/kasan/common.c:45 [inline]  kasan_set_track+0x4b/0x70 mm/kasan/common.c:52  kasan_save_alloc_info+0x25/0x30 mm/kasan/generic.c:505  __kasan_slab_alloc+0x72/0x80 mm/kasan/common.c:328 kasan_slab_alloc  include/linux/kasan.h:201 [inline] slab_post_alloc_hook+0x4f/0x2c0  mm/slab.h:737 slab_alloc_node mm/slub.c:3398 [inline] slab_alloc  mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline]  kmem_cache_alloc_lru+0x104/0x220 mm/slub.c:3429 alloc_inode_sb  include/linux/fs.h:3245 [inline] f2fs_alloc_inode+0x2d/0x340  fs/f2fs/super.c:1419 alloc_inode fs/inode.c:261 [inline]  iget_locked+0x186/0x880 fs/inode.c:1373 f2fs_iget+0x55/0x4c60  fs/f2fs/inode.c:483 f2fs_lookup+0x366/0xab0 fs/f2fs/namei.c:487  __lookup_slow+0x2a3/0x3d0 fs/namei.c:1690 lookup_slow+0x57/0x70  fs/namei.c:1707 walk_component+0x2e6/0x410 fs/namei ---truncated---  (CVE-2025-38577)
* In the Linux kernel, the following vulnerability has been resolved: f2fs:  fix to avoid UAF in f2fs_sync_inode_meta() syzbot reported an UAF issue as  below: [1] [2] [1]  https://syzkaller.appspot.com/text?tag=CrashReport&x=16594c60580000  ================================================================== BUG:  KASAN: use-after-free in __list_del_entry_valid+0xa6/0x130  lib/list_debug.c:62 Read of size 8 at addr ffff888100567dc8 by task  kworker/u4:0/8 CPU: 1 PID: 8 Comm: kworker/u4:0 Tainted: G W  6.1.129-syzkaller-00017-g642656a36791 #0 Hardware name: Google Google  Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Workqueue:  writeback wb_workfn (flush-7:0) Call Trace: <TASK> __dump_stack  lib/dump_stack.c:88 [inline] dump_stack_lvl+0x151/0x1b7  lib/dump_stack.c:106 print_address_description mm/kasan/report.c:316  [inline] print_report+0x158/0x4e0 mm/kasan/report.c:427  kasan_report+0x13c/0x170 mm/kasan/report.c:531  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:351  __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 __list_del_entry  include/linux/list.h:134 [inline] list_del_init include/linux/list.h:206  [inline] f2fs_inode_synced+0x100/0x2e0 fs/f2fs/super.c:1553  f2fs_update_inode+0x72/0x1c40 fs/f2fs/inode.c:588  f2fs_update_inode_page+0x135/0x170 fs/f2fs/inode.c:706  f2fs_write_inode+0x416/0x790 fs/f2fs/inode.c:734 write_inode  fs/fs-writeback.c:1460 [inline] __writeback_single_inode+0x4cf/0xb80  fs/fs-writeback.c:1677 writeback_sb_inodes+0xb32/0x1910  fs/fs-writeback.c:1903 __writeback_inodes_wb+0x118/0x3f0  fs/fs-writeback.c:1974 wb_writeback+0x3da/0xa00 fs/fs-writeback.c:2081  wb_check_background_flush fs/fs-writeback.c:2151 [inline] wb_do_writeback  fs/fs-writeback.c:2239 [inline] wb_workfn+0xbba/0x1030  fs/fs-writeback.c:2266 process_one_work+0x73d/0xcb0 kernel/workqueue.c:2299  worker_thread+0xa60/0x1260 kernel/workqueue.c:2446 kthread+0x26d/0x300  kernel/kthread.c:386 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295  </TASK> Allocated by task 298: kasan_save_stack mm/kasan/common.c:45  [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52  kasan_save_alloc_info+0x1f/0x30 mm/kasan/generic.c:505  __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:333 kasan_slab_alloc  include/linux/kasan.h:202 [inline] slab_post_alloc_hook+0x53/0x2c0  mm/slab.h:768 slab_alloc_node mm/slub.c:3421 [inline] slab_alloc  mm/slub.c:3431 [inline] __kmem_cache_alloc_lru mm/slub.c:3438 [inline]  kmem_cache_alloc_lru+0x102/0x270 mm/slub.c:3454 alloc_inode_sb  include/linux/fs.h:3255 [inline] f2fs_alloc_inode+0x2d/0x350  fs/f2fs/super.c:1437 alloc_inode fs/inode.c:261 [inline]  iget_locked+0x18c/0x7e0 fs/inode.c:1373 f2fs_iget+0x55/0x4ca0  fs/f2fs/inode.c:486 f2fs_lookup+0x3c1/0xb50 fs/f2fs/namei.c:484  __lookup_slow+0x2b9/0x3e0 fs/namei.c:1689 lookup_slow+0x5a/0x80  fs/namei.c:1706 walk_component+0x2e7/0x410 fs/namei.c:1997 lookup_last  fs/namei.c:2454 [inline] path_lookupat+0x16d/0x450 fs/namei.c:2478  filename_lookup+0x251/0x600 fs/namei.c:2507 vfs_statx+0x107/0x4b0  fs/stat.c:229 vfs_fstatat fs/stat.c:267 [inline] vfs_lstat  include/linux/fs.h:3434 [inline] __do_sys_newlstat fs/stat.c:423 [inline]  __se_sys_newlstat+0xda/0x7c0 fs/stat.c:417 __x64_sys_newlstat+0x5b/0x70  fs/stat.c:417 x64_sys_call+0x52/0x9a0  arch/x86/include/generated/asm/syscalls_64.h:7 do_syscall_x64  arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3b/0x80  arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 Freed  by task 0: kasan_save_stack mm/kasan/common.c:45 [inline]  kasan_set_track+0x4b/0x70 mm/kasan/common.c:52  kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:516  ____kasan_slab_free+0x131/0x180 mm/kasan/common.c:241  __kasan_slab_free+0x11/0x20 mm/kasan/common.c:249 kasan_slab_free  include/linux/kasan.h:178 [inline] slab_free_hook mm/slub.c:1745 [inline]  slab_free_freelist_hook mm/slub.c:1771 [inline] slab_free mm/slub.c:3686  [inline] kmem_cache_free+0x ---truncated--- (CVE-2025-38578)
* In the Linux kernel, the following vulnerability has been resolved: f2fs:  fix KMSAN uninit-value in extent_info usage KMSAN reported a use of  uninitialized value in `__is_extent_mergeable()` and  `__is_back_mergeable()` via the read extent tree path. The root cause is  that `get_read_extent_info()` only initializes three fields (`fofs`, `blk`,  `len`) of `struct extent_info`, leaving the remaining fields uninitialized.  This leads to undefined behavior when those fields are accessed later,  especially during extent merging. Fix it by zero-initializing the  `extent_info` struct before population. (CVE-2025-38579)
* In the Linux kernel, the following vulnerability has been resolved: crypto:  ccp - Fix crash when rebind ccp device for ccp.ko When  CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding the ccp device causes  the following crash: $ echo '0000:0a:00.2' >  /sys/bus/pci/drivers/ccp/unbind $ echo '0000:0a:00.2' >  /sys/bus/pci/drivers/ccp/bind [ 204.976930] BUG: kernel NULL pointer  dereference, address: 0000000000000098 [ 204.978026] #PF: supervisor write  access in kernel mode [ 204.979126] #PF: error_code(0x0002) - not-present  page [ 204.980226] PGD 0 P4D 0 [ 204.981317] Oops: Oops: 0002 [#1] SMP  NOPTI ... [ 204.997852] Call Trace: [ 204.999074] <TASK> [ 205.000297]  start_creating+0x9f/0x1c0 [ 205.001533] debugfs_create_dir+0x1f/0x170 [  205.002769] ? srso_return_thunk+0x5/0x5f [ 205.004000]  ccp5_debugfs_setup+0x87/0x170 [ccp] [ 205.005241] ccp5_init+0x8b2/0x960  [ccp] [ 205.006469] ccp_dev_init+0xd4/0x150 [ccp] [ 205.007709]  sp_init+0x5f/0x80 [ccp] [ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp] [  205.010165] ? srso_return_thunk+0x5/0x5f [ 205.011376]  local_pci_probe+0x4f/0xb0 [ 205.012584] pci_device_probe+0xdb/0x230 [  205.013810] really_probe+0xed/0x380 [ 205.015024]  __driver_probe_device+0x7e/0x160 [ 205.016240]  device_driver_attach+0x2f/0x60 [ 205.017457] bind_store+0x7c/0xb0 [  205.018663] drv_attr_store+0x28/0x40 [ 205.019868] sysfs_kf_write+0x5f/0x70  [ 205.021065] kernfs_fop_write_iter+0x145/0x1d0 [ 205.022267]  vfs_write+0x308/0x440 [ 205.023453] ksys_write+0x6d/0xe0 [ 205.024616]  __x64_sys_write+0x1e/0x30 [ 205.025778] x64_sys_call+0x16ba/0x2150 [  205.026942] do_syscall_64+0x56/0x1e0 [ 205.028108]  entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 205.029276] RIP:  0033:0x7fbc36f10104 [ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e  0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01  00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53  48 89 f5 This patch sets ccp_debugfs_dir to NULL after destroying it in  ccp5_debugfs_destroy, allowing the directory dentry to be recreated when  rebinding the ccp device. Tested on AMD Ryzen 7 1700X. (CVE-2025-38581)
* In the Linux kernel, the following vulnerability has been resolved: clk:  xilinx: vcu: unregister pll_post only if registered correctly If  registration of pll_post is failed, it will be set to NULL or ERR,  unregistering same will fail with following call trace: Unable to handle  kernel NULL pointer dereference at virtual address 008 pc :  clk_hw_unregister+0xc/0x20 lr : clk_hw_unregister_fixed_factor+0x18/0x30 sp  : ffff800011923850 ... Call trace: clk_hw_unregister+0xc/0x20  clk_hw_unregister_fixed_factor+0x18/0x30  xvcu_unregister_clock_provider+0xcc/0xf4 [xlnx_vcu] xvcu_probe+0x2bc/0x53c  [xlnx_vcu] (CVE-2025-38583)
* In the Linux kernel, the following vulnerability has been resolved: ipv6:  fix possible infinite loop in fib6_info_uses_dev() fib6_info_uses_dev()  seems to rely on RCU without an explicit protection. Like the prior fix in  rt6_nlmsg_size(), we need to make sure fib6_del_route() or  fib6_add_rt2node() have not removed the anchor from the list, or we risk an  infinite loop. (CVE-2025-38587)
* In the Linux kernel, the following vulnerability has been resolved: ipv6:  prevent infinite loop in rt6_nlmsg_size() While testing prior patch, I was  able to trigger an infinite loop in rt6_nlmsg_size() in the following  place: list_for_each_entry_rcu(sibling, &f6i->fib6_siblings, fib6_siblings)  { rt6_nh_nlmsg_size(sibling->fib6_nh, &nexthop_len); } This is because  fib6_del_route() and fib6_add_rt2node() uses list_del_rcu(), which can  confuse rcu readers, because they might no longer see the head of the list.  Restart the loop if f6i->fib6_nsiblings is zero. (CVE-2025-38588)
* In the Linux kernel, the following vulnerability has been resolved: wifi:  ath11k: clear initialized flag for deinit-ed srng lists In a number of  cases we see kernel panics on resume due to ath11k kernel page fault, which  happens under the following circumstances: 1) First  ath11k_hal_dump_srng_stats() call Last interrupt received for each group:  ath11k_pci 0000:01:00.0: group_id 0 22511ms before ath11k_pci 0000:01:00.0:  group_id 1 14440788ms before [..] ath11k_pci 0000:01:00.0: failed to  receive control response completion, polling.. ath11k_pci 0000:01:00.0:  Service connect timeout ath11k_pci 0000:01:00.0: failed to connect to HTT:  -110 ath11k_pci 0000:01:00.0: failed to start core: -110 ath11k_pci  0000:01:00.0: firmware crashed: MHI_CB_EE_RDDM ath11k_pci 0000:01:00.0:  already resetting count 2 ath11k_pci 0000:01:00.0: failed to wait wlan mode  request (mode 4): -110 ath11k_pci 0000:01:00.0: qmi failed to send wlan  mode off: -110 ath11k_pci 0000:01:00.0: failed to reconfigure driver on  crash recovery [..] 2) At this point reconfiguration fails (we have 2  resets) and ath11k_core_reconfigure_on_crash() calls  ath11k_hal_srng_deinit() which destroys srng lists. However, it does not  reset per-list ->initialized flag. 3) Second ath11k_hal_dump_srng_stats()  call sees stale ->initialized flag and attempts to dump srng stats: Last  interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0  66785ms before ath11k_pci 0000:01:00.0: group_id 1 14485062ms before  ath11k_pci 0000:01:00.0: group_id 2 14485062ms before ath11k_pci  0000:01:00.0: group_id 3 14485062ms before ath11k_pci 0000:01:00.0:  group_id 4 14780845ms before ath11k_pci 0000:01:00.0: group_id 5 14780845ms  before ath11k_pci 0000:01:00.0: group_id 6 14485062ms before ath11k_pci  0000:01:00.0: group_id 7 66814ms before ath11k_pci 0000:01:00.0: group_id 8  68997ms before ath11k_pci 0000:01:00.0: group_id 9 67588ms before  ath11k_pci 0000:01:00.0: group_id 10 69511ms before BUG: unable to handle  page fault for address: ffffa007404eb010 #PF: supervisor read access in  kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D  100000067 PUD 10022d067 PMD 100b01067 PTE 0 Oops: 0000 [#1] PREEMPT SMP  NOPTI RIP: 0010:ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k] Call Trace:  <TASK> ? __die_body+0xae/0xb0 ? page_fault_oops+0x381/0x3e0 ?  exc_page_fault+0x69/0xa0 ? asm_exc_page_fault+0x22/0x30 ?  ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)]  ath11k_qmi_driver_event_work+0xbd/0x1050 [ath11k (HASH:6cea 4)]  worker_thread+0x389/0x930 kthread+0x149/0x170 Clear per-list ->initialized  flag in ath11k_hal_srng_deinit(). (CVE-2025-38601)
* In the Linux kernel, the following vulnerability has been resolved:  iwlwifi: Add missing check for alloc_ordered_workqueue Add check for the  return value of alloc_ordered_workqueue since it may return NULL pointer.  (CVE-2025-38602)
* In the Linux kernel, the following vulnerability has been resolved: wifi:  rtl818x: Kill URBs before clearing tx status queue In rtl8187_stop() move  the call of usb_kill_anchored_urbs() before clearing b_tx_status.queue.  This change prevents callbacks from using already freed skb due to anchor  was not killed before freeing such skb. BUG: kernel NULL pointer  dereference, address: 0000000000000080 #PF: supervisor read access in  kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops:  Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted  6.15.0 #8 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX +  PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP:  0010:ieee80211_tx_status_irqsafe+0x21/0xc0 [mac80211] Call Trace: <IRQ>  rtl8187_tx_cb+0x116/0x150 [rtl8187] __usb_hcd_giveback_urb+0x9d/0x120  usb_giveback_urb_bh+0xbb/0x140 process_one_work+0x19b/0x3c0  bh_worker+0x1a7/0x210 tasklet_action+0x10/0x30 handle_softirqs+0xf0/0x340  __irq_exit_rcu+0xcd/0xf0 common_interrupt+0x85/0xa0 </IRQ> Tested on  RTL8187BvE device. Found by Linux Verification Center (linuxtesting.org)  with SVACE. (CVE-2025-38604)
* In the Linux kernel, the following vulnerability has been resolved: bpf,  ktls: Fix data corruption when using bpf_msg_pop_data() in ktls When  sending plaintext data, we initially calculated the corresponding  ciphertext length. However, if we later reduced the plaintext data length  via socket policy, we failed to recalculate the ciphertext length. This  results in transmitting buffers containing uninitialized data during  ciphertext transmission. This causes uninitialized bytes to be appended  after a complete "Application Data" packet, leading to errors on the  receiving end when parsing TLS record. (CVE-2025-38608)
* In the Linux kernel, the following vulnerability has been resolved: PM /  devfreq: Check governor before using governor->name Commit 96ffcdf239de  ("PM / devfreq: Remove redundant governor_name from struct devfreq")  removes governor_name and uses governor->name to replace it. But  devfreq->governor may be NULL and directly using devfreq->governor->name  may cause null pointer exception. Move the check of governor to before  using governor->name. (CVE-2025-38609)
* In the Linux kernel, the following vulnerability has been resolved:  powercap: dtpm_cpu: Fix NULL pointer dereference in get_pd_power_uw() The  get_pd_power_uw() function can crash with a NULL pointer dereference when  em_cpu_get() returns NULL. This occurs when a CPU becomes impossible during  runtime, causing get_cpu_device() to return NULL, which propagates through  em_cpu_get() and leads to a crash when em_span_cpus() dereferences the NULL  pointer. Add a NULL check after em_cpu_get() and return 0 if unavailable,  matching the existing fallback behavior in __dtpm_cpu_setup(). [ rjw: Drop  an excess empty code line ] (CVE-2025-38610)
* In the Linux kernel, the following vulnerability has been resolved:  staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc() In  the error paths after fb_info structure is successfully allocated, the  memory allocated in fb_deferred_io_init() for info->pagerefs is not freed.  Fix that by adding the cleanup function on the error path. (CVE-2025-38612)
* In the Linux kernel, the following vulnerability has been resolved:  eventpoll: Fix semi-unbounded recursion Ensure that epoll instances can  never form a graph deeper than EP_MAX_NESTS+1 links. Currently,  ep_loop_check_proc() ensures that the graph is loop-free and does some  recursion depth checks, but those recursion depth checks don't limit the  depth of the resulting tree for two reasons: - They don't look upwards in  the tree. - If there are multiple downwards paths of different lengths,  only one of the paths is actually considered for the depth check since  commit 28d82dc1c4ed ("epoll: limit paths"). Essentially, the current  recursion depth check in ep_loop_check_proc() just serves to prevent it  from recursing too deeply while checking for loops. A more thorough check  is done in reverse_path_check() after the new graph edge has already been  created; this checks, among other things, that no paths going upwards from  any non-epoll file with a length of more than 5 edges exist. However, this  check does not apply to non-epoll files. As a result, it is possible to  recurse to a depth of at least roughly 500, tested on v6.15. (I am unsure  if deeper recursion is possible; and this may have changed with commit  8c44dac8add7 ("eventpoll: Fix priority inversion problem").) To fix it: 1.  In ep_loop_check_proc(), note the subtree depth of each visited node, and  use subtree depths for the total depth calculation even when a subtree has  already been visited. 2. Add ep_get_upwards_depth_proc() for similarly  determining the maximum depth of an upwards walk. 3. In ep_loop_check(),  use these values to limit the total path length between epoll nodes to  EP_MAX_NESTS edges. (CVE-2025-38614)
* In the Linux kernel, the following vulnerability has been resolved:  net/packet: fix a race in packet_set_ring() and packet_notifier() When  packet_set_ring() releases po->bind_lock, another thread can run  packet_notifier() and process an NETDEV_UP event. This race and the fix are  both similar to that of commit 15fe076edea7 ("net/packet: fix a race in  packet_bind() and packet_notifier()"). There too the packet_notifier  NETDEV_UP event managed to run while a po->bind_lock critical section had  to be temporarily released. And the fix was similarly to temporarily set  po->num to zero to keep the socket unhooked until the lock is retaken. The  po->bind_lock in packet_set_ring and packet_notifier precede the  introduction of git history. (CVE-2025-38617)
* In the Linux kernel, the following vulnerability has been resolved: vsock:  Do not allow binding to VMADDR_PORT_ANY It is possible for a vsock to  autobind to VMADDR_PORT_ANY. This can cause a use-after-free when a  connection is made to the bound socket. The socket returned by accept()  also has port VMADDR_PORT_ANY but is not on the list of unbound sockets.  Binding it will result in an extra refcount decrement similar to the one  fixed in fcdd2242c023 (vsock: Keep the binding until socket destruction).  Modify the check in __vsock_bind_connectible() to also prevent binding to  VMADDR_PORT_ANY. (CVE-2025-38618)
* In the Linux kernel, the following vulnerability has been resolved: net:  drop UFO packets in udp_rcv_segment() When sending a packet with  virtio_net_hdr to tun device, if the gso_type in virtio_net_hdr is  SKB_GSO_UDP and the gso_size is less than udphdr size, below crash may  happen. ------------[ cut here ]------------ kernel BUG at  net/core/skbuff.c:4572! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0  UID: 0 PID: 62 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary)  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1  04/01/2014 RIP: 0010:skb_pull_rcsum+0x8e/0xa0 Code: 00 00 5b c3 cc cc cc cc  8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8  00 00 00 5b c3 cc cc cc cc <0f> 0b 0f 0b 66 66 2e 0f 1f 84 00 000 RSP:  0018:ffffc900001fba38 EFLAGS: 00000297 RAX: 0000000000000004 RBX:  ffff8880040c1000 RCX: ffffc900001fb948 RDX: ffff888003e6d700 RSI:  0000000000000008 RDI: ffff88800411a062 RBP: ffff8880040c1000 R08:  0000000000000000 R09: 0000000000000001 R10: ffff888003606c00 R11:  0000000000000001 R12: 0000000000000000 R13: ffff888004060900 R14:  ffff888004050000 R15: ffff888004060900 FS: 000000002406d3c0(0000)  GS:ffff888084a19000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000  CR0: 0000000080050033 CR2: 0000000020000040 CR3: 0000000004007000 CR4:  00000000000006f0 Call Trace: <TASK> udp_queue_rcv_one_skb+0x176/0x4b0  net/ipv4/udp.c:2445 udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475  udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626  __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690  ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205  ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233  ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579  ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636 ip_list_rcv+0xf7/0x130  net/ipv4/ip_input.c:670 __netif_receive_skb_list_core+0x21d/0x240  net/core/dev.c:6067 netif_receive_skb_list_internal+0x186/0x2b0  net/core/dev.c:6210 napi_complete_done+0x78/0x180 net/core/dev.c:6580  tun_get_user+0xa63/0x1120 drivers/net/tun.c:1909  tun_chr_write_iter+0x65/0xb0 drivers/net/tun.c:1984 vfs_write+0x300/0x420  fs/read_write.c:593 ksys_write+0x60/0xd0 fs/read_write.c:686  do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63 </TASK> To trigger  gso segment in udp_queue_rcv_skb(), we should also set option  UDP_ENCAP_ESPINUDP to enable udp_sk(sk)->encap_rcv. When the encap_rcv hook  return 1 in udp_queue_rcv_one_skb(), udp_csum_pull_header() will try to  pull udphdr, but the skb size has been segmented to gso size, which leads  to this crash. Previous commit cf329aa42b66 ("udp: cope with UDP GRO packet  misdirection") introduces segmentation in UDP receive path only for GRO,  which was never intended to be used for UFO, so drop UFO packets in  udp_rcv_segment(). (CVE-2025-38622)
* In the Linux kernel, the following vulnerability has been resolved: PCI:  pnv_php: Fix surprise plug detection and recovery The existing PowerNV  hotplug code did not handle surprise plug events correctly, leading to a  complete failure of the hotplug system after device removal and a required  reboot to detect new devices. This comes down to two issues: 1) When a  device is surprise removed, often the bridge upstream port will cause a PE  freeze on the PHB. If this freeze is not cleared, the MSI interrupts from  the bridge hotplug notification logic will not be received by the kernel,  stalling all plug events on all slots associated with the PE. 2) When a  device is removed from a slot, regardless of surprise or programmatic  removal, the associated PHB/PE ls left frozen. If this freeze is not  cleared via a fundamental reset, skiboot is unable to clear the freeze and  cannot retrain / rescan the slot. This also requires a reboot to clear the  freeze and redetect the device in the slot. Issue the appropriate unfreeze  and rescan commands on hotplug events, and don't oo