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

drm/xe/sync: Cleanup partially initialized sync on parse failure

xesyncentryparse() can allocate references (syncobj, fence, chain fence, or user fence) before hitting a later failure path. Several of those paths returned directly, leaving partially initialized state and leaking refs.

Route these error paths through a common freesync label and call xesyncentrycleanup(sync) before returning the error.

(cherry picked from commit f939bdd9207a5d1fc55cced5459858480686ce22)

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

media: rockchip: rga: Fix possible ERRPTR dereference in rgabufinit()

rgagetframe() can return ERRPTR(-EINVAL) when buffer type is unsupported or invalid. rgabufinit() does not check the return value and unconditionally dereferences the pointer when accessing f->size.

Add proper ERRPTR checking and return the error to prevent dereferencing an invalid pointer.

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

rxrpc, afs: Fix missing error pointer check after rxrpckernellookuppeer()

rxrpckernellookuppeer() can also return error pointers in addition to NULL, so just checking for NULL is not sufficient.

Fix this by:

(1) Changing rxrpckernellookuppeer() to return -ENOMEM rather than NULL on allocation failure.

(2) Making the callers in afs use ISERR() and PTRERR() to pass on the error code returned.

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

thermal: core: Address thermal zone removal races with resume

Since thermalzonepmcomplete() and thermalzonedeviceresume() re-initialize the pollqueue delayed work for the given thermal zone, the canceldelayedworksync() in thermalzonedeviceunregister() may miss some already running work items and the thermal zone may be freed prematurely [1].

There are two failing scenarios that both start with running thermalpmnotifycomplete() right before invoking thermalzonedeviceunregister() for one of the thermal zones.

In the first scenario, there is a work item already running for the given thermal zone when thermalpmnotifycomplete() calls thermalzonepmcomplete() for that thermal zone and it continues to run when thermalzonedeviceunregister() starts. Since the pollqueue delayed work has been re-initialized by thermalpmnotifycomplete(), the running work item will be missed by the canceldelayedworksync() in thermalzonedeviceunregister() and if it continues to run past the freeing of the thermal zone object, a use-after-free will occur.

In the second scenario, thermalzonedeviceresume() queued up by thermalpmnotifycomplete() runs right after the thermalzoneexit() called by thermalzonedeviceunregister() has returned. The pollqueue delayed work is re-initialized by it before canceldelayedworksync() is called by thermalzonedeviceunregister(), so it may continue to run after the freeing of the thermal zone object, which also leads to a use-after-free.

Address the first failing scenario by ensuring that no thermal work items will be running when thermalpmnotifycomplete() is called. For this purpose, first move the canceldelayedwork() call from thermalzonepmcomplete() to thermalzonepmprepare() to prevent new work from entering the workqueue going forward. Next, switch over to using a dedicated workqueue for thermal events and update the code in thermalpmnotify() to flush that workqueue after thermalpmnotifyprepare() has returned which will take care of all leftover thermal work already on the workqueue (that leftover work would do nothing useful anyway because all of the thermal zones have been flagged as suspended).

The second failing scenario is addressed by adding a tz->state check to thermalzonedeviceresume() to prevent it from re-initializing the pollqueue delayed work if the thermal zone is going away.

Note that the above changes will also facilitate relocating the suspend and resume of thermal zones closer to the suspend and resume of devices, respectively.

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

media: chips-media: wave5: Fix Null reference while testing fluster

When multi instances are created/destroyed, many interrupts happens and structures for decoder are removed. "struct vpuinstance" this structure is shared for all flow in the decoder, so if the structure is not protected by lock, Null dereference could happens sometimes. IRQ Handler was spilt to two phases and Lock was added as well.

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

media: chips-media: wave5: Fix device cleanup order to prevent kernel panic

Move video device unregistration to the beginning of the remove function to ensure all video operations are stopped before cleaning up the worker thread and disabling PM runtime. This prevents hardware register access after the device has been powered down.

In polling mode, the hrtimer periodically triggers wave5vputimercallback() which queues work to the kthread worker. The worker executes wave5vpuirqworkfn() which reads hardware registers via wave5vdireadregister().

