The Linux Kernel, the operating system core itself.

Security Fix(es):

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

powerpc/kprobes: Fix null pointer reference in archpreparekprobe()

I found a null pointer reference in archpreparekprobe():

# echo 'p cmdlineprocshow' > kprobeevents # echo 'p cmdlineprocshow+16' >> kprobeevents Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc000000000050bfc Oops: Kernel access of bad area, sig: 11 [#1] LE PAGESIZE=64K MMU=Radix SMP NRCPUS=2048 NUMA PowerNV Modules linked in: CPU: 0 PID: 122 Comm: sh Not tainted 6.0.0-rc3-00007-gdcf8e5633e2e #10 NIP: c000000000050bfc LR: c000000000050bec CTR: 0000000000005bdc REGS: c0000000348475b0 TRAP: 0300 Not tainted (6.0.0-rc3-00007-gdcf8e5633e2e) MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 88002444 XER: 20040006 CFAR: c00000000022d100 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0 ... NIP archpreparekprobe+0x10c/0x2d0 LR archpreparekprobe+0xfc/0x2d0 Call Trace: 0xc0000000012f77a0 (unreliable) registerkprobe+0x3c0/0x7a0 _registertracekprobe+0x140/0x1a0 _tracekprobecreate+0x794/0x1040 traceprobecreate+0xc4/0xe0 createordeletetracekprobe+0x2c/0x80 traceparseruncommand+0xf0/0x210 probeswrite+0x20/0x40 vfswrite+0xfc/0x450 ksyswrite+0x84/0x140 systemcallexception+0x17c/0x3a0 systemcallvectoredcommon+0xe8/0x278 --- interrupt: 3000 at 0x7fffa5682de0 NIP: 00007fffa5682de0 LR: 0000000000000000 CTR: 0000000000000000 REGS: c000000034847e80 TRAP: 3000 Not tainted (6.0.0-rc3-00007-gdcf8e5633e2e) MSR: 900000000280f033 <SF,HV,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 44002408 XER: 00000000

The address being probed has some special:

cmdlineprocshow: Probe based on ftrace cmdlineprocshow+16: Probe for the next instruction at the ftrace location

The ftrace-based kprobe does not generate kprobe::ainsn::insn, it gets set to NULL. In archpreparekprobe() it will check for:

... prev = getkprobe(p->addr - 1); preemptenablenoresched(); if (prev && ppcinstprefixed(ppcinstread(prev->ainsn.insn))) { ...

If prev is based on ftrace, 'ppcinstread(prev->ainsn.insn)' will occur with a null pointer reference. At this point prev->addr will not be a prefixed instruction, so the check can be skipped.

Check if prev is ftrace-based kprobe before reading 'prev->ainsn.insn' to fix this problem.

mpe: Trim oops

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

erofs: validate the extent length for uncompressed pclusters

syzkaller reported a KASAN use-after-free: https://syzkaller.appspot.com/bug?extid=2ae90e873e97f1faf6f2

The referenced fuzzed image actually has two issues: - m_pa == 0 as a non-inlined pcluster; - The logical length is longer than its physical length.

The first issue has already been addressed. This patch addresses the second issue by checking the extent length validity.(CVE-2022-50746)

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

smc: Fix use-after-free in tcpwritetimer_handler().

With Eric's ref tracker, syzbot finally found a repro for use-after-free in tcpwritetimer_handler() by kernel TCP sockets. [0]

If SMC creates a kernel socket in _smccreate(), the kernel socket is supposed to be freed in smcclcsockrelease() by calling sock_release() when we close() the parent SMC socket.

However, at the end of smcclcsockrelease(), the kernel socket's skstate might not be TCPCLOSE. This means that we have not called inetcskdestroysock() in _tcp_close() and have not stopped the TCP timers.

The kernel socket's TCP timers can be fired later, so we need to hold a refcnt for net as we do for MPTCP subflows in mptcpsubflowcreate_socket().

skalloc (./include/net/netnamespace.h:335 net/core/sock.c:2108) inetcreate (net/ipv4/afinet.c:319 net/ipv4/afinet.c:244) _sockcreate (net/socket.c:1546) smccreate (net/smc/afsmc.c:3269 net/smc/afsmc.c:3284) _sockcreate (net/socket.c:1546) _syssocket (net/socket.c:1634 net/socket.c:1618 net/socket.c:1661) _x64syssocket (net/socket.c:1672) dosyscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)

