OESA-2025-2079

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

mac802154: check local interfaces before deleting sdata list

syzkaller reported a corrupted list in ieee802154ifremove. [1]

Remove an IEEE 802.15.4 network interface after unregister an IEEE 802.15.4 hardware device from the system.

CPU0 CPU1 ==== ==== genlfamilyrcvmsgdoit ieee802154unregisterhw ieee802154deliface ieee802154removeinterfaces rdevdelvirtualintfdeprecated listdel(&sdata->list) ieee802154ifremove listdel_rcu

The net device has been unregistered, since the rcu grace period, unregistration must be run before ieee802154ifremove.

To avoid this issue, add a check for local->interfaces before deleting sdata list.

[1] kernel BUG at lib/listdebug.c:58! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 6277 Comm: syz-executor157 Not tainted 6.12.0-rc6-syzkaller-00005-g557329bcecc2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:listdelentryvalidorreport+0xf4/0x140 lib/listdebug.c:56 Code: e8 a1 7e 00 07 90 0f 0b 48 c7 c7 e0 37 60 8c 4c 89 fe e8 8f 7e 00 07 90 0f 0b 48 c7 c7 40 38 60 8c 4c 89 fe e8 7d 7e 00 07 90 <0f> 0b 48 c7 c7 a0 38 60 8c 4c 89 fe e8 6b 7e 00 07 90 0f 0b 48 c7 RSP: 0018:ffffc9000490f3d0 EFLAGS: 00010246 RAX: 000000000000004e RBX: dead000000000122 RCX: d211eee56bb28d00 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88805b278dd8 R08: ffffffff8174a12c R09: 1ffffffff2852f0d R10: dffffc0000000000 R11: fffffbfff2852f0e R12: dffffc0000000000 R13: dffffc0000000000 R14: dead000000000100 R15: ffff88805b278cc0 FS: 0000555572f94380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000056262e4a3000 CR3: 0000000078496000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> _listdelentryvalid include/linux/list.h:124 [inline] _listdelentry include/linux/list.h:215 [inline] listdelrcu include/linux/rculist.h:157 [inline] ieee802154ifremove+0x86/0x1e0 net/mac802154/iface.c:687 rdevdelvirtualintfdeprecated net/ieee802154/rdev-ops.h:24 [inline] ieee802154deliface+0x2c0/0x5c0 net/ieee802154/nl-phy.c:323 genlfamilyrcvmsgdoit net/netlink/genetlink.c:1115 [inline] genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0xb14/0xec0 net/netlink/genetlink.c:1210 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2551 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1331 [inline] netlinkunicast+0x7f6/0x990 net/netlink/afnetlink.c:1357 netlinksendmsg+0x8e4/0xcb0 net/netlink/afnetlink.c:1901 socksendmsgnosec net/socket.c:729 [inline] _socksendmsg+0x221/0x270 net/socket.c:744 syssendmsg+0x52a/0x7e0 net/socket.c:2607 _syssendmsg net/socket.c:2661 [inline] _syssendmsg+0x292/0x380 net/socket.c:2690 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f(CVE-2024-57948)

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Load DR6 with guest value only before entering .vcpu_run() loop

Move the conditional loading of hardware DR6 with the guest's DR6 value out of the core .vcpu_run() loop to fix a bug where KVM can load hardware with a stale vcpu->arch.dr6.

When the guest accesses a DR and host userspace isn't debugging the guest, KVM disables DR interception and loads the guest's values into hardware on VM-Enter and saves them on VM-Exit. This allows the guest to access DRs at will, e.g. so that a sequence of DR accesses to configure a breakpoint only generates one VM-Exit.

For DR0-DR3, the logic/behavior is identical between VMX and SVM, and also identical between KVMDEBUGREGBPENABLED (userspace debugging the guest) and KVMDEBUGREGWONTEXIT (guest using DRs), and so KVM handles loading DR0-DR3 in common code, outside of the core kvmx86ops.vcpu_run() loop.

But for DR6, the guest's value doesn't need to be loaded into hardware for KVMDEBUGREGBPENABLED, and SVM provides a dedicated VMCB field whereas VMX requires software to manually load the guest value, and so loading the guest's value into DR6 is handled by {svm,vmx}vcpurun(), i.e. is done _inside the core run loop.

Unfortunately, saving the guest values on VM-Exit is initiated by common x86, again outside of the core run loop. If the guest modifies DR6 (in hardware, when DR interception is disabled), and then the next VM-Exit is a fastpath VM-Exit, KVM will reload hardware DR6 with vcpu->arch.dr6 and clobber the guest's actual value.

The bug shows up primarily with nested VMX because KVM handles the VMX preemption timer in the fastpath, and the window between hardware DR6 being modified (in guest context) and DR6 being read by guest software is orders of magnitude larger in a nested setup. E.g. in non-nested, the VMX preemption timer would need to fire precisely between #DB injection and the #DB handler's read of DR6, whereas with a KVM-on-KVM setup, the window where hardware DR6 is "dirty" extends all the way from L1 writing DR6 to VMRESUME (in L1).

L1's view:
==========
<L1 disables DR interception>
       CPU 0/KVM-7289    [023] d....  2925.640961: kvm_entry: vcpu 0

A: L1 Writes DR6 CPU 0/KVM-7289 [023] d.... 2925.640963: <hack>: Set DRs, DR6 = 0xffff0ff1

B: CPU 0/KVM-7289 [023] d.... 2925.640967: kvmexit: vcpu 0 reason EXTERNALINTERRUPT intr_info 0x800000ec

D: L1 reads DR6, arch.dr6 = 0 CPU 0/KVM-7289 [023] d.... 2925.640969: <hack>: Sync DRs, DR6 = 0xffff0ff0

       CPU 0/KVM-7289    [023] d....  2925.640976: kvm_entry: vcpu 0
L2 reads DR6, L1 disables DR interception
       CPU 0/KVM-7289    [023] d....  2925.640980: kvm_exit: vcpu 0 reason DR_ACCESS info1 0x0000000000000216
       CPU 0/KVM-7289    [023] d....  2925.640983: kvm_entry: vcpu 0

       CPU 0/KVM-7289    [023] d....  2925.640983: <hack>: Set DRs, DR6 = 0xffff0ff0

L2 detects failure
       CPU 0/KVM-7289    [023] d....  2925.640987: kvm_exit: vcpu 0 reason HLT
L1 reads DR6 (confirms failure)
       CPU 0/KVM-7289    [023] d....  2925.640990: <hack>: Sync DRs, DR6 = 0xffff0ff0

L0's view:
==========
L2 reads DR6, arch.dr6 = 0
      CPU 23/KVM-5046    [001] d....  3410.005610: kvm_exit: vcpu 23 reason DR_ACCESS info1 0x0000000000000216
      CPU 23/KVM-5046    [001] .....  3410.005610: kvm_nested_vmexit: vcpu 23 reason DR_ACCESS info1 0x0000000000000216

L2 => L1 nested VM-Exit
      CPU 23/KVM-5046    [001] .....  3410.005610: kvm_nested_vmexit_inject: reason: DR_ACCESS ext_inf1: 0x0000000000000216

      CPU 23/KVM-5046    [001] d....  3410.005610: kvm_entry: vcpu 23
      CPU 23/KVM-5046    [001] d....  3410.005611: kvm_exit: vcpu 23 reason VMREAD
      CPU 23/KVM-5046    [001] d....  3410.005611: kvm_entry: vcpu 23
      CPU 23/KVM-5046    [001] d....  3410.

