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

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

A response-bearing attempt can return a replayable error and free its response buffer. If SMB2openinit() 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:

KVM: guestmemfd: Treat memslot binding offset+size as unsigned values

When binding a memslot to a guestmemfd file, treat the offset and size as unsigned values to fix a bug where the sum of the two can result in a false negative when checking for overflow against the size of the file. Passing unsigned values also avoids relying on somewhat obscure checks in other flows for safety, and tracks the offset and size as they are intended to be tracked, as unsigned values.

On 64-bit kernels, the number of pages a memslot contains and thus the size (and offset) of its guestmemfd binding are unsigned 64-bit values. Taking the offset+size as an lofft instead of a uofft inadvertently converts the unsigned value to a signed value if the offset and/or size is massive.

Locally storing the offset and size as signed values is benign in and of itself (though even that is extremely difficult to discern), but operating on their sum is not.

For the offset, KVM explicitly checks against a negative value, which might seem like a bug as KVM could incorrectly reject a legitimate binding, but that's not actually the case as KVMCREATEGUESTMEMFD takes a signed value for its size, i.e. a would-be-negative offset is also greater than the maximum possible size of any guestmemfd file.

Regarding the size, while KVM lacks an explicit check for a negative value, i.e. seemingly has a flawed overflow check, KVM restricts the number of pages in a single memslot to the largest positive signed 32-bit value:

if (id < KVMUSERMEMSLOTS && (mem->memorysize >> PAGESHIFT) > KVMMEMMAXNRPAGES) return -EINVAL;

and so that maximum "size" will ever be is 0x7fffffff000.

The sum of the two is, however, problematic. While the size is restricted by KVM's memslot logic, the offset is not, i.e. the offset is completely unchecked until the "offset + size > isizeread(inode)" check. If the offset is the (nearly) largest possible positive value, then adding size to the offset can result in a signed, negative 64-bit value. When compared against the size of the file (guaranteed to be positive), the negative sum is always smaller, and KVM incorrectly allows the absurd offset.

Opportunistically add missing includes in kvmmm.h (instead of relying on its parents).

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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

lsm: hold credguardmutex for lsmsetselfattr()

Just as procpidattrwrite() already does before calling the LSM hook. This only matters for SELinux and AppArmor which check whether the process is being ptraced and if so, whether to allow the transition.

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.

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:

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:

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:

drm/xe/dma-buf: handle empty bo and UAF races

There look to be some nasty races here when triggering the invalidatemappings hook:

1) We do xeboalloc() followed by the attach, before the actual full bo init step in xedmabufinitobj(). However the bo is visible on the attachments list after the attach. This is bad since exporter driver, say amdgpu, can at any time call back into our invalidatemappings hook, with an empty/bogus bo, leading to potential bugs/crashes.

2) Similar to 1) but here we get a UAF, when the invalidatemappings hook is triggered. For example, we get as far as xeboinitlocked() but this fails in some way. But here the bo will be freed on error, but we still have it attached from dma-buf pov, so if the invalidatemappings is now triggered then the bo we access is gone and we trigger UAF and more bugs/crashes.

To fix this, move the attach step until after we actually have a fully set up buffer object. Note that the bo is not published to userspace until later, so not sure what the comment "Don't publish the bo until we have a valid attachment", is referring to.

We have at least two different customers reporting hitting a NULL ptr deref in evictflags when importing something from amdgpu, followed by triggering the evict flow. Hit rate is also pretty low, which would hint at some kind of race, so something like 1) or 2) might explain this.

v2: - Shuffle the order of the ops slightly (no functional change) - Improve the comment to better explain the ordering (Matt B)

(cherry picked from commit af1f2ad0c59fe4e2f924c526f66e968289d77971)

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

drm/xe: Fix dma-buf attachment leak in xegemprimeimport()

When xedmabufinitobj() fails, the attachment from dmabufdynamicattach() is not detached. Add dmabufdetach() before returning the error. Note: we cannot use goto outerr here because xedmabufinitobj() already frees bo on failure, and outerr would double-free it.