The original cleanup order disabled PM runtime and powered down hardware before unregistering video devices. When autosuspend triggers and powers off the hardware, the video devices are still registered and the worker thread can still be triggered by the hrtimer, causing it to attempt reading registers from powered-off hardware. This results in a bus error (synchronous external abort) and kernel panic.

This causes random kernel panics during encoding operations:

Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP Modules linked in: wave5 rpmsgctrl rpmsgchar ... CPU: 0 UID: 0 PID: 1520 Comm: vpuirqthread Tainted: G M W pc : wave5vdireadregister+0x10/0x38 [wave5] lr : wave5vpuirqworkfn+0x28/0x60 [wave5] Call trace: wave5vdireadregister+0x10/0x38 [wave5] kthreadworkerfn+0xd8/0x238 kthread+0x104/0x120 retfromfork+0x10/0x20 Code: aa1e03e9 d503201f f9416800 8b214000 (b9400000) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: synchronous external abort: Fatal exception

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

drm/xe: always keep track of remap prev/next

During 3D workload, user is reporting hitting:

[ 413.361679] WARNING: drivers/gpu/drm/xe/xevm.c:1217 at vmbindioctlopsunwind+0x1e2/0x2e0 [xe], CPU#7: vkd3dqueue/9925 [ 413.361944] CPU: 7 UID: 1000 PID: 9925 Comm: vkd3dqueue Kdump: loaded Not tainted 7.0.0-070000rc3-generic #202603090038 PREEMPT(lazy) [ 413.361949] RIP: 0010:vmbindioctlopsunwind+0x1e2/0x2e0 [xe] [ 413.362074] RSP: 0018:ffffd4c25c3df930 EFLAGS: 00010282 [ 413.362077] RAX: 0000000000000000 RBX: ffff8f3ee817ed10 RCX: 0000000000000000 [ 413.362078] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 413.362079] RBP: ffffd4c25c3df980 R08: 0000000000000000 R09: 0000000000000000 [ 413.362081] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8f41fbf99380 [ 413.362082] R13: ffff8f3ee817e968 R14: 00000000ffffffef R15: ffff8f43d00bd380 [ 413.362083] FS: 00000001040ff6c0(0000) GS:ffff8f4696d89000(0000) knlGS:00000000330b0000 [ 413.362085] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 [ 413.362086] CR2: 00007ddfc4747000 CR3: 00000002e6262005 CR4: 0000000000f72ef0 [ 413.362088] PKRU: 55555554 [ 413.362089] Call Trace: [ 413.362092] <TASK> [ 413.362096] xevmbindioctl+0xa9a/0xc60 [xe]

Which seems to hint that the vma we are re-inserting for the ops unwind is either invalid or overlapping with something already inserted in the vm. It shouldn't be invalid since this is a re-insertion, so must have worked before. Leaving the likely culprit as something already placed where we want to insert the vma.

Following from that, for the case where we do something like a rebind in the middle of a vma, and one or both mapped ends are already compatible, we skip doing the rebind of those vma and set next/prev to NULL. As well as then adjust the original unmap va range, to avoid unmapping the ends. However, if we trigger the unwind path, we end up with three va, with the two ends never being removed and the original va range in the middle still being the shrunken size.

If this occurs, one failure mode is when another unwind op needs to interact with that range, which can happen with a vector of binds. For example, if we need to re-insert something in place of the original va. In this case the va is still the shrunken version, so when removing it and then doing a re-insert it can overlap with the ends, which were never removed, triggering a warning like above, plus leaving the vm in a bad state.

With that, we need two things here:

1) Stop nuking the prev/next tracking for the skip cases. Instead relying on checking for skip prev/next, where needed. That way on the unwind path, we now correctly remove both ends.

2) Undo the unmap va shrinkage, on the unwind path. With the two ends now removed the unmap va should expand back to the original size again, before re-insertion.

v2: - Update the explanation in the commit message, based on an actual IGT of triggering this issue, rather than conjecture. - Also undo the unmap shrinkage, for the skip case. With the two ends now removed, the original unmap va range should expand back to the original range. v3: - Track the old start/range separately. vmasize/start() uses the va info directly.

(cherry picked from commit aec6969f75afbf4e01fd5fb5850ed3e9c27043ac)

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

dmaengine: idxd: fix possible wrong descriptor completion in llistabortdesc()