---truncated---(CVE-2025-21839)

In the Linux kernel, the following vulnerability has been resolved:

mm: memory-failure: update ttu flag inside unmappoisonedfolio

Patch series "mm: memory_failure: unmap poisoned folio during migrate properly", v3.

Fix two bugs during folio migration if the folio is poisoned.

This patch (of 3):

Commit 6da6b1d4a7df ("mm/hwpoison: convert TTUIGNOREHWPOISON to TTUHWPOISON") introduce TTUHWPOISON to replace TTUIGNOREHWPOISON in order to stop send SIGBUS signal when accessing an error page after a memory error on a clean folio. However during page migration, anon folio must be set with TTUHWPOISON during unmap*(). For pagecache we need some policy just like the one in hwpoisonusermappings to set this flag. So move this policy from hwpoisonusermappings to unmappoisonedfolio to handle this warning properly.

Warning will be produced during unamp poison folio with the following log:

------------[ cut here ]------------ WARNING: CPU: 1 PID: 365 at mm/rmap.c:1847 trytounmapone+0x8fc/0xd3c Modules linked in: CPU: 1 UID: 0 PID: 365 Comm: bash Tainted: G W 6.13.0-rc1-00018-gacdb4bbda7ab #42 Tainted: [W]=WARN Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : trytounmapone+0x8fc/0xd3c lr : trytounmapone+0x3dc/0xd3c Call trace: trytounmapone+0x8fc/0xd3c (P) trytounmapone+0x3dc/0xd3c (L) rmapwalkanon+0xdc/0x1f8 rmapwalk+0x3c/0x58 trytounmap+0x88/0x90 unmappoisonedfolio+0x30/0xa8 domigraterange+0x4a0/0x568 offlinepages+0x5a4/0x670 memoryblockaction+0x17c/0x374 memorysubsysoffline+0x3c/0x78 deviceoffline+0xa4/0xd0 statestore+0x8c/0xf0 devattrstore+0x18/0x2c sysfskfwrite+0x44/0x54 kernfsfopwriteiter+0x118/0x1a8 vfswrite+0x3a8/0x4bc ksyswrite+0x6c/0xf8 _arm64syswrite+0x1c/0x28 invokesyscall+0x44/0x100 el0svccommon.constprop.0+0x40/0xe0 doel0svc+0x1c/0x28 el0svc+0x30/0xd0 el0t64synchandler+0xc8/0xcc el0t64sync+0x198/0x19c ---[ end trace 0000000000000000 ]---

