The Linux Kernel, the operating system core itself.

Security Fix(es):

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:

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:

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)