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

spi: ep93xx: fix error pointer deref after DMA setup failure

The driver falls back to PIO mode if DMA setup fails during probe.

Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer on later probe errors or driver unbind.

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.

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

usb: gadget: fncm: validate minimum blocklen in ncmunwrapntb()

The blocklen read from the host-supplied NTB header is checked against ntbmax but has no lower bound. When blocklen is smaller than opts->ndpsize, the bounds check of: ndpindex > (blocklen - opts->ndpsize) will underflow producing a huge unsigned value that ndpindex can never exceed, defeating the check entirely.

The same underflow occurs in the datagram index checks against blocklen - opts->dpesize. With those checks neutered, a malicious USB host can choose ndpindex and datagram offsets that point past the actual transfer, and the skbputdata() copies adjacent kernel memory into the network skb.

Fix this by rejecting block lengths that cannot hold at least the NTB header plus one NDP. This will make blocklen - opts->ndpsize and blocklen - opts->dpesize both well-defined.

Commit 8d2b1a1ec9f5 ("CDC-NCM: avoid overflow in sanity checking") fixed a related class of issues on the host side of NCM.

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

RDMA/mlx5: Fix pagesize variable overflow

Change all variables storing mlx5umemmkcfindbestpgsz() result to unsigned long to support values larger than 31 and avoid overflow.

For example: If we try to register 4GB of memory that is contiguous in physical memory, the driver will optimize the pagesize and try to use an mkey with 4GB entity size. The 'unsigned int' pagesize variable will overflow to '0' and we'll hit the WARNON() in alloccacheablemr().

WARNING: CPU: 2 PID: 1203 at drivers/infiniband/hw/mlx5/mr.c:1124 alloccacheablemr+0x22/0x580 [mlx5ib] Modules linked in: mlx5ib mlx5core bonding ip6gre ip6tunnel tunnel6 ipgre gre rdmarxe rdmaucm ibuverbs ibipoib ibumad rpcrdma ibiser libiscsi scsitransportiscsi rdmacm iwcm ibcm fuse ibcore [last unloaded: mlx5core] CPU: 2 UID: 70878 PID: 1203 Comm: rdmaresourcel Tainted: G W 6.14.0-rc4-dirty #43 Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:alloccacheablemr+0x22/0x580 [mlx5ib] Code: 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 41 52 53 48 83 ec 30 f6 46 28 04 4c 8b 77 08 75 21 <0f> 0b 49 c7 c2 ea ff ff ff 48 8d 65 d0 4c 89 d0 5b 41 5a 41 5c 41 RSP: 0018:ffffc900006ffac8 EFLAGS: 00010246 RAX: 0000000004c0d0d0 RBX: ffff888217a22000 RCX: 0000000000100001 RDX: 00007fb7ac480000 RSI: ffff8882037b1240 RDI: ffff8882046f0600 RBP: ffffc900006ffb28 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000007e0 R11: ffffea0008011d40 R12: ffff8882037b1240 R13: ffff8882046f0600 R14: ffff888217a22000 R15: ffffc900006ffe00 FS: 00007fb7ed013340(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb7ed1d8000 CR3: 00000001fd8f6006 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? warn+0x81/0x130 ? alloccacheablemr+0x22/0x580 [mlx5ib] ? reportbug+0xfc/0x1e0 ? handlebug+0x55/0x90 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? alloccacheablemr+0x22/0x580 [mlx5ib] createrealmr+0x54/0x150 [mlx5ib] ibuverbsregmr+0x17f/0x2a0 [ibuverbs] ibuverbshandlerUVERBSMETHODINVOKEWRITE+0xca/0x140 [ibuverbs] ibuverbsrunmethod+0x6d0/0x780 [ibuverbs] ? pfxibuverbshandlerUVERBSMETHODINVOKEWRITE+0x10/0x10 [ibuverbs] ibuverbscmdverbs+0x19b/0x360 [ibuverbs] ? walksystemramrange+0x79/0xd0 ? pteoffsetmap+0x1b/0x110 ? pteoffsetmaplock+0x80/0x100 ibuverbsioctl+0xac/0x110 [ibuverbs] x64sysioctl+0x94/0xb0 dosyscall64+0x50/0x110 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7fb7ecf0737b Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 7d 2a 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffdbe03ecc8 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffdbe03edb8 RCX: 00007fb7ecf0737b RDX: 00007ffdbe03eda0 RSI: 00000000c0181b01 RDI: 0000000000000003 RBP: 00007ffdbe03ed80 R08: 00007fb7ecc84010 R09: 00007ffdbe03eed4 R10: 0000000000000009 R11: 0000000000000246 R12: 00007ffdbe03eed4 R13: 000000000000000c R14: 000000000000000c R15: 00007fb7ecc84150 </TASK>

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