(cherry picked from commit a828eb185aac41800df8eae4b60501ccc0dbbe51)

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

RDMA/mana: Remove user triggerable WARNON() in manaibcreateqprss()

Sashiko points out that the user can specify WQs sharing the same CQ as a part of the uAPI and this will trigger the WARNON() then go on to corrupt the kernel.

Just reject it outright and fail the QP creation.

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:

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:

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:

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:

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:

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:

crypto: iaa - Fix out-of-bounds index in findemptyiaacompressionmode

The local variable 'i' is initialized with -EINVAL, but the for loop immediately overwrites it and -EINVAL is never returned.

If no empty compression mode can be found, the function would return the out-of-bounds index IAACOMPMODESMAX, which would cause an invalid array access in addiaacompressionmode().

Fix both issues by returning either a valid index or -EINVAL.

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:

accel/ivpu: Fix race condition when unbinding BOs

Fix 'Memory manager not clean during takedown' warning that occurs when ivpugembofree() removes the BO from the BOs list before it gets unmapped. Then fileprivunbind() triggers a warning in drmmmtakedown() during context teardown.

Protect the unmapping sequence with bolistlock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by fileprivunbind().

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

net: xilinx: axienet: Add error handling for RX metadata pointer retrieval

Add proper error checking for dmaenginedescgetmetadataptr() which can return an error pointer and lead to potential crashes or undefined behaviour if the pointer retrieval fails.

Properly handle the error by unmapping DMA buffer, freeing the skb and returning early to prevent further processing with invalid data.

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

accel/ivpu: Prevent recovery work from being queued during device removal

Use disableworksync() instead of cancelworksync() in ivpudevfini() to ensure that no new recovery work items can be queued after device removal has started. Previously, recovery work could be scheduled even after canceling existing work, potentially leading to use-after-free bugs if recovery accessed freed resources.

Rename ivpupmcancelrecovery() to ivpupmdisablerecovery() to better reflect its new behavior.

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

netfilter: brnetfilter: do not check confirmed bit in brnflocalin() after confirm

When send a broadcast packet to a tap device, which was added to a bridge, brnflocalin() is called to confirm the conntrack. If another conntrack with the same hash value is added to the hash table, which can be triggered by a normal packet to a non-bridge device, the below warning may happen.

------------[ cut here ]------------ WARNING: CPU: 1 PID: 96 at net/bridge/brnetfilterhooks.c:632 brnflocalin+0x168/0x200 CPU: 1 UID: 0 PID: 96 Comm: tapsend Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary) RIP: 0010:brnflocalin+0x168/0x200 Call Trace: <TASK> nfhookslow+0x3e/0xf0 brpassframeup+0x103/0x180 brhandleframefinish+0x2de/0x5b0 brnfhookthresh+0xc0/0x120 brnfpreroutingfinish+0x168/0x3a0 brnfprerouting+0x237/0x5e0 brhandleframe+0x1ec/0x3c0 netifreceiveskbcore+0x225/0x1210 netifreceiveskbonecore+0x37/0xa0 netifreceiveskb+0x36/0x160 tungetuser+0xa54/0x10c0 tunchrwriteiter+0x65/0xb0 vfswrite+0x305/0x410 ksyswrite+0x60/0xd0 dosyscall64+0xa4/0x260 entrySYSCALL64afterhwframe+0x77/0x7f </TASK> ---[ end trace 0000000000000000 ]---

To solve the hash conflict, nfctresolveclash() try to merge the conntracks, and update skb->nfct. However, brnflocalin() still use the old ct from local variable 'nfct' after confirm(), which leads to this warning.

If confirm() does not insert the conntrack entry and return NFDROP, the warning may also occur. There is no need to reserve the WARNONONCE, just remove it.

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

ice: fix NULL access of tx->inuse in icelltsintr