[(CVE-2025-21907)

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Assign normalizedpixclk when color depth = 14

[WHY & HOW] A warning message "WARNING: CPU: 4 PID: 459 at ... /dcresource.c:3397 calculatephypixclks+0xef/0x100 [amdgpu]" occurs because the displaycolordepth == COLORDEPTH141414 is not handled. This is observed in Radeon RX 6600 XT.

It is fixed by assigning pix_clk * (14 * 3) / 24 - same as the rests.

Also fixes the indentation in getnormpix_clk.

(cherry picked from commit 274a87eb389f58eddcbc5659ab0b180b37e92775)(CVE-2025-21956)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfconncount: Fully initialize struct nfconncounttuple in inserttree()

Since commit b36e4523d4d5 ("netfilter: nfconncount: fix garbage collection confirm race"), cpu and jiffies32 were introduced to the struct nfconncount_tuple.

The commit made nfconncountadd() initialize conn->cpu and conn->jiffies32 when allocating the struct. In contrast, count_tree() was not changed to initialize them.

By commit 34848d5c896e ("netfilter: nfconncount: Split insert and traversal"), counttree() was split and the relevant allocation code now resides in inserttree(). Initialize conn->cpu and conn->jiffies32 in inserttree().

BUG: KMSAN: uninit-value in findorevict net/netfilter/nfconncount.c:117 [inline] BUG: KMSAN: uninit-value in _nfconncountadd+0xd9c/0x2850 net/netfilter/nfconncount.c:143 findorevict net/netfilter/nfconncount.c:117 [inline] _nfconncountadd+0xd9c/0x2850 net/netfilter/nfconncount.c:143 counttree net/netfilter/nfconncount.c:438 [inline] nfconncountcount+0x82f/0x1e80 net/netfilter/nfconncount.c:521 connlimitmt+0x7f6/0xbd0 net/netfilter/xtconnlimit.c:72 _nftmatcheval net/netfilter/nftcompat.c:403 [inline] nftmatcheval+0x1a5/0x300 net/netfilter/nftcompat.c:433 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x426/0x2290 net/netfilter/nftablescore.c:288 nftdochainipv4+0x1a5/0x230 net/netfilter/nftchainfilter.c:23 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhookslowlist+0x24d/0x860 net/netfilter/core.c:663 NFHOOKLIST include/linux/netfilter.h:350 [inline] ipsublistrcv+0x17b7/0x17f0 net/ipv4/ipinput.c:633 iplistrcv+0x9ef/0xa40 net/ipv4/ipinput.c:669 _netifreceiveskblistptype net/core/dev.c:5936 [inline] _netifreceiveskblistcore+0x15c5/0x1670 net/core/dev.c:5983 _netifreceiveskblist net/core/dev.c:6035 [inline] netifreceiveskblistinternal+0x1085/0x1700 net/core/dev.c:6126 netifreceiveskblist+0x5a/0x460 net/core/dev.c:6178 xdprecvframes net/bpf/testrun.c:280 [inline] xdptestrunbatch net/bpf/testrun.c:361 [inline] bpftestrunxdplive+0x2e86/0x3480 net/bpf/testrun.c:390 bpfprogtestrunxdp+0xf1d/0x1ae0 net/bpf/testrun.c:1316 bpfprogtestrun+0x5e5/0xa30 kernel/bpf/syscall.c:4407 _sysbpf+0x6aa/0xd90 kernel/bpf/syscall.c:5813 _dosysbpf kernel/bpf/syscall.c:5902 [inline] _sesysbpf kernel/bpf/syscall.c:5900 [inline] _ia32sysbpf+0xa0/0xe0 kernel/bpf/syscall.c:5900 ia32syscall+0x394d/0x4180 arch/x86/include/generated/asm/syscalls32.h:358 dosyscall32irqson arch/x86/entry/common.c:165 [inline] _dofastsyscall32+0xb0/0x110 arch/x86/entry/common.c:387 dofastsyscall32+0x38/0x80 arch/x86/entry/common.c:412 doSYSENTER32+0x1f/0x30 arch/x86/entry/common.c:450 entrySYSENTERcompatafterhwframe+0x84/0x8e

Uninit was created at: slabpostallochook mm/slub.c:4121 [inline] slaballocnode mm/slub.c:4164 [inline] kmemcacheallocnoprof+0x915/0xe10 mm/slub.c:4171 inserttree net/netfilter/nfconncount.c:372 [inline] counttree net/netfilter/nfconncount.c:450 [inline] nfconncountcount+0x1415/0x1e80 net/netfilter/nfconncount.c:521 connlimitmt+0x7f6/0xbd0 net/netfilter/xtconnlimit.c:72 _nftmatcheval net/netfilter/nftcompat.c:403 [inline] nftmatcheval+0x1a5/0x300 net/netfilter/nftcompat.c:433 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x426/0x2290 net/netfilter/nftablescore.c:288 nftdochainipv4+0x1a5/0x230 net/netfilter/nftchainfilter.c:23 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhookslowlist+0x24d/0x860 net/netfilter/core.c:663 NFHOOKLIST include/linux/netfilter.h:350 [inline] ipsublistrcv+0x17b7/0x17f0 net/ipv4/ipinput.c:633 iplist_rcv+0x9ef/0xa40 net/ip ---truncated---(CVE-2025-21959)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix slab-use-after-free Read in l2capsendcmd

After the hci sync command releases l2capconn, the hci receive data work queue references the released l2capconn when sending to the upper layer. Add hci dev lock to the hci receive data work queue to synchronize the two.

[1] BUG: KASAN: slab-use-after-free in l2capsendcmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954 Read of size 8 at addr ffff8880271a4000 by task kworker/u9:2/5837

CPU: 0 UID: 0 PID: 5837 Comm: kworker/u9:2 Not tainted 6.13.0-rc5-syzkaller-00163-gab75170520d4 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: hci1 hcirxwork Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0x169/0x550 mm/kasan/report.c:489 kasanreport+0x143/0x180 mm/kasan/report.c:602 l2capbuildcmd net/bluetooth/l2capcore.c:2964 [inline] l2capsendcmd+0x187/0x8d0 net/bluetooth/l2capcore.c:954 l2capsigsendrej net/bluetooth/l2capcore.c:5502 [inline] l2capsigchannel net/bluetooth/l2capcore.c:5538 [inline] l2caprecvframe+0x221f/0x10db0 net/bluetooth/l2capcore.c:6817 hciacldatapacket net/bluetooth/hcicore.c:3797 [inline] hcirxwork+0x508/0xdb0 net/bluetooth/hcicore.c:4040 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xa66/0x1840 kernel/workqueue.c:3310 workerthread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>

Allocated by task 5837: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:377 [inline] _kasankmalloc+0x98/0xb0 mm/kasan/common.c:394 kasankmalloc include/linux/kasan.h:260 [inline] _kmalloccachenoprof+0x243/0x390 mm/slub.c:4329 kmallocnoprof include/linux/slab.h:901 [inline] kzallocnoprof include/linux/slab.h:1037 [inline] l2capconnadd+0xa9/0x8e0 net/bluetooth/l2capcore.c:6860 l2capconnectcfm+0x115/0x1090 net/bluetooth/l2capcore.c:7239 hciconnectcfm include/net/bluetooth/hcicore.h:2057 [inline] hciremotefeaturesevt+0x68e/0xac0 net/bluetooth/hcievent.c:3726 hcieventfunc net/bluetooth/hcievent.c:7473 [inline] hcieventpacket+0xac2/0x1540 net/bluetooth/hcievent.c:7525 hcirxwork+0x3f3/0xdb0 net/bluetooth/hcicore.c:4035 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xa66/0x1840 kernel/workqueue.c:3310 workerthread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Freed by task 54: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 kasansavefreeinfo+0x40/0x50 mm/kasan/generic.c:582 poisonslabobject mm/kasan/common.c:247 [inline] _kasanslabfree+0x59/0x70 mm/kasan/common.c:264 kasanslabfree include/linux/kasan.h:233 [inline] slabfreehook mm/slub.c:2353 [inline] slabfree mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 l2capconnectcfm+0xcc/0x1090 net/bluetooth/l2capcore.c:7235 hciconnectcfm include/net/bluetooth/hcicore.h:2057 [inline] hciconnfailed+0x287/0x400 net/bluetooth/hciconn.c:1266 hciabortconnsync+0x56c/0x11f0 net/bluetooth/hcisync.c:5603 hcicmdsyncwork+0x22b/0x400 net/bluetooth/hcisync.c:332 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xa66/0x1840 kernel/workqueue.c:3310 workerthread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entr ---truncated---(CVE-2025-21969)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btnxpuart: Fix kernel panic during FW release

This fixes a kernel panic seen during release FW in a stress test scenario where WLAN and BT FW download occurs simultaneously, and due to a HW bug, chip sends out only 1 bootloader signatures.

When driver receives the bootloader signature, it enters FW download mode, but since no consequtive bootloader signatures seen, FW file is not requested.

After 60 seconds, when FW download times out, release_firmware causes a kernel panic.

[ 2601.949184] Unable to handle kernel paging request at virtual address 0000312e6f006573 [ 2601.992076] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000111802000 [ 2601.992080] [0000312e6f006573] pgd=0000000000000000, p4d=0000000000000000 [ 2601.992087] Internal error: Oops: 0000000096000021 [#1] PREEMPT SMP [ 2601.992091] Modules linked in: algifhash algifskcipher afalg btnxpuart(O) pciexxx(O) mlan(O) overlay fsljruio caamjr caamkeyblobdesc caamhashdesc caamalgdesc cryptoengine authenc libdes crct10difce polyvalce sndsocfsleasrc sndsocfslasoccard imx8mediadev(C) sndsocfslmicfil polyvalgeneric sndsocfslxcvr sndsocfslsai sndsocimxaudmux sndsocfslasrc sndsocimxcard sndsocimxhdmi sndsocfslaud2htx sndsocfslutils imxpcmdma dwhdmicec flexcan candev [ 2602.001825] CPU: 2 PID: 20060 Comm: hciconfig Tainted: G C O 6.6.23-lts-next-06236-gb586a521770e #1 [ 2602.010182] Hardware name: NXP i.MX8MPlus EVK board (DT) [ 2602.010185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2602.010191] pc : rawspinlock+0x34/0x68 [ 2602.010201] lr : freefwpriv+0x20/0xfc [ 2602.020561] sp : ffff800089363b30 [ 2602.020563] x29: ffff800089363b30 x28: ffff0000d0eb5880 x27: 0000000000000000 [ 2602.020570] x26: 0000000000000000 x25: ffff0000d728b330 x24: 0000000000000000 [ 2602.020577] x23: ffff0000dc856f38 [ 2602.033797] x22: ffff800089363b70 x21: ffff0000dc856000 [ 2602.033802] x20: ff00312e6f006573 x19: ffff0000d0d9ea80 x18: 0000000000000000 [ 2602.033809] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaad80dd480 [ 2602.083320] x14: 0000000000000000 x13: 00000000000001b9 x12: 0000000000000002 [ 2602.083326] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff800089363a30 [ 2602.083333] x8 : ffff0001793d75c0 x7 : ffff0000d6dbc400 x6 : 0000000000000000 [ 2602.083339] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000001 [ 2602.083346] x2 : 0000000000000000 x1 : 0000000000000001 x0 : ff00312e6f006573 [ 2602.083354] Call trace: [ 2602.083356] _rawspinlock+0x34/0x68 [ 2602.083364] releasefirmware+0x48/0x6c [ 2602.083370] nxpsetup+0x3c4/0x540 [btnxpuart] [ 2602.083383] hcidevopensync+0xf0/0xa34 [ 2602.083391] hcidevopen+0xd8/0x178 [ 2602.083399] hcisockioctl+0x3b0/0x590 [ 2602.083405] sockdoioctl+0x60/0x118 [ 2602.083413] sockioctl+0x2f4/0x374 [ 2602.091430] _arm64sysioctl+0xac/0xf0 [ 2602.091437] invokesyscall+0x48/0x110 [ 2602.091445] el0svccommon.constprop.0+0xc0/0xe0 [ 2602.091452] doel0svc+0x1c/0x28 [ 2602.091457] el0svc+0x40/0xe4 [ 2602.091465] el0t64synchandler+0x120/0x12c [ 2602.091470] el0t64_sync+0x190/0x194(CVE-2025-22102)

In the Linux kernel, the following vulnerability has been resolved:

bonding: check xdp prog when set bond mode

Following operations can trigger a warning[1]:

ip netns add ns1
ip netns exec ns1 ip link add bond0 type bond mode balance-rr
ip netns exec ns1 ip link set dev bond0 xdp obj af_xdp_kern.o sec xdp
ip netns exec ns1 ip link set bond0 type bond mode broadcast
ip netns del ns1

When delete the namespace, devxdpuninstall() is called to remove xdp program on bond dev, and bondxdpset() will check the bond mode. If bond mode is changed after attaching xdp program, the warning may occur.

Some bond modes (broadcast, etc.) do not support native xdp. Set bond mode with xdp program attached is not good. Add check for xdp program when set bond mode.

[1]
------------[ cut here ]------------
WARNING: CPU: 0 PID: 11 at net/core/dev.c:9912 unregister_netdevice_many_notify+0x8d9/0x930
Modules linked in:
CPU: 0 UID: 0 PID: 11 Comm: kworker/u4:0 Not tainted 6.14.0-rc4 #107
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
Workqueue: netns cleanup_net
RIP: 0010:unregister_netdevice_many_notify+0x8d9/0x930
Code: 00 00 48 c7 c6 6f e3 a2 82 48 c7 c7 d0 b3 96 82 e8 9c 10 3e ...
RSP: 0018:ffffc90000063d80 EFLAGS: 00000282
RAX: 00000000ffffffa1 RBX: ffff888004959000 RCX: 00000000ffffdfff
RDX: 0000000000000000 RSI: 00000000ffffffea RDI: ffffc90000063b48
RBP: ffffc90000063e28 R08: ffffffff82d39b28 R09: 0000000000009ffb
R10: 0000000000000175 R11: ffffffff82d09b40 R12: ffff8880049598e8
R13: 0000000000000001 R14: dead000000000100 R15: ffffc90000045000
FS:  0000000000000000(0000) GS:ffff888007a00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000d406b60 CR3: 000000000483e000 CR4: 00000000000006f0
Call Trace:
 <TASK>
 ? __warn+0x83/0x130
 ? unregister_netdevice_many_notify+0x8d9/0x930
 ? report_bug+0x18e/0x1a0
 ? handle_bug+0x54/0x90
 ? exc_invalid_op+0x18/0x70
 ? asm_exc_invalid_op+0x1a/0x20
 ? unregister_netdevice_many_notify+0x8d9/0x930
 ? bond_net_exit_batch_rtnl+0x5c/0x90
 cleanup_net+0x237/0x3d0
 process_one_work+0x163/0x390
 worker_thread+0x293/0x3b0
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xec/0x1e0
 ? __pfx_kthread+0x10/0x10
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2f/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 </TASK>
---[ end trace 0000000000000000 ]---(CVE-2025-22105)

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: Prevent division by zero

The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37767)

In the Linux kernel, the following vulnerability has been resolved:

isofs: Prevent the use of too small fid

syzbot reported a slab-out-of-bounds Read in isofsfhto_parent. [1]

The handlebytes value passed in by the reproducing program is equal to 12. In handletopath(), only 12 bytes of memory are allocated for the structure filehandle->fhandle member, which causes an out-of-bounds access when accessing the member parentblock of the structure isofsfid in isofs, because accessing parentblock requires at least 16 bytes of fhandle. Here, fhlen is used to indirectly confirm that the value of handlebytes is greater than 3 before accessing parentblock.

[1] BUG: KASAN: slab-out-of-bounds in isofsfhtoparent+0x1b8/0x210 fs/isofs/export.c:183 Read of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466 CPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call trace: showstack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0xe4/0x150 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:408 [inline] printreport+0x198/0x550 mm/kasan/report.c:521 kasanreport+0xd8/0x138 mm/kasan/report.c:634 _asanreportload4noabort+0x20/0x2c mm/kasan/reportgeneric.c:380 isofsfhtoparent+0x1b8/0x210 fs/isofs/export.c:183 exportfsdecodefhraw+0x2dc/0x608 fs/exportfs/expfs.c:523 dohandletopath+0xa0/0x198 fs/fhandle.c:257 handletopath fs/fhandle.c:385 [inline] dohandleopen+0x8cc/0xb8c fs/fhandle.c:403 _dosysopenbyhandleat fs/fhandle.c:443 [inline] _sesysopenbyhandleat fs/fhandle.c:434 [inline] _arm64sysopenbyhandleat+0x80/0x94 fs/fhandle.c:434 _invokesyscall arch/arm64/kernel/syscall.c:35 [inline] invokesyscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0svccommon+0x130/0x23c arch/arm64/kernel/syscall.c:132 doel0svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t64synchandler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600

Allocated by task 6466: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x40/0x78 mm/kasan/common.c:68 kasansaveallocinfo+0x40/0x50 mm/kasan/generic.c:562 poisonkmallocredzone mm/kasan/common.c:377 [inline] _kasankmalloc+0xac/0xc4 mm/kasan/common.c:394 kasankmalloc include/linux/kasan.h:260 [inline] _dokmallocnode mm/slub.c:4294 [inline] _kmallocnoprof+0x32c/0x54c mm/slub.c:4306 kmallocnoprof include/linux/slab.h:905 [inline] handletopath fs/fhandle.c:357 [inline] dohandleopen+0x5a4/0xb8c fs/fhandle.c:403 _dosysopenbyhandleat fs/fhandle.c:443 [inline] _sesysopenbyhandleat fs/fhandle.c:434 [inline] _arm64sysopenbyhandleat+0x80/0x94 fs/fhandle.c:434 _invokesyscall arch/arm64/kernel/syscall.c:35 [inline] invokesyscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0svccommon+0x130/0x23c arch/arm64/kernel/syscall.c:132 doel0svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t64synchandler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600(CVE-2025-37780)

In the Linux kernel, the following vulnerability has been resolved:

spi: spi-imx: Add check for spiimxsetupxfer()

Add check for the return value of spiimxsetupxfer(). spiimx->rx and spiimx->tx function pointer can be NULL when spiimxsetupxfer() return error, and make NULL pointer dereference.

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: 0x0 spiimxpiotransfer+0x50/0xd8 spiimxtransferone+0x18c/0x858 spitransferonemessage+0x43c/0x790 _spipumptransfermessage+0x238/0x5d4 _spisync+0x2b0/0x454 spiwritethenread+0x11c/0x200(CVE-2025-37801)

In the Linux kernel, the following vulnerability has been resolved:

usb: xhci: Fix invalid pointer dereference in Etron workaround

This check is performed before preparetransfer() and preparering(), so enqueue can already point at the final link TRB of a segment. And indeed it will, some 0.4% of times this code is called.

Then enqueue + 1 is an invalid pointer. It will crash the kernel right away or load some junk which may look like a link TRB and cause the real link TRB to be replaced with a NOOP. This wouldn't end well.

Use a functionally equivalent test which doesn't dereference the pointer and always gives correct result.

Something has crashed my machine twice in recent days while playing with an Etron HC, and a control transfer stress test ran for confirmation has just crashed it again. The same test passes with this patch applied.(CVE-2025-37813)

In the Linux kernel, the following vulnerability has been resolved:

irqchip/gic-v2m: Prevent use after free of gicv2mgetfwnode()

With ACPI in place, gicv2mgetfwnode() is registered with the pci subsystem as pcimsigetfwnodecb(), which may get invoked at runtime during a PCI host bridge probe. But, the call back is wrongly marked as __init, causing it to be freed, while being registered with the PCI subsystem and could trigger:

Unable to handle kernel paging request at virtual address ffff8000816c0400 gicv2mgetfwnode+0x0/0x58 (P) pcisetbusmsidomain+0x74/0x88 pciregisterhost_bridge+0x194/0x548

This is easily reproducible on a Juno board with ACPI boot.

Retain the function for later use.(CVE-2025-37819)

In the Linux kernel, the following vulnerability has been resolved:

HID: pidff: Fix null pointer dereference in pidfffindfields

This function triggered a null pointer dereference if used to search for a report that isn't implemented on the device. This happened both for optional and required reports alike.

The same logic was applied to pidfffindspecialfield and although pidffinit_fields should return an error earlier if one of the required reports is missing, future modifications could change this logic and resurface this possible null pointer dereference again.

LKML bug report: https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com(CVE-2025-37862)

In the Linux kernel, the following vulnerability has been resolved:

net_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc

As described in Gerrard's report [1], we have a UAF case when an hfsc class has a netem child qdisc. The crux of the issue is that hfsc is assuming that checking for cl->qdisc->q.qlen == 0 guarantees that it hasn't inserted the class in the vttree or eltree (which is not true for the netem duplicate case).

This patch checks the n_active class variable to make sure that the code won't insert the class in the vttree or eltree twice, catering for the reentrant case.

[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37890)

In the Linux kernel, the following vulnerability has been resolved:

xsk: Fix race condition in AF_XDP generic RX path

Move rxlock from xsksocket to xskbuffpool. Fix synchronization for shared umem mode in generic RX path where multiple sockets share single xskbuffpool.

RX queue is exclusive to xsk_socket, while FILL queue can be shared between multiple sockets. This could result in race condition where two CPU cores access RX path of two different sockets sharing the same umem.

Protect both queues by acquiring spinlock in shared xskbuffpool.

Lock contention may be minimized in the future by some per-thread FQ buffering.

It's safe and necessary to move spinlockbh(rxlock) after xskrcvcheck(): * xs->pool and spinlockinit is synchronized by xskbind() -> xskisbound() memory barriers. * xskrcvcheck() may return true at the moment of xskrelease() or xskunbinddev(), however this will not cause any data races or race conditions. xskunbinddev() removes xdp socket from all maps and waits for completion of all outstanding rx operations. Packets in RX path will either complete safely or drop.(CVE-2025-37920)

In the Linux kernel, the following vulnerability has been resolved:

schhfsc: Fix qlen accounting bug when using peek in hfscenqueue()

When enqueuing the first packet to an HFSC class, hfscenqueue() calls the child qdisc's peek() operation before incrementing sch->q.qlen and sch->qstats.backlog. If the child qdisc uses qdiscpeekdequeued(), this may trigger an immediate dequeue and potential packet drop. In such cases, qdisctreereducebacklog() is called, but the HFSC qdisc's qlen and backlog have not yet been updated, leading to inconsistent queue accounting. This can leave an empty HFSC class in the active list, causing further consequences like use-after-free.

This patch fixes the bug by moving the increment of sch->q.qlen and sch->qstats.backlog before the call to the child qdisc's peek() operation. This ensures that queue length and backlog are always accurate when packet drops or dequeues are triggered during the peek.(CVE-2025-38000)

In the Linux kernel, the following vulnerability has been resolved:

net_sched: hfsc: Address reentrant enqueue adding class to eltree twice

Savino says: "We are writing to report that this recent patch (141d34391abbb315d68556b7c67ad97885407547) [1] can be bypassed, and a UAF can still occur when HFSC is utilized with NETEM.

The patch only checks the cl->cl_nactive field to determine whether
it is the first insertion or not [2], but this field is only
incremented by init_vf [3].

By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the
check and insert the class twice in the eltree.
Under normal conditions, this would lead to an infinite loop in
hfsc_dequeue for the reasons we already explained in this report [5].

However, if TBF is added as root qdisc and it is configured with a
very low rate,
it can be utilized to prevent packets from being dequeued.
This behavior can be exploited to perform subsequent insertions in the
HFSC eltree and cause a UAF."

To fix both the UAF and the infinite loop, with netem as an hfsc child, check explicitly in hfscenqueue whether the class is already in the eltree whenever the HFSCRSC flag is set.

[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547 [2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L1572 [3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L677 [4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L1574 [5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigReIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u(CVE-2025-38001)

In the Linux kernel, the following vulnerability has been resolved:

net: mctp: Don't access ifa_index when missing

In mctpdumpaddrinfo, ifa_index can be used to filter interfaces, but only when the struct ifaddrmsg is provided. Otherwise it will be comparing to uninitialised memory - reproducible in the syzkaller case from dhcpd, or busybox "ip addr show".

The kernel MCTP implementation has always filtered by ifaindex, so existing userspace programs expecting to dump MCTP addresses must already be passing a valid ifaindex value (either 0 or a real index).

BUG: KMSAN: uninit-value in mctpdumpaddrinfo+0x208/0xac0 net/mctp/device.c:128 mctpdumpaddrinfo+0x208/0xac0 net/mctp/device.c:128 rtnldumpall+0x3ec/0x5b0 net/core/rtnetlink.c:4380 rtnldumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824 netlinkdump+0x97b/0x1690 net/netlink/af_netlink.c:2309(CVE-2025-38006)

In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: disable napi on driver removal

A warning on driver removal started occurring after commit 9dd05df8403b ("net: warn if NAPI instance wasn't shut down"). Disable tx napi before deleting it in mt76dmacleanup().

WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 netifnapidellocked+0xf0/0x100 CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy) Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024 RIP: 0010:netifnapidellocked+0xf0/0x100 Call Trace: <TASK> mt76dmacleanup+0x54/0x2f0 [mt76] mt7921pciremove+0xd5/0x190 [mt7921e] pcideviceremove+0x47/0xc0 devicereleasedriverinternal+0x19e/0x200 driverdetach+0x48/0x90 busremovedriver+0x6d/0xf0 pciunregisterdriver+0x2e/0xb0 _dosysdeletemodule.isra.0+0x197/0x2e0 dosyscall64+0x7b/0x160 entrySYSCALL64afterhwframe+0x76/0x7e

Tested with mt7921e but the same pattern can be actually applied to other mt76 drivers calling mt76dmacleanup() during removal. Tx napi is enabled in their *dmainit() functions and only toggled off and on again inside their suspend/resume/reset paths. So it should be okay to disable tx napi in such a generic way.

Found by Linux Verification Center (linuxtesting.org).(CVE-2025-38009)

In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: Set nchannels after allocating struct cfg80211scan_request

Make sure that nchannels is set after allocating the struct cfg80211registereddevice::intscan_req member. Seen with syzkaller:

UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:1208:5 index 0 is out of range for type 'struct ieee80211channel *[] _countedby(nchannels)' (aka 'struct ieee80211_channel *[]')

This was missed in the initial conversions because I failed to locate the allocation likely due to the "sizeof(void *)" not matching the "channels" array type.(CVE-2025-38013)

In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: fix debug actions order

The order of actions taken for debug was implemented incorrectly. Now we implemented the dump split and do the FW reset only in the middle of the dump (rather than the FW killing itself on error.) As a result, some of the actions taken when applying the config will now crash the device, so we need to fix the order.(CVE-2025-38045)

In the Linux kernel, the following vulnerability has been resolved:

net/tipc: fix slab-use-after-free Read in tipcaeadencrypt_done

Syzbot reported a slab-use-after-free with the following call trace:

================================================================== BUG: KASAN: slab-use-after-free in tipcaeadencrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25

Call Trace: kasanreport+0xd9/0x110 mm/kasan/report.c:601 tipcaeadencryptdone+0x4bd/0x510 net/tipc/crypto.c:840 cryptorequestcomplete include/crypto/algapi.h:266 aeadrequestcomplete include/crypto/internal/aead.h:85 cryptdaeadcrypt+0x3b8/0x750 crypto/cryptd.c:772 cryptorequestcomplete include/crypto/algapi.h:266 cryptdqueueworker+0x131/0x200 crypto/cryptd.c:181 processonework+0x9fb/0x1b60 kernel/workqueue.c:3231

Allocated by task 8355: kzallocnoprof include/linux/slab.h:778 tipccryptostart+0xcc/0x9e0 net/tipc/crypto.c:1466 tipcinitnet+0x2dd/0x430 net/tipc/core.c:72 opsinit+0xb9/0x650 net/core/netnamespace.c:139 setupnet+0x435/0xb40 net/core/netnamespace.c:343 copynetns+0x2f0/0x670 net/core/netnamespace.c:508 createnewnamespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unsharensproxynamespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksysunshare+0x419/0x970 kernel/fork.c:3323 _dosysunshare kernel/fork.c:3394

Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipccryptostop+0x23c/0x500 net/tipc/crypto.c:1539 tipcexitnet+0x8c/0x110 net/tipc/core.c:119 opsexitlist+0xb0/0x180 net/core/netnamespace.c:173 cleanupnet+0x5b7/0xbf0 net/core/netnamespace.c:640 processone_work+0x9fb/0x1b60 kernel/workqueue.c:3231

After freed the tipccrypto tx by delete namespace, tipcaeadencryptdone may still visit it in cryptdqueueworker workqueue.

I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key thisisamasterkey master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1

The key of reproduction is that, simdaeadencrypt is interrupted, leading to cryptosimdusable() return false. Thus, the cryptdqueueworker is triggered, and the tipc_crypto tx will be visited.

tipcdisctimeout tipcbearerxmitskb tipccryptoxmit tipcaeadencrypt cryptoaeadencrypt // encrypt() simdaeadencrypt // cryptosimdusable() is false child = &ctx->cryptdtfm->base;

simdaeadencrypt cryptoaeadencrypt // encrypt() cryptdaeadencryptenqueue cryptdaeadenqueue cryptdenqueuerequest // trigger cryptdqueueworker queueworkon(smpprocessorid(), cryptdwq, &cpu_queue->work)

Fix this by holding net reference count before encrypt.(CVE-2025-38052)

In the Linux kernel, the following vulnerability has been resolved:

crypto: lzo - Fix compression buffer overrun

Unlike the decompression code, the compression code in LZO never checked for output overruns. It instead assumes that the caller always provides enough buffer space, disregarding the buffer length provided by the caller.

Add a safe compression interface that checks for the end of buffer before each write. Use the safe interface in crypto/lzo.(CVE-2025-38068)

In the Linux kernel, the following vulnerability has been resolved:

powerpc/powernv/memtrace: Fix out of bounds issue in memtrace mmap

memtrace mmap issue has an out of bounds issue. This patch fixes the by checking that the requested mapping region size should stay within the allocated region size.(CVE-2025-38088)

In the Linux kernel, the following vulnerability has been resolved:

sunrpc: handle SVC_GARBAGE during svc auth processing as auth error

tianshuo han reported a remotely-triggerable crash if the client sends a kernel RPC server a specially crafted packet. If decoding the RPC reply fails in such a way that SVCGARBAGE is returned without setting the rqaccept_statp pointer, then that pointer can be dereferenced and a value stored there.

If it's the first time the thread has processed an RPC, then that pointer will be set to NULL and the kernel will crash. In other cases, it could create a memory scribble.

The server sunrpc code treats a SVCGARBAGE return from svcauthenticate or pgauthenticate as if it should send a GARBAGEARGS reply. RFC 5531 says that if authentication fails that the RPC should be rejected instead with a status of AUTH_ERR.

Handle a SVCGARBAGE return as an AUTHERROR, with a reason of AUTHBADCRED instead of returning GARBAGEARGS in that case. This sidesteps the whole problem of touching the rpcacceptstatp pointer in this situation and avoids the crash.(CVE-2025-38089)

Linux kernel is the kernel used by Linux, the open source operating system of the Linux Foundation in the United States. There is a security vulnerability in Linux kernel, which originates from the TOCTOU problem with the skisreadable function, which may cause the null pointer to be dereferenced.(CVE-2025-38112)

A vulnerability, which was classified as critical, was found in Linux Kernel up to 6.15.1 (Operating System).CWE is classifying the issue as CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.This is going to have an impact on availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.33, 6.14.11, 6.15.2 or 6.16-rc1 eliminates this vulnerability. Applying the patch e49e994cd83705f7ca30eda1e304abddfd96a37a/0a3011d47dbc92a33621861c423cb64833d7fe57/2f62eda4d974c26bc595425eafd429067541f2c9/85286e634ebbaf9c0fb1cdf580add2f33fc7628c/5a057f261539720165d03d85024da2b52e67f63d/eb2d5e794fb966b3ef8bde99eb8561446a53509f/0771bcbe2f6e5d5f263cf466efe571d2754a46da/cdb4feab2f39e75a66239e3a112beced279612a8/0f73628e9da1ee39daf5f188190cdbaee5e0c98c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38174)

In the Linux kernel, the following vulnerability has been resolved:

tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer

The reproduction steps: 1. create a tun interface 2. enable l2 bearer 3. TIPCNLUDPGETREMOTEIP with media name set to tun

tipc: Started in network mode tipc: Node identity 8af312d38a21, cluster identity 4711 tipc: Enabled bearer <eth:syztun>, priority 1 Oops: general protection fault KASAN: null-ptr-deref in range CPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT Hardware name: QEMU Ubuntu 24.04 PC RIP: 0010:tipcudpnldump_remoteip+0x4a4/0x8f0

the ub was in fact a struct dev.

when bid != 0 && skipcnt != 0, bearerlist[bid] may be NULL or other media when other thread changes it.

fix this by checking media_id.(CVE-2025-38184)

A vulnerability classified as critical has been found in Linux Kernel up to 6.6.94/6.12.34/6.15.3/6.16-rc1 (Operating System).CWE is classifying the issue as CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.This is going to have an impact on availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc2 eliminates this vulnerability. Applying the patch bfa4d86e130a09f67607482e988313430e38f6c4/2a3ad42a57b43145839f2f233fb562247658a6d9/e9994e7b9f7bbb882d13c8191731649249150d21/ba9db6f907ac02215e30128770f85fbd7db2fcf9 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20064).(CVE-2025-38192)

In the Linux kernel, the following vulnerability has been resolved:

scsi: megaraid_sas: Fix invalid node index

On a system with DRAM interleave enabled, out-of-bound access is detected:

megaraidsas 0000:3f:00.0: requested/available msix 128/128 pollqueue 0 ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' dumpstacklvl+0x5d/0x80 ubsanepilogue+0x5/0x2b _ubsanhandleoutofbounds.cold+0x46/0x4b megasasallocirqvectors+0x149/0x190 [megaraidsas] megasasprobeone.cold+0xa4d/0x189c [megaraidsas] localpciprobe+0x42/0x90 pcideviceprobe+0xdc/0x290 reallyprobe+0xdb/0x340 _driverprobedevice+0x78/0x110 driverprobedevice+0x1f/0xa0 _driverattach+0xba/0x1c0 busforeachdev+0x8b/0xe0 busadddriver+0x142/0x220 driverregister+0x72/0xd0 megasasinit+0xdf/0xff0 [megaraidsas] dooneinitcall+0x57/0x310 doinitmodule+0x90/0x250 initmodulefromfile+0x85/0xc0 idempotentinitmodule+0x114/0x310 _x64sysfinitmodule+0x65/0xc0 dosyscall64+0x82/0x170 entrySYSCALL64afterhwframe+0x76/0x7e

Fix it accordingly.(CVE-2025-38239)

A vulnerability was found in Linux Kernel up to 6.15.4/6.16-rc3 (Operating System). It has been classified as critical.CWE is classifying the issue as CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.15.5 or 6.16-rc4 eliminates this vulnerability. Applying the patch f05a4f9e959e0fc098046044c650acf897ea52d2/7544f3f5b0b58c396f374d060898b5939da31709 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20813).(CVE-2025-38248)

A vulnerability, which was classified as problematic, has been found in Linux Kernel up to 5.15.185/6.1.141/6.6.93/6.12.33/6.15.2 (Operating System).Using CWE to declare the problem leads to CWE-824. The product accesses or uses a pointer that has not been initialized.Impacted is confidentiality, integrity, and availability.Upgrading to version 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 668923c474608dd9ebce0fbcc41bd8a27aa73dd6/cef33a86bcb04ecf4dc10c56f6c42ee9d1c54bac/d2507aeea45b3c5aa24d5daae0cf3db76895c0b7/d5d9fd13bc19a3f9f2a951c5b6e934d84205789e/cd4cd09810211fa23609c5c1018352e9e1cd8e5a/7632fedb266d93ed0ed9f487133e6c6314a9b2d1 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38310)

A vulnerability, which was classified as critical, was found in Linux Kernel up to 6.6.95/6.12.35/6.15.4 (Operating System).CWE is classifying the issue as CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.This is going to have an impact on availability.Upgrading to version 6.6.96, 6.12.36, 6.15.5 or 6.16-rc1 eliminates this vulnerability. Applying the patch e0051a3daa8b2cb318b03b2f9317c3e40855847a/98fd66c8ba77e3a7137575f610271014bc0e701f/aee7a7439f8c0884da87694a401930204a57128f/17502e7d7b7113346296f6758324798d536c31fd is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38369)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: flowtable: account for Ethernet header in nfflowpppoe_proto()