lib/buildid: use kernelread() for sleepable context

Prevent a "BUG: unable to handle kernel NULL pointer dereference in filemapreadfolio".

For the sleepable context, convert freader to use kernelread() instead of direct page cache access via readcachefolio(). This simplifies the faultable code path by using the standard kernel file reading interface which handles all the complexity of reading file data.

At the moment we are not changing the code for non-sleepable context which uses filemapgetfolio() and only succeeds if the target folios are already in memory and up-to-date. The reason is to keep the patch simple and easier to backport to stable kernels.

Syzbot repro does not crash the kernel anymore and the selftests run successfully.

In the follow up we will make kernelread() with IOCBNOWAIT work for non-sleepable contexts. In addition, I would like to replace the secretmem check with a more generic approach and will add fstest for the buildid code.

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

NFS/localio: prevent direct reclaim recursion into NFS via nfswritepages

LOCALIO is an NFS loopback mount optimization that avoids using the network for READ, WRITE and COMMIT if the NFS client and server are determined to be on the same system. But because LOCALIO is still fundamentally "just NFS loopback mount" it is susceptible to recursion deadlock via direct reclaim, e.g.: NFS LOCALIO down to XFS and then back into NFS via nfswritepages.

Fix LOCALIO's potential for direct reclaim deadlock by ensuring that all its page cache allocations are done from GFPNOFS context.

Thanks to Ben Coddington for pointing out commit ad22c7a043c2 ("xfs: prevent stack overflows from page cache allocation").

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

rtc: check if rtcreadtime was successful in rtctimerdowork()

If the rtcreadtime call fails,, the struct rtctime tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware.

When calling rtctmtoktime later, the result may be a very large value (possibly KTIMEMAX). If there are periodic timers in rtc->timerqueue, they will continually expire, may causing kernel softlockup.

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

netfs: Fix the (non-)cancellation of copy when cache is temporarily disabled

When the caching for a cookie is temporarily disabled (e.g. due to a DIO write on that file), future copying to the cache for that file is disabled until all fds open on that file are closed. However, if netfslib is using the deprecated PGprivate2 method (such as is currently used by ceph), and decides it wants to copy to the cache, netfsadvancewrite() will just bail at the first check seeing that the cache stream is unavailable, and indicate that it dealt with all the content.

This means that we have no subrequests to provide notifications to drive the state machine or even to pin the request and the request just gets discarded, leaving the folios with PGprivate2 set.

Fix this by jumping directly to cancel the request if the cache is not available. That way, we don't remove mark3 from the folioqueue list and netfspgpriv2cancel() will clean up the folios.

This was found by running the generic/013 xfstest against ceph with an active cache and the "-o fsc" option passed to ceph. That would usually hang

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

sched/fair: Clear reldeadline when initializing forked entities

A yield-triggered crash can happen when a newly forked schedentity enters the fair class with se->reldeadline unexpectedly set.

The failing sequence is:

1. A task is forked while se->reldeadline is still set. 2. schedfork() initializes vruntime, vlag and other schedentity state, but does not clear reldeadline. 3. On the first enqueue, enqueueentity() calls placeentity(). 4. Because se->reldeadline is set, placeentity() treats se->deadline as a relative deadline and converts it to an absolute deadline by adding the current vruntime. 5. However, the forked entity's deadline is not a valid inherited relative deadline for this new scheduling instance, so the conversion produces an abnormally large deadline. 6. If the task later calls schedyield(), yieldtaskfair() advances se->vruntime to se->deadline. 7. The inflated vruntime is then used by the following enqueue path, where the vruntime-derived key can overflow when multiplied by the entity weight. 8. This corrupts cfsrq->sumwvruntime, breaks EEVDF eligibility calculation, and can eventually make all entities appear ineligible. picknextentity() may then return NULL unexpectedly, leading to a later NULL dereference.

A captured trace shows the effect clearly. Before yield, the entity's vruntime was around:

9834017729983308

After yieldtaskfair() executed:

se->vruntime = se->deadline

the vruntime jumped to:

19668035460670230

and the deadline was later advanced further to:

19668035463470230

This shows that the deadline had already become abnormally large before yieldtaskfair() copied it into vruntime.

reldeadline is only meaningful when se->deadline really carries a relative deadline that still needs to be placed against vruntime. A freshly forked schedentity should not inherit or retain this state. Clear se->reldeadline in schedfork(), together with the other schedentity runtime state, so that the first enqueue does not interpret the new entity's deadline as a stale relative deadline.

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