Recent versions of the E810 firmware have support for an extra interrupt to handle report of the "low latency" Tx timestamps coming from the specialized low latency firmware interface. Instead of polling the registers, software can wait until the low latency interrupt is fired.

This logic makes use of the Tx timestamp tracking structure, iceptptx, as it uses the same "ready" bitmap to track which Tx timestamps complete.

Unfortunately, the icelltsintr() function does not check if the tracker is initialized before its first access. This results in NULL dereference or use-after-free bugs similar to the issues fixed in the iceptptsirq() function.

Fix this by only checking the inuse bitmap (and other fields) if the tracker is marked as initialized. The reset flow will clear the init field under lock before it tears the tracker down, thus preventing any use-after-free or NULL access.

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

efi: stmm: Fix incorrect buffer allocation method

The communication buffer allocated by setupmmhdr() is later on passed to teeshmregisterkernelbuf(). The latter expects those buffers to be contiguous pages, but setupmmhdr() just uses kmalloc(). That can cause various corruptions or BUGs, specifically since commit 9aec2fb0fd5e ("slab: allocate frozen pages"), though it was broken before as well.

Fix this by using allocpagesexact() instead of kmalloc().

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

RISC-V: KVM: fix stack overrun when loading vlenb

The userspace load can put up to 2048 bits into an xlen bit stack buffer. We want only xlen bits, so check the size beforehand.

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

drm/xe: Make dma-fences compliant with the safe access rules

Xe can free some of the data pointed to by the dma-fences it exports. Most notably the timeline name can get freed if userspace closes the associated submit queue. At the same time the fence could have been exported to a third party (for example a syncfence fd) which will then cause an use- after-free on subsequent access.

To make this safe we need to make the driver compliant with the newly documented dma-fence rules. Driver has to ensure a RCU grace period between signalling a fence and freeing any data pointed to by said fence.

For the timeline name we simply make the queue be freed via kfreercu and for the shared lock associated with multiple queues we add a RCU grace period before freeing the per GT structure holding the lock.

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

drm/imagination: Fix kernel crash when hard resetting the GPU

The GPU hard reset sequence calls pmruntimeforcesuspend() and pmruntimeforceresume(), which according to their documentation should only be used during system-wide PM transitions to sleep states.

The main issue though is that depending on some internal runtime PM state as seen by pmruntimeforcesuspend() (whether the usage count is <= 1), pmruntimeforceresume() might not resume the device unless needed. If that happens, the runtime PM resume callback pvrpowerdeviceresume() is not called, the GPU clocks are not re-enabled, and the kernel crashes on the next attempt to access GPU registers as part of the power-on sequence.

Replace calls to pmruntimeforcesuspend() and pmruntimeforceresume() with direct calls to the driver's runtime PM callbacks, pvrpowerdevicesuspend() and pvrpowerdeviceresume(), to ensure clocks are re-enabled and avoid the kernel crash.

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

drm/xe/pf: Clear all LMTT pages on alloc

Our LMEM buffer objects are not cleared by default on alloc and during VF provisioning we only setup LMTT PTEs for the actually provisioned LMEM range. But beyond that valid range we might leave some stale data that could either point to some other VFs allocations or even to the PF pages.

Explicitly clear all new LMTT page to avoid the risk that a malicious VF would try to exploit that gap.

While around add asserts to catch any undesired PTE overwrites and low-level debug traces to track LMTT PT life-cycle.

(cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)

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

HID: wacom: fix crash in wacomaesbatteryhandler()

Commit fd2a9b29dc9c ("HID: wacom: Remove AES powersupply after extended inactivity") introduced wacomaesbatteryhandler() which is scheduled as a delayed work (aesbatterywork).

In wacomremove(), aesbatterywork is not canceled. Consequently, if the device is removed while aesbatterywork is still pending, then hard crashes or "Oops: general protection fault..." are experienced when wacomaesbatteryhandler() is finally called. E.g., this happens with built-in USB devices after resume from hibernate when aesbatterywork was still pending at the time of hibernation.

So, take care to cancel aesbatterywork in wacomremove().