syzbot found a potential access to uninit-value in nfflowpppoe_proto()

Blamed commit forgot the Ethernet header.

BUG: KMSAN: uninit-value in nfflowoffloadinethook+0x7e4/0x940 net/netfilter/nfflowtableinet.c:27 nfflowoffloadinethook+0x7e4/0x940 net/netfilter/nfflowtableinet.c:27 nfhookentryhookfn include/linux/netfilter.h:157 [inline] nfhookslow+0xe1/0x3d0 net/netfilter/core.c:623 nfhookingress include/linux/netfilternetdev.h:34 [inline] nfingress net/core/dev.c:5742 [inline] _netifreceiveskbcore+0x4aff/0x70c0 net/core/dev.c:5837 _netifreceiveskbonecore net/core/dev.c:5975 [inline] _netifreceiveskb+0xcc/0xac0 net/core/dev.c:6090 netifreceiveskbinternal net/core/dev.c:6176 [inline] netifreceiveskb+0x57/0x630 net/core/dev.c:6235 tunrxbatched+0x1df/0x980 drivers/net/tun.c:1485 tungetuser+0x4ee0/0x6b40 drivers/net/tun.c:1938 tunchrwriteiter+0x3e9/0x5c0 drivers/net/tun.c:1984 newsyncwrite fs/readwrite.c:593 [inline] vfswrite+0xb4b/0x1580 fs/readwrite.c:686 ksyswrite fs/readwrite.c:738 [inline] _dosyswrite fs/readwrite.c:749 inline