netfs: Fix ceph copy to cache on write-begin

At the end of netfsunlockreadfolio() in which folios are marked appropriately for copying to the cache (either with by being marked dirty and having their private data set or by having PGprivate2 set) and then unlocked, the folioqueue struct has the entry pointing to the folio cleared. This presents a problem for netfspgpriv2writetothecache(), which is used to write folios marked with PGprivate2 to the cache as it expects to be able to trawl the folioqueue list thereafter to find the relevant folios, leading to a hang.

Fix this by not clearing the folioqueue entry if we're going to do the deprecated copy-to-cache. The clearance will be done instead as the folios are written to the cache.

This can be reproduced by starting cachefiles, mounting a ceph filesystem with "-o fsc" and writing to it.

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

drm/nouveau: fix nvkmdevice leak on aperture removal failure

When apertureremoveconflictingpcidevices() fails during probe, the error path returns directly without unwinding the nvkmdevice that was just allocated by nvkmdevicepcinew(). This leaks both the device wrapper and the pcienabledevice() reference taken inside it.

Jump to the existing failnvkm label so nvkmdevicedel() runs and balances both. The leak was introduced when the intermediate nvkmdevicedel() between detection and aperture removal was dropped in favor of creating the pci device once.

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

erofs: handle end of filesystem properly for file-backed mounts

I/O requests beyond the end of the filesystem should be zeroed out, similar to loopback devices and that is what we expect.

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

RDMA/rxe: Fix the qp flush warnings in req

When the qp is in error state, the status of WQEs in the queue should be set to error. Or else the following will appear.

[ 920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxecomp.c:756 rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.617744] Modules linked in: rnbdclient(O) rtrsclient(O) rtrscore(O) rdmaucm rdmacm iwcm ibcm crc32generic rdmarxe ip6udptunnel udptunnel ibuverbs ibcore loop brd nullblk ipv6 [ 920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G O 6.1.113-storage+ #65 [ 920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 920.619396] RIP: 0010:rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff <0f> 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24 [ 920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246 [ 920.620817] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000008 [ 920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac [ 920.621548] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffac406450 [ 920.621884] R10: ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800 [ 920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: 0000000000000000 [ 920.622609] FS: 0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000 [ 920.622979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 920.623245] CR2: 00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0 [ 920.623680] Call Trace: [ 920.623815] <TASK> [ 920.623933] ? warn+0x79/0xc0 [ 920.624116] ? rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.624356] ? reportbug+0xfb/0x150 [ 920.624594] ? handlebug+0x3c/0x60 [ 920.624796] ? excinvalidop+0x14/0x70 [ 920.624976] ? asmexcinvalidop+0x16/0x20 [ 920.625203] ? rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.625474] ? rxecompleter+0x329/0xcc0 [rdmarxe] [ 920.625749] rxedotask+0x80/0x110 [rdmarxe] [ 920.626037] rxerequester+0x625/0xde0 [rdmarxe] [ 920.626310] ? rxecqpost+0xe2/0x180 [rdmarxe] [ 920.626583] ? docomplete+0x18d/0x220 [rdmarxe] [ 920.626812] ? rxecompleter+0x1a3/0xcc0 [rdmarxe] [ 920.627050] rxedotask+0x80/0x110 [rdmarxe] [ 920.627285] taskletactioncommon.constprop.0+0xa4/0x120 [ 920.627522] handlesoftirqs+0xc2/0x250 [ 920.627728] ? sortrange+0x20/0x20 [ 920.627942] runksoftirqd+0x1f/0x30 [ 920.628158] smpbootthreadfn+0xc7/0x1b0 [ 920.628334] kthread+0xd6/0x100 [ 920.628504] ? kthreadcompleteandexit+0x20/0x20 [ 920.628709] retfromfork+0x1f/0x30 [ 920.628892] </TASK>

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

crypto: pcrypt - Call crypto layer directly when padatadoparallel() return -EBUSY

Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATARESET"), the pcrypt encryption and decryption operations return -EAGAIN when the CPU goes online or offline. In algtest(), a WARN is generated when pcryptaeaddecrypt() or pcryptaeadencrypt() returns -EAGAIN, the unnecessary panic will occur when paniconwarn set 1. Fix this issue by calling crypto layer directly without parallelization in that case.

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

wifi: iwlwifi: mvm: avoid NULL pointer dereference

When iterating over the links of a vif, we need to make sure that the pointer is valid (in other words - that the link exists) before dereferncing it. Use foreachvifactivelink that also does the check.

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

schedext: Fix incorrect autogroup migration detection

scxmovetask() is called from schedmovetask() and tells the BPF scheduler that cgroup migration is being committed. schedmovetask() is used by both cgroup and autogroup migrations and scxmovetask() tried to filter out autogroup migrations by testing the destination cgroup and PFEXITING but this is not enough. In fact, without explicitly tagging the thread which is doing the cgroup migration, there is no good way to tell apart scxmovetask() invocations for racing migration to the root cgroup and an autogroup migration.

This led to scxmovetask() incorrectly ignoring a migration from non-root cgroup to an autogroup of the root cgroup triggering the following warning:

WARNING: CPU: 7 PID: 1 at kernel/sched/ext.c:3725 scxcgroupcanattach+0x196/0x340 ... Call Trace: <TASK> cgroupmigrateexecute+0x5b1/0x700 cgroupattachtask+0x296/0x400 cgroupprocswrite+0x128/0x140 cgroupprocswrite+0x17/0x30 kernfsfopwriteiter+0x141/0x1f0 vfswrite+0x31d/0x4a0 x64syswrite+0x72/0xf0 dosyscall64+0x82/0x160 entrySYSCALL64afterhwframe+0x76/0x7e

Fix it by adding an argument to schedmovetask() that indicates whether the moving is for a cgroup or autogroup migration. After the change, scxmovetask() is called only for cgroup migrations and renamed to scxcgroupmovetask().

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

ice: fix eswitch code memory leak in reset scenario

Add simple eswitch mode checker in attaching VF procedure and allocate required port representor memory structures only in switchdev mode. The reset flows triggers VF (if present) detach/attach procedure. It might involve VF port representor(s) re-creation if the device is configured is switchdev mode (not legacy one). The memory was blindly allocated in current implementation, regardless of the mode and not freed if in legacy mode.

Kmemeleak trace: unreferenced object (percpu) 0x7e3bce5b888458 (size 40): comm "bash", pid 1784, jiffies 4295743894 hex dump (first 32 bytes on cpu 45): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): pcpuallocnoprof+0x4c4/0x7c0 icereprcreate+0x66/0x130 [ice] icereprcreatevf+0x22/0x70 [ice] iceeswitchattachvf+0x1b/0xa0 [ice] iceresetallvfs+0x1dd/0x2f0 [ice] icepcierrresume+0x3b/0xb0 [ice] pciresetfunction+0x8f/0x120 resetstore+0x56/0xa0 kernfsfopwriteiter+0x120/0x1b0 vfswrite+0x31c/0x430 ksyswrite+0x61/0xd0 dosyscall64+0x5b/0x180 entrySYSCALL64afterhwframe+0x76/0x7e