entrySYSCALL64afterhwframe (arch/x86/entry/entry_64.S:120)

BUG: KASAN: slab-use-after-free in tcpwritetimerhandler (net/ipv4/tcptimer.c:378 net/ipv4/tcptimer.c:624 net/ipv4/tcptimer.c:594) Read of size 1 at addr ffff888052b65e0d by task syzrepro/18091

CPU: 0 PID: 18091 Comm: syzrepro Tainted: G W 6.3.0-rc4-01174-gb5d54eb5899a #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.amzn2022.0.1 04/01/2014 Call Trace: <IRQ> dumpstacklvl (lib/dumpstack.c:107) printreport (mm/kasan/report.c:320 mm/kasan/report.c:430) kasanreport (mm/kasan/report.c:538) tcpwritetimerhandler (net/ipv4/tcptimer.c:378 net/ipv4/tcptimer.c:624 net/ipv4/tcptimer.c:594) tcpwritetimer (./include/linux/spinlock.h:390 net/ipv4/tcptimer.c:643) calltimerfn (./arch/x86/include/asm/jumplabel.h:27 ./include/linux/jumplabel.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701) _runtimers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2022) runtimersoftirq (kernel/time/timer.c:2037) _dosoftirq (./arch/x86/include/asm/jumplabel.h:27 ./include/linux/jumplabel.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:572) _irqexitrcu (kernel/softirq.c:445 kernel/softirq.c:650) irqexitrcu (kernel/softirq.c:664) sysvecapictimerinterrupt (arch/x86/kernel/apic/apic.c:1107 (discriminator 14)) </IRQ>(CVE-2023-53781)

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

ip6vti: fix slab-use-after-free in decodesession6

When ipv6vti device is set to the qdisc of the sfb type, the cb field of the sent skb may be modified during enqueuing. Then, slab-use-after-free may occur when ipv6vti device sends IPv6 packets.

The stack information is as follows: BUG: KASAN: slab-use-after-free in decodesession6+0x103f/0x1890 Read of size 1 at addr ffff88802e08edc2 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.0-next-20230707-00001-g84e2cad7f979 #410 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <IRQ> dumpstacklvl+0xd9/0x150 printaddressdescription.constprop.0+0x2c/0x3c0 kasanreport+0x11d/0x130 decodesession6+0x103f/0x1890 xfrmdecodesession+0x54/0xb0 vti6tnlxmit+0x3e6/0x1ee0 devhardstartxmit+0x187/0x700 schdirectxmit+0x1a3/0xc30 _qdiscrun+0x510/0x17a0 _devqueuexmit+0x2215/0x3b10 neighconnectedoutput+0x3c2/0x550 ip6finishoutput2+0x55a/0x1550 ip6finishoutput+0x6b9/0x1270 ip6output+0x1f1/0x540 ndiscsendskb+0xa63/0x1890 ndiscsendrs+0x132/0x6f0 addrconfrstimer+0x3f1/0x870 calltimerfn+0x1a0/0x580 expiretimers+0x29b/0x4b0 runtimersoftirq+0x326/0x910 _dosoftirq+0x1d4/0x905 irqexitrcu+0xb7/0x120 sysvecapictimerinterrupt+0x97/0xc0 </IRQ> Allocated by task 9176: kasansavestack+0x22/0x40 kasansettrack+0x25/0x30 _kasanslaballoc+0x7f/0x90 kmemcacheallocnode+0x1cd/0x410 kmallocreserve+0x165/0x270 _allocskb+0x129/0x330 netlinksendmsg+0x9b1/0xe30 socksendmsg+0xde/0x190 _syssendmsg+0x739/0x920 syssendmsg+0x110/0x1b0 _syssendmsg+0xf7/0x1c0 dosyscall64+0x39/0xb0 entrySYSCALL64afterhwframe+0x63/0xcd Freed by task 9176: kasansavestack+0x22/0x40 kasansettrack+0x25/0x30 kasansavefreeinfo+0x2b/0x40 kasanslabfree+0x160/0x1c0 slabfreefreelisthook+0x11b/0x220 kmemcachefree+0xf0/0x490 skbfreehead+0x17f/0x1b0 skbreleasedata+0x59c/0x850 consumeskb+0xd2/0x170 netlinkunicast+0x54f/0x7f0 netlinksendmsg+0x926/0xe30 socksendmsg+0xde/0x190 syssendmsg+0x739/0x920 syssendmsg+0x110/0x1b0 _syssendmsg+0xf7/0x1c0 dosyscall64+0x39/0xb0 entrySYSCALL64afterhwframe+0x63/0xcd The buggy address belongs to the object at ffff88802e08ed00 which belongs to the cache skbuffsmallhead of size 640 The buggy address is located 194 bytes inside of freed 640-byte region [ffff88802e08ed00, ffff88802e08ef80)