In the Linux kernel, the following vulnerability has been resolved:

raid10: cleanup memleak at raid10makerequest

If raid10readrequest or raid10writerequest registers a new request and the REQ_NOWAIT flag is set, the code does not free the malloc from the mempool.

unreferenced object 0xffff8884802c3200 (size 192): comm "fio", pid 9197, jiffies 4298078271 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 88 41 02 00 00 00 00 00 .........A...... 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc c1a049a2): _kmalloc+0x2bb/0x450 mempoolalloc+0x11b/0x320 raid10makerequest+0x19e/0x650 [raid10] mdhandlerequest+0x3b3/0x9e0 _submitbio+0x394/0x560 _submitbionoacct+0x145/0x530 submitbionoacctnocheck+0x682/0x830 _blkdevdirectIOasync+0x4dc/0x6b0 blkdevreaditer+0x1e5/0x3b0 _ioread+0x230/0x1110 ioread+0x13/0x30 ioissuesqe+0x134/0x1180 iosubmitsqes+0x48c/0xe90 _dosysiouringenter+0x574/0x8b0 dosyscall64+0x5c/0xe0 entrySYSCALL64afterhwframe+0x76/0x7e

V4: changing backing tree to see if CKI tests will pass. The patch code has not changed between any versions.(CVE-2025-38444)