Testing hints (ethX is PF netdev): - create at least one VF echo 1 > /sys/class/net/ethX/device/sriovnumvfs - trigger the reset echo 1 > /sys/class/net/ethX/device/reset

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

ring-buffer: Validate the persistent meta data subbuf array

The meta data for a mapped ring buffer contains an array of indexes of all the subbuffers. The first entry is the reader page, and the rest of the entries lay out the order of the subbuffers in how the ring buffer link list is to be created.

The validator currently makes sure that all the entries are within the range of 0 and nrsubbufs. But it does not check if there are any duplicates.

While working on the ring buffer, I corrupted this array, where I added duplicates. The validator did not catch it and created the ring buffer link list on top of it. Luckily, the corruption was only that the reader page was also in the writer path and only presented corrupted data but did not crash the kernel. But if there were duplicates in the writer side, then it could corrupt the ring buffer link list and cause a crash.

Create a bitmask array with the size of the number of subbuffers. Then clear it. When walking through the subbuf array checking to see if the entries are within the range, test if its bit is already set in the subbufmask. If it is, then there is duplicates and fail the validation. If not, set the corresponding bit and continue.

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

ofnuma: fix uninitialized memory nodes causing kernel panic

When there are memory-only nodes (nodes without CPUs), these nodes are not properly initialized, causing kernel panic during boot.

ofnumainit ofnumaparsecpunodes nodeset(nid, numanodesparsed); ofnumaparsememorynodes

In ofnumaparsecpunodes, numanodesparsed gets updated only for nodes containing CPUs. Memory-only nodes should have been updated in ofnumaparsememorynodes, but they weren't.

Subsequently, when freeareainit() attempts to access NODEDATA() for these uninitialized memory nodes, the kernel panics due to NULL pointer dereference.

This can be reproduced on ARM64 QEMU with 1 CPU and 2 memory nodes:

qemu-system-aarch64 \ -cpu host -nographic \ -m 4G -smp 1 \ -machine virt,accel=kvm,gic-version=3,iommu=smmuv3 \ -object memory-backend-ram,size=2G,id=mem0 \ -object memory-backend-ram,size=2G,id=mem1 \ -numa node,nodeid=0,memdev=mem0 \ -numa node,nodeid=1,memdev=mem1 \ -kernel $IMAGE \ -hda $DISK \ -append "console=ttyAMA0 root=/dev/vda rw earlycon"

[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x481fd010] [ 0.000000] Linux version 6.17.0-rc1-00001-gabb4b3daf18c-dirty (yintirui@local) (gcc (GCC) 12.3.1, GNU ld (GNU Binutils) 2.41) #52 SMP PREEMPT Mon Aug 18 09:49:40 CST 2025 [ 0.000000] KASLR enabled [ 0.000000] random: crng init done [ 0.000000] Machine model: linux,dummy-virt [ 0.000000] efi: UEFI not found. [ 0.000000] earlycon: pl11 at MMIO 0x0000000009000000 (options '') [ 0.000000] printk: legacy bootconsole [pl11] enabled [ 0.000000] OF: reserved mem: Reserved memory: No reserved-memory node in the DT [ 0.000000] NODEDATA(0) allocated [mem 0xbfffd9c0-0xbfffffff] [ 0.000000] node 1 must be removed before remove section 23 [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000040000000-0x00000000ffffffff] [ 0.000000] DMA32 empty [ 0.000000] Normal [mem 0x0000000100000000-0x000000013fffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000040000000-0x00000000bfffffff] [ 0.000000] node 1: [mem 0x00000000c0000000-0x000000013fffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x00000000bfffffff] [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 0.000000] Mem abort info: [ 0.000000] ESR = 0x0000000096000004 [ 0.000000] EC = 0x25: DABT (current EL), IL = 32 bits [ 0.000000] SET = 0, FnV = 0 [ 0.000000] EA = 0, S1PTW = 0 [ 0.000000] FSC = 0x04: level 0 translation fault [ 0.000000] Data abort info: [ 0.000000] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 0.000000] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 0.000000] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 0.000000] [00000000000000a0] user address but activemm is swapper [ 0.000000] Internal error: Oops: 0000000096000004 [#1] SMP [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.17.0-rc1-00001-g760c6dabf762-dirty #54 PREEMPT [ 0.000000] Hardware name: linux,dummy-virt (DT) [ 0.000000] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.000000] pc : freeareainit+0x50c/0xf9c [ 0.000000] lr : freeareainit+0x5c0/0xf9c [ 0.000000] sp : ffffa02ca0f33c00 [ 0.000000] x29: ffffa02ca0f33cb0 x28: 0000000000000000 x27: 0000000000000000 [ 0.000000] x26: 4ec4ec4ec4ec4ec5 x25: 00000000000c0000 x24: 00000000000c0000 [ 0.000000] x23: 0000000000040000 x22: 0000000000000000 x21: ffffa02ca0f3b368 [ 0.000000] x20: ffffa02ca14c7b98 x19: 0000000000000000 x18: 0000000000000002 [ 0.000000] x17: 000000000000cacc x16: 0000000000000001 x15: 0000000000000001 [ 0.000000] x14: 0000000080000000 x13: 0000000000000018 x12: 0000000000000002 [ 0.0 ---truncated---

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

schedext: Disable preemption between scxclaimexit() and kicking helper work

scxclaimexit() atomically sets exitkind, which prevents scxerror() from triggering further error handling. After claiming exit, the caller must kick the helper kthread work which initiates bypass mode and teardown.

If the calling task gets preempted between claiming exit and kicking the helper work, and the BPF scheduler fails to schedule it back (since error handling is now disabled), the helper work is never queued, bypass mode never activates, tasks stop being dispatched, and the system wedges.

Disable preemption across scxclaimexit() and the subsequent work kicking in all callers - scxdisable() and scxvexit(). Add lockdepassertpreemptiondisabled() to scxclaimexit() to enforce the requirement.

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

RDMA/mlx5: Fix memory leak in GETDATADIRECTSYSFSPATH handler

The UVERBSHANDLER(MLX5IBMETHODGETDATADIRECTSYSFSPATH) function allocates memory for the device path using kobjectgetpath(). If the length of the device path exceeds the output buffer length, the function returns -ENOSPC but does not free the allocated memory, resulting in a memory leak.

Add a kfree() call to the error path to ensure the allocated memory is properly freed.

Compile tested only. Issue found using a prototype static analysis tool and code review.

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