At the end of this function, d is the traversal cursor of flist, but the code completes found instead. This can lead to issues such as NULL pointer dereferences, double completion, or descriptor leaks.

Fix this by completing d instead of found in the final listforeachentrysafe() loop.

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

netfs: Fix kernel BUG in netfslimititer() for ITERKVEC iterators

When a process crashes and the kernel writes a core dump to a 9P filesystem, kernelwrite() creates an ITERKVEC iterator. This iterator reaches netfslimititer() via netfsunbufferedwrite(), which only handles ITERFOLIOQ, ITERBVEC and ITERXARRAY iterator types, hitting the BUG() for any other type.

Fix this by adding netfslimitkvec() following the same pattern as netfslimitbvec(), since both kvec and bvec are simple segment arrays with pointer and length fields. Dispatch it from netfslimititer() when the iterator type is ITERKVEC.

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

netfilter: nftables: reject immediate NFQUEUE verdict

nftqueue is always used from userspace nftables to deliver the NFQUEUE verdict. Immediately emitting an NFQUEUE verdict is never used by the userspace nft tools, so reject immediate NFQUEUE verdicts.

The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NFQUEUE immediate verdicts to address this issue.

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

ip6tunnel: use skbvlaninetprepare() in ip6tnlrcv()

Blamed commit did not take care of VLAN encapsulations as spotted by syzbot [1].

Use skbvlaninetprepare() instead of pskbinetmaypull().

[1] BUG: KMSAN: uninit-value in INETECNdecapsulate include/net/inetecn.h:253 [inline] BUG: KMSAN: uninit-value in INETECNdecapsulate include/net/inetecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6ECNdecapsulate+0x7a8/0x1fa0 include/net/inetecn.h:321 INETECNdecapsulate include/net/inetecn.h:253 [inline] INETECNdecapsulate include/net/inetecn.h:275 [inline] IP6ECNdecapsulate+0x7a8/0x1fa0 include/net/inetecn.h:321 ip6ip6dscpecndecapsulate+0x16f/0x1b0 net/ipv6/ip6tunnel.c:729 ip6tnlrcv+0xed9/0x1b50 net/ipv6/ip6tunnel.c:860 ip6tnlrcv+0xc3/0x100 net/ipv6/ip6tunnel.c:903 grercv+0x1529/0x1b90 net/ipv6/ip6gre.c:-1 ip6protocoldeliverrcu+0x1c89/0x2c60 net/ipv6/ip6input.c:438 ip6inputfinish+0x1f4/0x4a0 net/ipv6/ip6input.c:489 NFHOOK include/linux/netfilter.h:318 [inline] ip6input+0x9c/0x330 net/ipv6/ip6input.c:500 ip6mcinput+0x7ca/0xc10 net/ipv6/ip6input.c:590 dstinput include/net/dst.h:474 [inline] ip6rcvfinish+0x958/0x990 net/ipv6/ip6input.c:79 NFHOOK include/linux/netfilter.h:318 [inline] ipv6rcv+0xf1/0x3c0 net/ipv6/ip6input.c:311 netifreceiveskbonecore net/core/dev.c:6139 [inline] netifreceiveskb+0x1df/0xac0 net/core/dev.c:6252 netifreceiveskbinternal net/core/dev.c:6338 [inline] netifreceiveskb+0x57/0x630 net/core/dev.c:6397 tunrxbatched+0x1df/0x980 drivers/net/tun.c:1485 tungetuser+0x5c0e/0x6c60 drivers/net/tun.c:1953 tunchrwriteiter+0x3e9/0x5c0 drivers/net/tun.c:1999 newsyncwrite fs/readwrite.c:593 [inline] vfswrite+0xbe2/0x15d0 fs/readwrite.c:686 ksyswrite fs/readwrite.c:738 [inline] dosyswrite fs/readwrite.c:749 [inline] sesyswrite fs/readwrite.c:746 [inline] x64syswrite+0x1fb/0x4d0 fs/readwrite.c:746 x64syscall+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls64.h:2 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xd3/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