As commit f855691975bb ("xfrm6: Fix the nexthdr offset in decodesession6.") showed, xfrmdecodesession was originally intended only for the receive path. IP6CB(skb)->nhoff is not set during transmission. Therefore, set the cb field in the skb to 0 before sending packets.(CVE-2023-53821)

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

f2fs: fix to do sanity check on direct node in truncate_dnode()

syzbot reports below bug:

BUG: KASAN: slab-use-after-free in f2fstruncatedatablocksrange+0x122a/0x14c0 fs/f2fs/file.c:574 Read of size 4 at addr ffff88802a25c000 by task syz-executor148/5000

CPU: 1 PID: 5000 Comm: syz-executor148 Not tainted 6.4.0-rc7-syzkaller-00041-ge660abd551f1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xd9/0x150 lib/dumpstack.c:106 printaddressdescription.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 printreport mm/kasan/report.c:462 [inline] kasanreport+0x11c/0x130 mm/kasan/report.c:572 f2fstruncatedatablocksrange+0x122a/0x14c0 fs/f2fs/file.c:574 truncatednode+0x229/0x2e0 fs/f2fs/node.c:944 f2fstruncateinodeblocks+0x64b/0xde0 fs/f2fs/node.c:1154 f2fsdotruncateblocks+0x4ac/0xf30 fs/f2fs/file.c:721 f2fstruncateblocks+0x7b/0x300 fs/f2fs/file.c:749 f2fstruncate.part.0+0x4a5/0x630 fs/f2fs/file.c:799 f2fstruncate include/linux/fs.h:825 [inline] f2fssetattr+0x1738/0x2090 fs/f2fs/file.c:1006 notifychange+0xb2c/0x1180 fs/attr.c:483 dotruncate+0x143/0x200 fs/open.c:66 handletruncate fs/namei.c:3295 [inline] doopen fs/namei.c:3640 [inline] pathopenat+0x2083/0x2750 fs/namei.c:3791 dofilpopen+0x1ba/0x410 fs/namei.c:3818 dosysopenat2+0x16d/0x4c0 fs/open.c:1356 dosysopen fs/open.c:1372 [inline] _dosyscreat fs/open.c:1448 [inline] _sesyscreat fs/open.c:1442 [inline] _x64syscreat+0xcd/0x120 fs/open.c:1442 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x39/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

The root cause is, inodeA references inodeB via inodeB's ino, once inodeA is truncated, it calls truncatednode() to truncate data blocks in inodeB's node page, it traverse mapping data from node->i.iaddr[0] to node->i.iaddr[ADDRSPER_BLOCK() - 1], result in out-of-boundary access.

This patch fixes to add sanity check on dnode page in truncatednode(), so that, it can help to avoid triggering such issue, and once it encounters such issue, it will record newly introduced ERRORINVALIDNODEREFERENCE error into superblock, later fsck can detect such issue and try repairing.

Also, it removes f2fstruncatedatablocks() for cleanup due to the function has only one caller, and uses f2fstruncatedatablocks_range() instead.(CVE-2023-53846)

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

ext4: correct grp validation in ext4mbgood_group

Group corruption check will access memory of grp and will trigger kernel crash if grp is NULL. So do NULL check before corruption check.(CVE-2023-53861)

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

qed: Don't collect too many protection override GRC elements

In the protection override dump path, the firmware can return far too many GRC elements, resulting in attempting to write past the end of the previously-kmalloc'ed dump buffer.

This will result in a kernel panic with reason:

BUG: unable to handle kernel paging request at ADDRESS

where "ADDRESS" is just past the end of the protection override dump buffer. The start address of the buffer is: phwfn->cdev->dbgfeatures[DBGFEATUREPROTECTIONOVERRIDE].dumpbuf and the size of the buffer is buf_size in the same data structure.