mm/pagewalk: fix race between concurrent split and refault

The splitting of a PUD entry in walkpudrange() can race with a concurrent thread refaulting the PUD leaf entry causing it to try walking a PMD range that has disappeared.

An example and reproduction of this is to try reading numamaps of a process while VFIO-PCI is setting up DMA (specifically the vfiopinpagesremote call) on a large BAR for that process.

This will trigger a kernel BUG: vfio-pci 0000:03:00.0: enabling device (0000 -> 0002) BUG: unable to handle page fault for address: ffffa23980000000 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI ... RIP: 0010:walkpgdrange+0x3b5/0x7a0 Code: 8d 43 ff 48 89 44 24 28 4d 89 ce 4d 8d a7 00 00 20 00 48 8b 4c 24 28 49 81 e4 00 00 e0 ff 49 8d 44 24 ff 48 39 c8 4c 0f 43 e3 <49> f7 06 9f ff ff ff 75 3b 48 8b 44 24 20 48 8b 40 28 48 85 c0 74 RSP: 0018:ffffac23e1ecf808 EFLAGS: 00010287 RAX: 00007f44c01fffff RBX: 00007f4500000000 RCX: 00007f44ffffffff RDX: 0000000000000000 RSI: 000ffffffffff000 RDI: ffffffff93378fe0 RBP: ffffac23e1ecf918 R08: 0000000000000004 R09: ffffa23980000000 R10: 0000000000000020 R11: 0000000000000004 R12: 00007f44c0200000 R13: 00007f44c0000000 R14: ffffa23980000000 R15: 00007f44c0000000 FS: 00007fe884739580(0000) GS:ffff9b7d7a9c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa23980000000 CR3: 000000c0650e2005 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> walkpagerange+0x195/0x1b0 walkpagevma+0x62/0xc0 shownumamap+0x12b/0x3b0 seqreaditer+0x297/0x440 seqread+0x11d/0x140 vfsread+0xc2/0x340 ksysread+0x5f/0xe0 dosyscall64+0x68/0x130 ? getpagefromfreelist+0x5c2/0x17e0 ? masstoreprealloc+0x17e/0x360 ? vmasetpageprot+0x4c/0xa0 ? allocpagesnoprof+0x14e/0x2d0 ? modmemcglruvecstate+0x8d/0x140 ? lruvecstatmodfolio+0x76/0xb0 ? foliomodstat+0x26/0x80 ? doanonymouspage+0x705/0x900 ? handlemmfault+0xa8d/0x1000 ? countmemcgevents+0x53/0xf0 ? handlemmfault+0xa5/0x360 ? douseraddrfault+0x342/0x640 ? archexittousermodeprepare.constprop.0+0x16/0xa0 ? irqentryexittousermode+0x24/0x100 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7fe88464f47e Code: c0 e9 b6 fe ff ff 50 48 8d 3d be 07 0b 00 e8 69 01 02 00 66 0f 1f 84 00 00 00 00 00 64 8b 04 25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d 00 f0 ff ff 77 5a c3 66 0f 1f 84 00 00 00 00 00 48 83 ec 28 RSP: 002b:00007ffe6cd9a9b8 EFLAGS: 00000246 ORIGRAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007fe88464f47e RDX: 0000000000020000 RSI: 00007fe884543000 RDI: 0000000000000003 RBP: 00007fe884543000 R08: 00007fe884542010 R09: 0000000000000000 R10: fffffffffffffbc5 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 </TASK>

Fix this by validating the PUD entry in walkpmdrange() using a stable snapshot (pudpget()). If the PUD is not present or is a leaf, retry the walk via ACTIONAGAIN instead of descending further. This mirrors the retry logic in walkpterange(), which lets walkpmdrange() retry if the PTE is not being got by pteoffsetmaplock().

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

usb: gadget: renesasusb3: validate endpoint index in standard request handlers

The GETSTATUS and SET/CLEARFEATURE handlers extract the endpoint number from the host-supplied wIndex without any sort of validation. Fix this up by validating the number of endpoints actually match up with the number the device has before attempting to dereference a pointer based on this math.

This is just like what was done in commit ee0d382feb44 ("usb: gadget: aspeedudc: validate endpoint index for ast udc") for the aspeed driver.

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

rcu/nocb: Fix missed RCU barrier on deoffloading

Currently, running rcutorture test with torturetype=rcu fwdprogress=8 nbarriercbs=8 nocbsnthreads=8 nocbstoggle=100 onoffinterval=60 testboost=2, will trigger the following warning:

WARNING: CPU: 19 PID: 100 at kernel/rcu/treenocb.h:1061 rcunocbrdpdeoffload+0x292/0x2a0 RIP: 0010:rcunocbrdpdeoffload+0x292/0x2a0 Call Trace: <TASK> ? warn+0x7e/0x120 ? rcunocbrdpdeoffload+0x292/0x2a0 ? reportbug+0x18e/0x1a0 ? handlebug+0x3d/0x70 ? excinvalidop+0x18/0x70 ? asmexcinvalidop+0x1a/0x20 ? rcunocbrdpdeoffload+0x292/0x2a0 rcunocbcpudeoffload+0x70/0xa0 rcunocbtoggle+0x136/0x1c0 ? pfxrcunocbtoggle+0x10/0x10 kthread+0xd1/0x100 ? pfxkthread+0x10/0x10 retfromfork+0x2f/0x50 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

CPU0 CPU2 CPU3 //rcunocbtoggle //nocbcbwait //rcutorture

// deoffload CPU1 // process CPU1's rdp rcubarrier() rcusegcblistentrain() rcusegcblistaddlen(1); // len == 2 // enqueue barrier // callback to CPU1's // rdp->cblist rcudobatch() // invoke CPU1's rdp->cblist // callback rcubarriercallback() rcubarrier() mutexlock(&rcustate.barriermutex); // still see len == 2 // enqueue barrier callback // to CPU1's rdp->cblist rcusegcblistentrain() rcusegcblistaddlen(1); // len == 3 // decrement len rcusegcblistaddlen(-2); kthreadparkme()

// CPU1's rdp->cblist len == 1 // Warn because there is // still a pending barrier // trigger warning WARNONONCE(rcusegcblistncbs(&rdp->cblist)); cpusreadunlock();

// wait CPU1 to comes online and // invoke barrier callback on // CPU1 rdp's->cblist waitforcompletion(&rcustate.barriercompletion); // deoffload CPU4 cpusreadlock() rcubarrier() mutexlock(&rcustate.barriermutex); // block on barriermutex // wait rcubarrier() on // CPU3 to unlock barriermutex // but CPU3 unlock barriermutex // need to wait CPU1 comes online // when CPU1 going online will block on cpuswritelock

The above scenario will not only trigger a WARNONONCE(), but also trigger a deadlock.

Thanks to nocb locking, a second racing rcubarrier() on an offline CPU will either observe the decremented callback counter down to 0 and spare the callback enqueue, or rcuo will observe the new callback and keep rdp->nocbcbsleep to false.

Therefore check rdp->nocbcbsleep before parking to make sure no further rcubarrier() is waiting on the rdp.

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

mtd: spi-nor: sst: Fix SST write failure

'commit 18bcb4aa54ea ("mtd: spi-nor: sst: Factor out common write operation to sstnorwritedata()")' introduced a bug where only one byte of data is written, regardless of the number of bytes passed to sstnorwritedata(), causing a kernel crash during the write operation. Ensure the correct number of bytes are written as passed to sstnorwritedata().

Call trace: [ 57.400180] ------------[ cut here ]------------ [ 57.404842] While writing 2 byte written 1 bytes [ 57.409493] WARNING: CPU: 0 PID: 737 at drivers/mtd/spi-nor/sst.c:187 sstnorwritedata+0x6c/0x74 [ 57.418464] Modules linked in: [ 57.421517] CPU: 0 UID: 0 PID: 737 Comm: mtddebug Not tainted 6.12.0-g5ad04afd91f9 #30 [ 57.429517] Hardware name: Xilinx Versal A2197 Processor board revA - x-prc-02 revA (DT) [ 57.437600] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 57.444557] pc : sstnorwritedata+0x6c/0x74 [ 57.448911] lr : sstnorwritedata+0x6c/0x74 [ 57.453264] sp : ffff80008232bb40 [ 57.456570] x29: ffff80008232bb40 x28: 0000000000010000 x27: 0000000000000001 [ 57.463708] x26: 000000000000ffff x25: 0000000000000000 x24: 0000000000000000 [ 57.470843] x23: 0000000000010000 x22: ffff80008232bbf0 x21: ffff000816230000 [ 57.477978] x20: ffff0008056c0080 x19: 0000000000000002 x18: 0000000000000006 [ 57.485112] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80008232b580 [ 57.492246] x14: 0000000000000000 x13: ffff8000816d1530 x12: 00000000000004a4 [ 57.499380] x11: 000000000000018c x10: ffff8000816fd530 x9 : ffff8000816d1530 [ 57.506515] x8 : 00000000fffff7ff x7 : ffff8000816fd530 x6 : 0000000000000001 [ 57.513649] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 57.520782] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0008049b0000 [ 57.527916] Call trace: [ 57.530354] sstnorwritedata+0x6c/0x74 [ 57.534361] sstnorwrite+0xb4/0x18c [ 57.538019] mtdwriteoobstd+0x7c/0x88 [ 57.541941] mtdwriteoob+0x70/0xbc [ 57.545511] mtdwrite+0x68/0xa8 [ 57.548733] mtdcharwrite+0x10c/0x290 [ 57.552477] vfswrite+0xb4/0x3a8 [ 57.555791] ksyswrite+0x74/0x10c [ 57.559189] arm64syswrite+0x1c/0x28 [ 57.563109] invokesyscall+0x54/0x11c [ 57.566856] el0svccommon.constprop.0+0xc0/0xe0 [ 57.571557] doel0svc+0x1c/0x28 [ 57.574868] el0svc+0x30/0xcc [ 57.577921] el0t64synchandler+0x120/0x12c [ 57.582276] el0t64sync+0x190/0x194 [ 57.585933] ---[ end trace 0000000000000000 ]---