Uninit was created at: slabpostallochook mm/slub.c:4960 [inline] slaballocnode mm/slub.c:5263 [inline] kmemcacheallocnodenoprof+0x9e7/0x17a0 mm/slub.c:5315 kmallocreserve+0x13c/0x4b0 net/core/skbuff.c:586 allocskb+0x805/0x1040 net/core/skbuff.c:690 allocskb include/linux/skbuff.h:1383 [inline] allocskbwithfrags+0xc5/0xa60 net/core/skbuff.c:6712 sockallocsendpskb+0xacc/0xc60 net/core/sock.c:2995 tunallocskb drivers/net/tun.c:1461 [inline] tungetuser+0x1142/0x6c60 drivers/net/tun.c:1794 tunchrwriteiter+0x3e9/0x5c0 drivers/net/tun.c:1999 newsyncwrite fs/readwrite.c:593 [inline] vfswrite+0xbe2/0x15d0 fs/readwrite.c:686 ksyswrite fs/readwrite.c:738 [inline] dosyswrite fs/readwrite.c:749 [inline] sesyswrite fs/readwrite.c:746 [inline] x64syswrite+0x1fb/0x4d0 fs/readwrite.c:746 x64syscall+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls64.h:2 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xd3/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

CPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025

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

net/sched: Only allow actct to bind to clsact/ingress qdiscs and shared blocks

As Paolo said earlier [1]:

"Since the blamed commit below, classify can return TCACTCONSUMED while the current skb being held by the defragmentation engine. As reported by GangMin Kim, if such packet is that may cause a UaF when the defrag engine later on tries to tuch again such packet."

actct was never meant to be used in the egress path, however some users are attaching it to egress today [2]. Attempting to reach a middle ground, we noticed that, while most qdiscs are not handling TCACTCONSUMED, clsact/ingress qdiscs are. With that in mind, we address the issue by only allowing actct to bind to clsact/ingress qdiscs and shared blocks. That way it's still possible to attach actct to egress (albeit only with clsact).

[1]

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

bnxten: set backing store type from query type

bnxthwrmfuncbackingstoreqcapsv2() stores resp->type from the firmware response in ctxm->type and later uses that value to index fixed backing-store metadata arrays such as ctxarr[] and bnxtbstoretotrace[].

ctxm->type is fixed by the current backing-store query type and matches the array index of ctx->ctxarr. Set ctxm->type from the current loop variable instead of depending on resp->type.

Also update the loop to advance type from nextvalidtype in the for statement, which keeps the control flow simpler for non-valid and unchanged entries.

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

cifs: some missing initializations on replay

In several places in the code, we have a label to signify the start of the code where a request can be replayed if necessary. However, some of these places were missing the necessary reinitializations of certain local variables before replay.

This change makes sure that these variables get initialized after the label.

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

clk: rs9: Reserve 8 struct clkhw slots for for 9FGV0841

The 9FGV0841 has 8 outputs and registers 8 struct clkhw, make sure there are 8 slots for those newly registered clkhw pointers, else there is going to be out of bounds write when pointers 4..7 are set into struct rs9driverdata .clkdif[4..7] field.

Since there are other structure members past this struct clkhw pointer array, writing to .clkdif[4..7] fields corrupts both the struct rs9driverdata content and data around it, sometimes without crashing the kernel. However, the kernel does surely crash when the driver is unbound or during suspend.

Fix this, increase the struct clkhw pointer array size to the maximum output count of 9FGV0841, which is the biggest chip that is supported by this driver.

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

media: chips-media: wave5: Fix PM runtime usage count underflow

Replace pmruntimeputsync() with pmruntimedontuseautosuspend() in the remove path to properly pair with pmruntimeuseautosuspend() from probe. This allows pmruntimedisable() to handle reference count cleanup correctly regardless of current suspend state.

The driver calls pmruntimeputsync() unconditionally in remove, but the device may already be suspended due to autosuspend configured in probe. When autosuspend has already suspended the device, the usage count is 0, and pmruntimeputsync() decrements it to -1.

This causes the following warning on module unload:

------------[ cut here ]------------ WARNING: CPU: 1 PID: 963 at kernel/kthread.c:1430 kthreaddestroyworker+0x84/0x98 ... vdec 30210000.video-codec: Runtime PM usage count underflow!

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

thermal: core: Fix thermal zone device registration error path

If thermalzonedeviceregisterwithtrips() fails after registering a thermal zone device, it needs to wait for the tz->removal completion like thermalzonedeviceunregister(), in case user space has managed to take a reference to the thermal zone device's kobject, in which case thermalrelease() may not be called by the error path itself and tz may be freed prematurely.

