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:

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:

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:

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:

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:

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:

drm/amdkfd: Unreserve bo if queue update failed

Error handling path should unreserve bo then return failed.

(cherry picked from commit c24afed7de9ecce341825d8ab55a43a254348b33)

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:

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:

iio: proximity: hx9023s: Protect against division by zero in setsampfreq

Avoid division by zero when sampling frequency is unspecified.

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)

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

schedext: Fix SCXKICKWAIT deadlock by deferring wait to balance callback

SCXKICKWAIT busy-waits in kickcpusirqworkfn() using smpcondloadacquire() until the target CPU's kicksync advances. Because the irqwork runs in hardirq context, the waiting CPU cannot reschedule and its own kicksync never advances. If multiple CPUs form a wait cycle, all CPUs deadlock.

Replace the busy-wait in kickcpusirqworkfn() with reschedcurr() to force the CPU through dopicktaskscx(), which queues a balance callback to perform the wait. The balance callback drops the rq lock and enables IRQs following the schedcorebalance() pattern, so the CPU can process IPIs while waiting. The local CPU's kicksync is advanced on entry to dopicktaskscx() and continuously during the wait, ensuring any CPU that starts waiting for us sees the advancement and cannot form cyclic dependencies.

drm/amd/display: Fix dsc eDP issue

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

ring-buffer: Fix possible dereference of uninitialized pointer

There is a pointer headpage in rbmetavalidateevents() which is not initialized at the beginning of a function. This pointer can be dereferenced if there is a failure during reader page validation. In this case the control is passed to "invalid" label where the pointer is dereferenced in a loop.

To fix the issue initialize orighead and headpage before calling rbvalidatebuffer.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

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

tracing: ring-buffer: Fix to check event length before using

Check the event length before adding it for accessing next index in rbreaddatabuffer(). Since this function is used for validating possibly broken ring buffers, the length of the event could be broken. In that case, the new event (e + len) can point a wrong address. To avoid invalid memory access at boot, check whether the length of each event is in the possible range before using it.

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

xfrm: fix refcount leak in xfrmmigratepolicyfind

syzkaller reported a memory leak in xfrmpolicyalloc:

BUG: memory leak unreferenced object 0xffff888114d79000 (size 1024): comm "syz.1.17", pid 931 ... xfrmpolicyalloc+0xb3/0x4b0 net/xfrm/xfrmpolicy.c:432

The root cause is a double call to xfrmpolholdrcu() in xfrmmigratepolicyfind(). The lookup function already returns a policy with held reference, making the second call redundant.

Remove the redundant xfrmpolholdrcu() call to fix the refcount imbalance and prevent the memory leak.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

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

schedext: Fix stale direct dispatch state in ddspdsqid

@p->scx.ddspdsqid can be left set (non-SCXDSQINVALID) triggering a spurious warning in markdirectdispatch() when the next wakeup's ops.selectcpu() calls scxbpfdsqinsert(), such as:

WARNING: kernel/sched/ext.c:1273 at scxdsqinsertcommit+0xcd/0x140

The root cause is that ddspdsqid was only cleared in dispatchenqueue(), which is not reached in all paths that consume or cancel a direct dispatch verdict.

Fix it by clearing it at the right places:

- directdispatch(): cache the direct dispatch state in local variables and clear it before dispatchenqueue() on the synchronous path. For the deferred path, the direct dispatch state must remain set until processddspdeferredlocals() consumes them.

- processddspdeferredlocals(): cache the dispatch state in local variables and clear it before calling dispatchtolocaldsq(), which may migrate the task to another rq.

- doenqueuetask(): clear the dispatch state on the enqueue path (local/global/bypass fallbacks), where the direct dispatch verdict is ignored.

- dequeuetaskscx(): clear the dispatch state after dispatchdequeue() to handle both the deferred dispatch cancellation and the holdingcpu race, covering all cases where a pending direct dispatch is cancelled.