In the Linux kernel, the following vulnerability has been resolved:

md/raid1: Fix stack memory use after return in raid1_reshape

In the raid1reshape function, newpool is allocated on the stack and assigned to conf->r1biopool. This results in conf->r1bio_pool.wait.head pointing to a stack address. Accessing this address later can lead to a kernel panic.

Example access path:

raid1reshape() { // newpool is on the stack mempoolt newpool, oldpool; // initialize newpool.wait.head to stack address mempoolinit(&newpool, ...); conf->r1biopool = newpool; }

raid1readrequest() or raid1writerequest() { allocr1bio() { mempoolalloc() { // if pool->alloc fails removeelement() { --pool->currnr; } } } }

mempoolfree() { if (pool->currnr < pool->minnr) { // pool->wait.head is a stack address // wakeup() will try to access this invalid address // which leads to a kernel panic return; wake_up(&pool->wait); } }

Fix: reinit conf->r1bio_pool.wait after assigning newpool.(CVE-2025-38445)

In the Linux kernel, the following vulnerability has been resolved:

ipmi:msghandler: Fix potential memory corruption in ipmicreateuser()

The "intf" list iterator is an invalid pointer if the correct "intf->intfnum" is not found. Calling atomicdec(&intf->nr_users) on and invalid pointer will lead to memory corruption.

We don't really need to call atomicdec() if we haven't called atomicaddreturn() so update the if (intf->inshutdown) path as well.(CVE-2025-38456)

A vulnerability, which was classified as problematic, has been found in Linux Kernel up to 6.6.98/6.12.38/6.15.6/6.16-rc5 (Operating System).The manipulation of the argument involved with an unknown input leads to a unknown weakness. Using CWE to declare the problem leads to CWE-770. The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.Impacted is confidentiality, integrity, and availability.Upgrading to version 6.6.99, 6.12.39, 6.15.7 or 6.16-rc6 eliminates this vulnerability. Applying the patch 81373cd1d72d87c7d844d4454a526b8f53e72d00/62e6160cfb5514787bda833d466509edc38fde23/9f164fa6bb09fbcc60fa5c3ff551ce9eec1befd7/d3a5f2871adc0c61c61869f37f3e697d97f03d8c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38463)

In the Linux kernel, the following vulnerability has been resolved:

tipc: Fix use-after-free in tipcconnclose().

syzbot reported a null-ptr-deref in tipcconnclose() during netns dismantle. [0]

tipctopsrvstop() iterates tipcnet(net)->topsrv->connidr and calls tipcconnclose() for each tipc_conn.

The problem is that tipcconnclose() is called after releasing the IDR lock.

At the same time, there might be tipcconnrecvwork() running and it could call tipcconnclose() for the same tipcconn and release its last ->kref.

Once we release the IDR lock in tipctopsrvstop(), there is no guarantee that the tipc_conn is alive.

Let's hold the ref before releasing the lock and put the ref after tipcconnclose() in tipctopsrvstop().

Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435

CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanupnet Call Trace: _dumpstack lib/dumpstack.c:77 [inline] dumpstack+0x1fc/0x2ef lib/dumpstack.c:118 printaddressdescription.cold+0x54/0x219 mm/kasan/report.c:256 kasanreporterror.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasanreport mm/kasan/report.c:412 [inline] _asanreportload8noabort+0x88/0x90 mm/kasan/report.c:433 tipcconnclose+0x122/0x140 net/tipc/topsrv.c:165 tipctopsrvstop net/tipc/topsrv.c:701 [inline] tipctopsrvexitnet+0x27b/0x5c0 net/tipc/topsrv.c:722 opsexitlist+0xa5/0x150 net/core/netnamespace.c:153 cleanupnet+0x3b4/0x8b0 net/core/netnamespace.c:553 processonework+0x864/0x1570 kernel/workqueue.c:2153 workerthread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 retfromfork+0x24/0x30 arch/x86/entry/entry_64.S:415

Allocated by task 23: kmemcachealloctrace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipcconnalloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipctopsrvaccept+0x1b5/0x280 net/tipc/topsrv.c:470 processonework+0x864/0x1570 kernel/workqueue.c:2153 workerthread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 retfromfork+0x24/0x30 arch/x86/entry/entry_64.S:415

Freed by task 23: _cachefree mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipcconnkrefrelease net/tipc/topsrv.c:150 [inline] krefput include/linux/kref.h:70 [inline] connput+0x2cd/0x3a0 net/tipc/topsrv.c:155 processonework+0x864/0x1570 kernel/workqueue.c:2153 workerthread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 retfromfork+0x24/0x30 arch/x86/entry/entry_64.S:415

The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00) The buggy address belongs to the page: page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0 flags: 0xfff00000000100(slab) raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940 raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb(CVE-2025-38464)

A vulnerability was found in Linux Kernel up to 6.16-rc5 (Operating System). It has been classified as problematic.CWE is classifying the issue as CWE-345. The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 5.4.296, 5.10.240, 5.15.189, 6.1.146, 6.6.99, 6.12.39, 6.15.7 or 6.16-rc6 eliminates this vulnerability. Applying the patch 9da025150b7c14a8390fc06aea314c0a4011e82c/c4ceaac5c5ba0b992ee1dc88e2a02421549e5c98/fd69af06101090eaa60b3d216ae715f9c0a58e5b/76602d8e13864524382b0687dc32cd8f19164d5a/55baecb9eb90238f60a8350660d6762046ebd3bd/4b8e18af7bea92f8b7fb92d40aeae729209db250/cd7ff61bfffd7000143c42bbffb85eeb792466d6/ae8f160e7eb24240a2a79fc4c815c6a0d4ee16cc is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38465)

A vulnerability was found in Linux Kernel up to 6.15.6 (Operating System). It has been rated as critical.Using CWE to declare the problem leads to CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.Impacted is availability.Upgrading to version 5.4.296, 5.10.240, 5.15.189, 6.1.146, 6.6.99, 6.12.39 or 6.15.7 eliminates this vulnerability. Applying the patch 549a9c78c3ea6807d0dc4162a4f5ba59f217d5a0/e62f51d0ec8a9baf324caf9a564f8e318d36a551/ef841f8e4e1ff67817ca899bedc5ebb00847c0a7/f9a4f28a4fc4ee453a92a9abbe36e26224d17749/c64f5310530baf75328292f9b9f3f2961d185183/e2d6547dc8b9b332f9bc00875197287a6a4db65a/ef58a95457466849fa7b31fd3953801a5af0f58b/8af39ec5cf2be522c8eb43a3d8005ed59e4daaee is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38515)

A vulnerability was found in Linux Kernel up to 6.6.99/6.12.39/6.15.7 (Operating System). It has been classified as critical.CWE is classifying the issue as CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.This is going to have an impact on availability.Upgrading to version 6.6.100, 6.12.40 or 6.15.8 eliminates this vulnerability. Applying the patch 27591d926191e42b2332e4bad3bcd3a49def393b/5a5d64f0eec82076b2c09fee2195d640cfbe3379/245917d3c5ed7c6ae720302b64eac5c6f0c85177/3ce58b01ada408b372f15b7c992ed0519840e3cf is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38526)

In the Linux kernel, the following vulnerability has been resolved:

tracing: Add downwrite(traceevent_sem) when adding trace event

When a module is loaded, it adds trace events defined by the module. It may also need to modify the modules trace printk formats to replace enum names with their values.

If two modules are loaded at the same time, the adding of the event to the ftrace_events list can corrupt the walking of the list in the code that is modifying the printk format strings and crash the kernel.

The addition of the event should take the traceeventsem for write while it adds the new event.

Also add a lockdepassertheld() on that semaphore in _traceaddeventdirs() as it iterates the list.(CVE-2025-38539)

In the Linux kernel, the following vulnerability has been resolved:

perf/core: Exit early on perf_mmap() fail

When perfmmap() fails to allocate a buffer, it still invokes the eventmapped() callback of the related event. On X86 this might increase the perfrdpmcallowed reference counter. But nothing undoes this as perfmmapclose() is never called in this case, which causes another reference count leak.

Return early on failure to prevent that.(CVE-2025-38565)

A vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.6.100/6.12.40/6.15.8 (Operating System).Using CWE to declare the problem leads to CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.Impacted is availability.Upgrading to version 6.6.101, 6.12.41 or 6.15.9 eliminates this vulnerability. Applying the patch 9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61/708fd522b86d2a9544c34ec6a86fa3fc23336525/0f67015d72627bad72da3c2084352e0aa134416b/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38670)