[pratyush@kernel.org: add Cc stable tag]

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

octeontx2-pf: handle otx2mboxgetrsp errors in otx2flows.c

Adding error pointer check after calling otx2mboxgetrsp().

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

f2fs: fix null-ptr-deref in f2fssubmitpagebio()

There's issue as follows when concurrently installing the f2fs.ko module and mounting the f2fs file system: KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:bioalloc+0x2fb/0x6c0 [f2fs] Call Trace: <TASK> f2fssubmitpagebio+0x126/0x8b0 [f2fs] getmetapage+0x1d4/0x920 [f2fs] getcheckpointversion.constprop.0+0x2b/0x3c0 [f2fs] validatecheckpoint+0xac/0x290 [f2fs] f2fsgetvalidcheckpoint+0x207/0x950 [f2fs] f2fsfillsuper+0x1007/0x39b0 [f2fs] mountbdev+0x183/0x250 legacygettree+0xf4/0x1e0 vfsgettree+0x88/0x340 donewmount+0x283/0x5e0 pathmount+0x2b2/0x15b0 x64sysmount+0x1fe/0x270 dosyscall64+0x5f/0x170 entrySYSCALL64afterhwframe+0x76/0x7e

Above issue happens as the biset of the f2fs file system is not initialized before register "f2fsfstype". To address above issue just register "f2fsfstype" at the last in initf2fsfs(). Ensure that all f2fs file system resources are initialized.

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

schedext: Fix starvation of scxenable() under fair-class saturation

During scxenable(), the READY -> ENABLED task switching loop changes the calling thread's schedclass from fair to ext. Since fair has higher priority than ext, saturating fair-class workloads can indefinitely starve the enable thread, hanging the system. This was introduced when the enable path switched from preemptdisable() to scxbypass() which doesn't protect against fair-class starvation. Note that the original preemptdisable() protection wasn't complete either - in partial switch modes, the calling thread could still be starved after preemptenable() as it may have been switched to ext class.

Fix it by offloading the enable body to a dedicated system-wide RT (SCHEDFIFO) kthread which cannot be starved by either fair or ext class tasks. scxenable() lazily creates the kthread on first use and passes the ops pointer through a struct scxenablecmd containing the kthreadwork, then synchronously waits for completion.

The workfn runs on a different kthread from sch->helper (which runs disablework), so it can safely flush disablework on the error path without deadlock.

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

btrfs: fix chunk map leak in btrfsmapblock() after btrfschunkmapnumcopies()

Fix a chunk map leak in btrfsmapblock(): if we return early with -EINVAL, we're not freeing the chunk map that we've just looked up.

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

drm/amd/display: Fix NULL pointer dereference in dcn401inithw()

dcn401inithw() assumes that updatebwboundingbox() is valid when entering the update path. However, the existing condition:

((!fams2enable && updatebwboundingbox) || freqchanged)

does not guarantee this, as the freqchanged branch can evaluate to true independently of the callback pointer.

This can result in calling updatebwboundingbox() when it is NULL.

Fix this by separating the update condition from the pointer checks and ensuring the callback, dc->clkmgr, and bwparams are validated before use.

Fixes the below: ../dc/hwss/dcn401/dcn401hwseq.c:367 dcn401inithw() error: we previously assumed 'dc->respool->funcs->updatebwboundingbox' could be null (see line 362)

(cherry picked from commit 86117c5ab42f21562fedb0a64bffea3ee5fcd477)

drm/amd/display: Fix dsc eDP issue