- scxdisabletask(): clear the direct dispatch state when transitioning a task out of the current scheduler. Waking tasks may have had the direct dispatch state set by the outgoing scheduler's ops.selectcpu() and then been queued on a wakelist via ttwuqueuewakelist(), when SCXOPSALLOWQUEUEDWAKEUP is set. Such tasks are not on the runqueue and are not iterated by scxbypass(), so their direct dispatch state won't be cleared. Without this clear, any subsequent SCX scheduler that tries to direct dispatch the task will trigger the WARNONONCE() in markdirectdispatch().

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:

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:

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:

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:

schedext: Fix possible deadlock in the deferredirqworkfn()

For PREEMPTRT=y kernels, the deferredirqworkfn() is executed in the per-cpu irqwork/ task context and not disable-irq, if the rq returned by containerof() is current CPU's rq, the following scenarios may occur:

lock(&rq->lock); <Interrupt> lock(&rq->lock);

This commit use IRQWORKINITHARD() to replace initirqwork() to initialize rq->scx.deferredirqwork, make the deferredirqworkfn() is always invoked in hard-irq context.

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

nfs/localio: restore creds before releasing pageio data

Otherwise if the nfsd filecache code releases the nfsdfile immediately, it can trigger the BUGON(cred == current->cred) in putcred() when it puts the nfsdfile->nffile->f-cred.

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:

netsched: genestimator: fix esttimer() vs CONFIGPREEMPTRT=y

syzbot reported a WARNING in esttimer() [1]

Problem here is that with CONFIGPREEMPTRT=y, timer callbacks can be preempted.

Adopt preemptdisablenested()/preemptenablenested() to fix this.

[1] WARNING: CPU: 0 PID: 16 at ./include/linux/seqlock.h:221 seqpropassert include/linux/seqlock.h:221 [inline] WARNING: CPU: 0 PID: 16 at ./include/linux/seqlock.h:221 esttimer+0x6dc/0x9f0 net/core/genestimator.c:93 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Not tainted syzkaller #0 PREEMPT{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:seqpropassert include/linux/seqlock.h:221 [inline] RIP: 0010:esttimer+0x6dc/0x9f0 net/core/genestimator.c:93 Call Trace: <TASK> calltimerfn+0x17e/0x5f0 kernel/time/timer.c:1747 expiretimers kernel/time/timer.c:1798 [inline] runtimers kernel/time/timer.c:2372 [inline] runtimerbase+0x648/0x970 kernel/time/timer.c:2384 runtimerbase kernel/time/timer.c:2393 [inline] runtimersoftirq+0xb7/0x180 kernel/time/timer.c:2403 handlesoftirqs+0x22c/0x710 kernel/softirq.c:579 dosoftirq kernel/softirq.c:613 [inline] runktimerd+0xcf/0x190 kernel/softirq.c:1043 smpbootthreadfn+0x53f/0xa60 kernel/smpboot.c:160 kthread+0x70e/0x8a0 kernel/kthread.c:463 retfromfork+0x3fc/0x770 arch/x86/kernel/process.c:148 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK>

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

net/mlx5: HWS, Fix memory leak in hwsactiongetsharedstcnic error flow

When an invalid stctype is provided, the function allocates memory for sharedstc but jumps to unlockandout without freeing it, causing a memory leak.

Fix by jumping to freesharedstc label instead to ensure proper cleanup.

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

net/mlx5: HWS, Fix memory leak in hwspoolbuddyinit error path

In the error path of hwspoolbuddyinit(), the buddy allocator cleanup doesn't free the allocator structure itself, causing a memory leak.

Add the missing kfree() to properly release all allocated memory.

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

iouring/kbuf: fix signedness in thislen calculation

When importing and using buffers, buf->len is considered unsigned. However, buf->len is converted to signed int when committing. This can lead to unexpected behavior if the buffer is large enough to be interpreted as a negative value. Make mint calculation unsigned.

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

iouring/kbuf: always use READONCE() to read ring provided buffer lengths

Since the buffers are mapped from userspace, it is prudent to use READONCE() to read the value into a local variable, and use that for any other actions taken. Having a stable read of the buffer length avoids worrying about it changing after checking, or being read multiple times.

Similarly, the buffer may well change in between it being picked and being committed. Ensure the looping for incremental ring buffer commit stops if it hits a zero sized buffer, as no further progress can be made at that point.