Add the missing waitforcompletion() call to the thermal zone device registration error path.

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

scsi: ufs: core: Fix SError in ufshcdrtcwork() during UFS suspend

In ufshcdwlsuspend(), canceldelayedworksync() is called to cancel the UFS RTC work, but it is placed after ufshcdvopssuspend(hba, pmop, POSTCHANGE). This creates a race condition where ufshcdrtcwork() can still be running while ufshcdvopssuspend() is executing. When UFSHCDCAPCLKGATING is not supported, the condition !hba->clkgating.activereqs is always true, causing ufshcdupdatertc() to be executed. Since ufshcdvopssuspend() typically performs clock gating operations, executing ufshcdupdatertc() at that moment triggers an SError. The kernel panic trace is as follows:

Kernel panic - not syncing: Asynchronous SError Interrupt Call trace: dumpbacktrace+0xec/0x128 showstack+0x18/0x28 dumpstacklvl+0x40/0xa0 dumpstack+0x18/0x24 panic+0x148/0x374 nmipanic+0x3c/0x8c arm64serrorpanic+0x64/0x8c doserror+0xc4/0xc8 el1h64errorhandler+0x34/0x4c el1h64error+0x68/0x6c el1interrupt+0x20/0x58 el1h64irqhandler+0x18/0x24 el1h64irq+0x68/0x6c ktimeget+0xc4/0x12c ufshcdmcqsqstop+0x4c/0xec ufshcdmcqsqcleanup+0x64/0x1dc ufshcdclearcmd+0x38/0x134 ufshcdissuedevcmd+0x298/0x4d0 ufshcdexecdevcmd+0x1a4/0x1c4 ufshcdqueryattr+0xbc/0x19c ufshcdrtcwork+0x10c/0x1c8 processscheduledworks+0x1c4/0x45c workerthread+0x32c/0x3e8 kthread+0x120/0x1d8 retfromfork+0x10/0x20

Fix this by moving canceldelayedworksync() before the call to ufshcdvopssuspend(hba, pmop, PRECHANGE), ensuring the UFS RTC work is fully completed or cancelled at that point.

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

smb: client: fix queryinfo() replay double-free

A response-bearing attempt can return a replayable error and free its response buffer. If SMB2queryinfoinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.

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

xfs: don't wrap around quota ids in dqiterate

LOLLM noticed that qid is an unsigned 32-bit variable. If it happens to be set to XFSDQIDMAX due to a filesystem that actually has a dquot for IDMAX, then this addition will truncate to zero and the iteration starts over. Fix this by casting to u64.

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

iommufd: Set upper bounds on cache invalidation entrynum and entrylen

iommufdhwptinvalidate() takes a user-controlled entrynum and entrylen, each bounded only by U32MAX. An entrylen beyond the kernel's struct size makes the copy helper verify the extra bytes are zero, scanning that excess in one uninterruptible pass; a multi-gigabyte value over zeroed user memory trips the soft-lockup watchdog.

A large entrynum is the other half, driving the backend invalidation loop with no reschedule. The VT-d nested handler, for one, copies each entry and flushes caches per iteration, pinning the CPU on a non-preemptible kernel.

Cap both in the ioctl. entrylen is held under PAGESIZE, above any request struct, and entrynum under 1 << 19, the order of a hardware invalidation queue and well beyond any real batch, bounding the per-call loop length.

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

smb: client: fix double-free in SMB2ioctl() replay

A response-bearing attempt can return a replayable error and free its response buffer. If SMB2ioctlinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.

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

smb: client: fix double-free in SMB2flush() replay

SMB2flush() keeps its response buffer bookkeeping across replay attempts. If a replayable flush response is received and the retry then fails before cifssendrecv() stores a replacement response, flushexit will free the stale response pointer a second time.

Reinitialize respbuftype and rspiov at the top of the replay loop so cleanup only acts on response state produced by the current attempt. This fixes a double-free without changing replay handling for successful requests.

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

xsk: cache csumstart/csumoffset to fix TOCTOU in xskskbmetadata()

