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:

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:

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:

serial: sc16is7xx: fix TX fifo corruption

Sometimes, when a packet is received on channel A at almost the same time as a packet is about to be transmitted on channel B, we observe with a logic analyzer that the received packet on channel A is transmitted on channel B. In other words, the Tx buffer data on channel B is corrupted with data from channel A.

The problem appeared since commit 4409df5866b7 ("serial: sc16is7xx: change EFR lock to operate on each channels"), which changed the EFR locking to operate on each channel instead of chip-wise.

This commit has introduced a regression, because the EFR lock is used not only to protect the EFR registers access, but also, in a very obscure and undocumented way, to protect access to the data buffer, which is shared by the Tx and Rx handlers, but also by each channel of the IC.

Fix this regression first by switching to kfifooutlinearptr() in sc16is7xxhandletx() to eliminate the need for a shared Rx/Tx buffer.

Secondly, replace the chip-wise Rx buffer with a separate Rx buffer for each channel.

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:

drm/vmwgfx: Fix the lifetime of the bo cursor memory

The cleanup can be dispatched while the atomic update is still active, which means that the memory acquired in the atomic update needs to not be invalidated by the cleanup. The buffer objects in vmwplanestate instead of using the builtin mapandcache were trying to handle the lifetime of the mapped memory themselves, leading to crashes.

Use the mapandcache instead of trying to manage the lifetime of the buffer objects held by the vmwplanestate.

Fixes kernel oops'es in IGT's kmscursorlegacy forked-bo.

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

md/dm-raid: don't call mdreapsyncthread() directly

Currently mdreapsyncthread() is called from raidmessage() directly without holding 'reconfigmutex', this is definitely unsafe because mdreapsyncthread() can change many fields that is protected by 'reconfigmutex'.

However, hold 'reconfigmutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozensyncthread() to fix deadlock").

Fix this problem by using stopsyncthread() to unregister syncthread, like md/raid did.

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

nvme: fix reconnection fail due to reserved tag allocation

The Linux kernel CVE team has assigned CVE-2024-27435 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051710-CVE-2024-27435-c465@gregkh/T

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.

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:

crypto: qat - resolve race condition during AER recovery

During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the resetdata structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the resetdata structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug.

This results in a KFENCE bug notice.

BUG: KFENCE: use-after-free read in adfdeviceresetworker+0x38/0xa0 [intelqat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adfdeviceresetworker+0x38/0xa0 [intelqat] processonework+0x173/0x340

To resolve this race condition, the memory associated to the container of the workstruct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completiondone() function.

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

drm/amdgpu: Fix potential out-of-bounds access in 'amdgpudiscoveryregbaseinit()'

The issue arises when the array 'adev->vcn.vcnconfig' is accessed before checking if the index 'adev->vcn.numvcninst' is within the bounds of the array.

The fix involves moving the bounds check before the array access. This ensures that 'adev->vcn.numvcninst' is within the bounds of the array before it is used as an index.

Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpudiscovery.c:1289 amdgpudiscoveryregbaseinit() error: testing array offset 'adev->vcn.numvcninst' after use.

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

USB: core: Fix deadlock in port "disable" sysfs attribute

The show and store callback routines for the "disable" sysfs attribute file in port.c acquire the device lock for the port's parent hub device. This can cause problems if another process has locked the hub to remove it or change its configuration:

Removing the hub or changing its configuration requires the hub interface to be removed, which requires the port device to be removed, and devicedel() waits until all outstanding sysfs attribute callbacks for the ports have returned. The lock can't be released until then.

But the disableshow() or disablestore() routine can't return until after it has acquired the lock.

The resulting deadlock can be avoided by calling sysfsbreakactiveprotection(). This will cause the sysfs core not to wait for the attribute's callback routine to return, allowing the removal to proceed. The disadvantage is that after making this call, there is no guarantee that the hub structure won't be deallocated at any moment. To prevent this, we have to acquire a reference to it first by calling hubget().

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

scsi: qla2xxx: Fix double free of the ha->vpmap pointer

Coverity scan reported potential risk of double free of the pointer ha->vpmap. ha->vpmap was freed in qla2x00memalloc(), and again freed in function qla2x00memfree(ha).

Assign NULL to vpmap and kfree take care of NULL.

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

nfs: fix UAF in direct writes

In production we have been hitting the following warning consistently

------------[ cut here ]------------ refcountt: underflow; use-after-free. WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcountwarnsaturate+0x9c/0xe0 Workqueue: nfsiod nfsdirectwriteschedulework [nfs] RIP: 0010:refcountwarnsaturate+0x9c/0xe0 PKRU: 55555554 Call Trace: ? warn+0x9f/0x130 ? refcountwarnsaturate+0x9c/0xe0 ? reportbug+0xcc/0x150 ? handlebug+0x3d/0x70 ? excinvalidop+0x16/0x40 ? asmexcinvalidop+0x16/0x20 ? refcountwarnsaturate+0x9c/0xe0 nfsdirectwriteschedulework+0x237/0x250 [nfs] processonework+0x12f/0x4a0 workerthread+0x14e/0x3b0 ? ZSTDgetCParamsinternal+0x220/0x220 kthread+0xdc/0x120 ? btfnamevalid+0xa0/0xa0 retfromfork+0x1f/0x30

This is because we're completing the nfsdirectrequest twice in a row.

The source of this is when we have our commit requests to submit, we process them and send them off, and then in the completion path for the commit requests we have

if (nfscommitend(cinfo.mds)) nfsdirectwritecomplete(dreq);

However since we're submitting asynchronous requests we sometimes have one that completes before we submit the next one, so we end up calling complete on the nfsdirectrequest twice.

The only other place we use nfsgenericcommitlist() is in nfscommitinode, which wraps this call in a

nfscommitbegin(); nfscommitend();

Which is a common pattern for this style of completion handling, one that is also repeated in the direct code with getdreq()/putdreq() calls around where we process events as well as in the completion paths.

Fix this by using the same pattern for the commit requests.

Before with my 200 node rocksdb stress running this warning would pop every 10ish minutes. With my patch the stress test has been running for several hours without popping.

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).

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:

ksmbd: fix slab-out-of-bounds in smbstrndupfromutf16()

If ->NameOffset of smb2createreq is smaller than Buffer offset of smb2createreq, slab-out-of-bounds read can happen from smb2open. This patch set the minimum value of the name offset to the buffer offset to validate name length of smb2createreq().

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

x86/entry32: Clear CPU buffers after register restore in NMI return

CPU buffers are currently cleared after call to excnmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data.

Move CLEARCPUBUFFERS after RESTOREALLNMI.

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

vfio/pci: Create persistent INTx handler

A vulnerability exists where the eventfd for INTx signaling can be deconfigured, which unregisters the IRQ handler but still allows eventfds to be signaled with a NULL context through the SETIRQS ioctl or through unmask irqfd if the device interrupt is pending.

Ideally this could be solved with some additional locking; the igate mutex serializes the ioctl and config space accesses, and the interrupt handler is unregistered relative to the trigger, but the irqfd path runs asynchronous to those. The igate mutex cannot be acquired from the atomic context of the eventfd wake function. Disabling the irqfd relative to the eventfd registration is potentially incompatible with existing userspace.

As a result, the solution implemented here moves configuration of the INTx interrupt handler to track the lifetime of the INTx context object and irqtype configuration, rather than registration of a particular trigger eventfd. Synchronization is added between the ioctl path and eventfdsignal() wrapper such that the eventfd trigger can be dynamically updated relative to in-flight interrupts or irqfd callbacks.

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

net: iptunnel: make sure to pull inner header in iptunnelrcv()

Apply the same fix than ones found in :

8d975c15c0cd ("ip6tunnel: make sure to pull inner header in ip6tnlrcv()") 1ca1ba465e55 ("geneve: make sure to pull inner header in geneverx()")

We have to save skb->networkheader in a temporary variable in order to be able to recompute the networkheader pointer after a pskbinetmaypull() call.

pskbinetmaypull() makes sure the needed headers are in skb->head.

syzbot reported: 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 IPECNdecapsulate include/net/inetecn.h:302 [inline] BUG: KMSAN: uninit-value in iptunnelrcv+0xed9/0x2ed0 net/ipv4/iptunnel.c:409 INETECNdecapsulate include/net/inetecn.h:253 [inline] INETECNdecapsulate include/net/inetecn.h:275 [inline] IPECNdecapsulate include/net/inetecn.h:302 [inline] iptunnelrcv+0xed9/0x2ed0 net/ipv4/iptunnel.c:409 ipgrercv+0x9bc/0xbc0 net/ipv4/ipgre.c:389 ipgrercv net/ipv4/ipgre.c:411 [inline] grercv+0x423/0x19f0 net/ipv4/ipgre.c:447 grercv+0x2a4/0x390 net/ipv4/gredemux.c:163 ipprotocoldeliverrcu+0x264/0x1300 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x2b8/0x440 net/ipv4/ipinput.c:233 NFHOOK include/linux/netfilter.h:314 [inline] iplocaldeliver+0x21f/0x490 net/ipv4/ipinput.c:254 dstinput include/net/dst.h:461 [inline] iprcvfinish net/ipv4/ipinput.c:449 [inline] NFHOOK include/linux/netfilter.h:314 [inline] iprcv+0x46f/0x760 net/ipv4/ipinput.c:569 netifreceiveskbonecore net/core/dev.c:5534 [inline] netifreceiveskb+0x1a6/0x5a0 net/core/dev.c:5648 netifreceiveskbinternal net/core/dev.c:5734 [inline] netifreceiveskb+0x58/0x660 net/core/dev.c:5793 tunrxbatched+0x3ee/0x980 drivers/net/tun.c:1556 tungetuser+0x53b9/0x66e0 drivers/net/tun.c:2009 tunchrwriteiter+0x3af/0x5d0 drivers/net/tun.c:2055 callwriteiter include/linux/fs.h:2087 [inline] newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0xb6b/0x1520 fs/readwrite.c:590 ksyswrite+0x20f/0x4c0 fs/readwrite.c:643 dosyswrite fs/readwrite.c:655 [inline] sesyswrite fs/readwrite.c:652 [inline] x64syswrite+0x93/0xd0 fs/readwrite.c:652 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

Uninit was created at: allocpages+0x9a6/0xe00 mm/pagealloc.c:4590 allocpagesmpol+0x62b/0x9d0 mm/mempolicy.c:2133 allocpages+0x1be/0x1e0 mm/mempolicy.c:2204 skbpagefragrefill+0x2bf/0x7c0 net/core/sock.c:2909 tunbuildskb drivers/net/tun.c:1686 [inline] tungetuser+0xe0a/0x66e0 drivers/net/tun.c:1826 tunchrwriteiter+0x3af/0x5d0 drivers/net/tun.c:2055 callwriteiter include/linux/fs.h:2087 [inline] newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0xb6b/0x1520 fs/readwrite.c:590 ksyswrite+0x20f/0x4c0 fs/readwrite.c:643 dosyswrite fs/readwrite.c:655 [inline] sesyswrite fs/readwrite.c:652 [inline] x64syswrite+0x93/0xd0 fs/readwrite.c:652 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

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:

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:

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:

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.