The panic can be arrived at from either the qede Ethernet driver path:

[exception RIP: qed_grc_dump_addr_range+0x108]

qedprotectionoverridedump at ffffffffc02662ed [qed] qeddbgprotectionoverridedump at ffffffffc0267792 [qed] qeddbgfeature at ffffffffc026aa8f [qed] qeddbgalldata at ffffffffc026b211 [qed] qedfwfatalreporterdump at ffffffffc027298a [qed] devlinkhealthdodump at ffffffff82497f61 devlinkhealthreport at ffffffff8249cf29 qedreportfatalerror at ffffffffc0272baf [qed] qedesptask at ffffffffc045ed32 [qede] processonework at ffffffff81d19783

or the qedf storage driver path:

[exception RIP: qed_grc_dump_addr_range+0x108]

qedprotectionoverridedump at ffffffffc068b2ed [qed] qeddbgprotectionoverridedump at ffffffffc068c792 [qed] qeddbgfeature at ffffffffc068fa8f [qed] qeddbgalldata at ffffffffc0690211 [qed] qedfwfatalreporterdump at ffffffffc069798a [qed] devlinkhealthdodump at ffffffff8aa95e51 devlinkhealthreport at ffffffff8aa9ae19 qedreportfatalerror at ffffffffc0697baf [qed] qedhwerrnotify at ffffffffc06d32d7 [qed] qedspqpost at ffffffffc06b1011 [qed] qedfcoedestroyconn at ffffffffc06b2e91 [qed] qedfcleanupfcport at ffffffffc05e7597 [qedf] qedfrporteventhandler at ffffffffc05e7bf7 [qedf] fcrportwork at ffffffffc02da715 [libfc] processone_work at ffffffff8a319663

Resolve this by clamping the firmware's return value to the maximum number of legal elements the firmware should return.(CVE-2025-39949)

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

i40e: fix validation of VF state in get resources

VF state I40EVFSTATE_ACTIVE is not the only state in which VF is actually active so it should not be used to determine if a VF is allowed to obtain resources.

Use I40EVFSTATERESOURCESLOADED that is set only in i40evcgetvfresources_msg() and cleared during reset.(CVE-2025-39969)

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

i40e: fix input validation logic for action_meta

Fix condition to check 'greater or equal' to prevent OOB dereference.(CVE-2025-39970)

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

Squashfs: reject negative file sizes in squashfsreadinode()

Syskaller reports a "WARNING in ovlcopyup_file" in overlayfs.

This warning is ultimately caused because the underlying Squashfs file system returns a file with a negative file size.

This commit checks for a negative file size and returns EINVAL.

[(CVE-2025-40200)

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

x86/fpu: Ensure XFD state on signal delivery

Sean reported [1] the following splat when running KVM tests:

WARNING: CPU: 232 PID: 15391 at xfdvalidatestate+0x65/0x70 Call Trace: <TASK> fpu_clearuserstates+0x9c/0x100 archdosignalorrestart+0x142/0x210 exittousermodeloop+0x55/0x100 dosyscall64+0x205/0x2c0 entrySYSCALL64after_hwframe+0x4b/0x53

Chao further identified [2] a reproducible scenario involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR.

When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu_clearuser_states() does not currently re-synchronize the XFD state after such preemption.

Invoke xfdupdatestate() which detects and corrects the mismatch if there is a dynamic feature.

This also benefits the sigreturn path, as fpurestoresig() may call fpuclearuser_states() when the sigframe is inaccessible.

dhansen: minor changelog munging

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

isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()

In hfcsusbprobe(), the memory allocated for ctrlurb gets leaked when setup_instance() fails with an error code. Fix that by freeing the urb before freeing the hw structure. Also change the error paths to use the goto ladder style.

Compile tested only. Issue found using a prototype static analysis tool.(CVE-2025-68734)

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

scsi: qla2xxx: Clear cmds after chip reset

Commit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handling and host reset handling") caused two problems:

1. Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.

2. BUGON(cmd->sgmapped) in qltfreecmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qltunmapsg() at the same time: BUGON(!validdmadirection(dir)) in dmaunmapsgattrs().

So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" and partially revert "scsi: qla2xxx: target: Fix offline port handling and host reset handling" at _qla2x00abortallcmds.(CVE-2025-68745)