The TX metadata area resides in the UMEM buffer which is memory-mapped and concurrently writable by userspace. In xskskbmetadata(), csumstart and csumoffset are read from shared memory for bounds validation, then read again for skb assignment. A malicious userspace application can race to overwrite these values between the two reads, bypassing the bounds check and causing out-of-bounds memory access during checksum computation in the transmit path.

Fix this by reading csumstart and csumoffset into local variables once, then using the local copies for both validation and assignment.

Note that other metadata fields (flags, launchtime) and the cached csum fields may be mutually inconsistent due to concurrent userspace writes, but this is benign: the only security-critical invariant is that each field's validated value is the same one used, which local caching guarantees.

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

smb: client: fix change notify replay double-free

A response-bearing attempt can return a replayable error and free its response buffer. If SMB2notifyinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.

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

iio: light: veml6075: add bounds check to veml6075itms index

veml6075itms has 5 elements but VEML6075CONFIT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range.

The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption.

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

drm/xe/gucsubmit: fix race around suspendpending

Currently in some testcases we can trigger:

xe 0000:03:00.0: [drm] Assertion execqueuedestroyed(q) failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xegucsubmit.c:1826 xegucscheddonehandler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] ERROR GT1: DEREGISTERDONE: Unexpected engine state 0x00a1, gucid=57

Looking at a snippet of corresponding ftrace for this GuC id we can see:

162.673311: xeschedmsgadd: dev=0000:03:00.0, gt=1 gucid=57, opcode=3 162.673317: xeschedmsgrecv: dev=0000:03:00.0, gt=1 gucid=57, opcode=3 162.673319: xeexecqueueschedulingdisable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, gucid=57, gucstate=0x29, flags=0x0 162.674089: xeexecqueuekill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, gucid=57, gucstate=0x29, flags=0x0 162.674108: xeexecqueueclose: dev=0000:03:00.0, 1:0x2, gt=1, width=1, gucid=57, gucstate=0xa9, flags=0x0 162.674488: xeexecqueueschedulingdone: dev=0000:03:00.0, 1:0x2, gt=1, width=1, gucid=57, gucstate=0xa9, flags=0x0 162.678452: xeexecqueuederegister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, gucid=57, gucstate=0xa1, flags=0x0

It looks like we try to suspend the queue (opcode=3), setting suspendpending and triggering a disablescheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disablescheduling comes back we have now cleared suspendpending when signalling the suspend fence, so the disablescheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue.

To fix this tweak the ordering when handling the response to ensure we don't race with a disablescheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pendingdisable before marking as destroyed.

(cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)

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

accel/ivpu: Fix signed integer truncation in IPC receive

Fix potential buffer overflow where firmware-supplied datasize is cast to signed int before being used in mint(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer.

Change mint(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.

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

tee: shm: fix shm leak in registershmhelper()

registershmhelper() allocates shm before calling ioviternpages(). If ioviternpages() returns 0, the function jumps to errctxput and leaks shm.

This can be triggered by TEEIOCSHMREGISTER with struct teeioctlshmregisterdata where length is 0.

Jump to errfreeshm instead.

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

drm/v3d: Fix use-after-free of CPU job query arrays on error path

The CPU job ioctl's fail label calls kvfree() on cpujob's timestamp and performance query arrays after v3djobcleanup(), which drops the job's last reference and frees cpujob. Reading cpujob at that point is a use-after-free. Also, on the early v3djobinit() failure path, it is a NULL dereference, since v3djobdeallocate() zeroes the local pointer.

In the success path, the arrays are released from the scheduler's .freejob callback, but on the error path, they are freed manually, as the job was never pushed to the scheduler. While the success path deals with this correctly, the fail path doesn't.

On top of that, the manual kvfree() calls only free the array storage; they don't drmsyncobjput() the per-query syncobjs that v3dtimestampqueryinfofree() and v3dperformancequeryinfofree() release on the success path. So the same fail path that triggers the use-after-free also leaks one syncobj reference per query.

Unify the CPU job teardown into the CPU job's kref destructor, mirroring v3drenderjobfree(). The scheduler's .freejob slot reverts to the generic v3dschedjobfree() and the fail label drops the manual kvfree() calls, leaving a single teardown path that is reached from both the scheduler and the ioctl error path. That removes the use-after-free, the NULL dereference, and the syncobj leak by construction.