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:

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

block: Fix page refcounts for unaligned buffers in bioreleasepages()

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:

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:

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:

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 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:

smb: client: fix query directory replay double-free

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

nvme: target: rdma: fix ndev refcount leak on queue connect

nvmetrdmaqueueconnect() calls nvmetrdmafindgetdevice() which acquires a reference on the returned ndev via krefget(). On the path where the host queue backlog is exceeded and the function returns NVMESCCONNECTCTRLBUSY, reference of ndev is not released, leaking the kref.

Fix this by adding a goto to the existing putdevice label before the early return.

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

netfs: Fix netfsinvalidatefolio() to clear dirty bit if all changes gone

If a streaming write is made, this will leave the relevant modified folio in a not-uptodate, but dirty state with a netfsfolio struct hung off of folio->private indicating the dirty range. Subsequently truncating the file such that the dirty data in the folio is removed, but the first part of the folio theoretically remains will cause the netfsfolio struct to be discarded... but will leave the dirty flag set.

If the folio is then read via mmap(), netfsreadfolio() will see that the page is dirty and jump to netfsreadgaps() to fill in the missing bits. netfsreadgaps(), however, expects there to be a netfsfolio struct present and can oops because truncate removed it.

Fix this by calling foliocanceldirty() in netfsinvalidatefolio() in the event that all the dirty data in the folio is erased (as nfs does).

Also add some tracepoints to log modifications to a dirty page.

This can be reproduced with something like:

dd if=/dev/zero of=/xfstest.test/foo bs=1M count=1 umount /xfstest.test mount /xfstest.test xfsio -c "w 0xbbbf 0xf96c" \ -c "truncate 0xbbbf" \ -c "mmap -r 0xb000 0x11000" \ -c "mr 0xb000 0x11000" \ /xfstest.test/foo

with fscaching disabled (otherwise streaming writes are suppressed) and a change to netfsperformwrite() to disallow streaming writes if the fd is open ORDWR:

if (//(file->fmode & FMODEREAD) || <--- comment this out netfsiscacheenabled(ctx)) {

It should be reproducible even without this change, but if prevents the above trivial xfsio command from reproducing it.

Note that the initial dd is important: the file must start out sufficiently large that the zero-point logic doesn't just clear the gaps because it knows there's nothing in the file to read yet. Unmounting and mounting is needed to clear the pagecache (there are other ways to do that that may also work).

This was initially reproduced with the generic/522 xfstest on some patches that remove the FMODEREAD restriction.

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

block: bio-integrity: Fix null-ptr-deref in biointegritymapuser()

pinuserpagesfast() can partially succeed and return the number of pages that were actually pinned. However, the biointegritymapuser() does not handle this partial pinning. This leads to a general protection fault since bvecfrompages() dereferences an unpinned page address, which is 0.

To fix this, add a check to verify that all requested memory is pinned. If partial pinning occurs, unpin the memory and return -EFAULT.

Kernel Oops:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 UID: 0 PID: 1061 Comm: nvme-passthroug Not tainted 7.0.0-11783-g90957f9314e8-dirty #16 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 RIP: 0010:biointegritymapuser.cold+0x1b0/0x9d6

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:

PCI/PM: Drain runtime-idle callbacks before driver removal

A race condition between the .runtimeidle() callback and the .remove() callback in the rtsxpcr PCI driver leads to a kernel crash due to an unhandled page fault [1].

The problem is that rtsxpciruntimeidle() is not expected to be running after pmruntimegetsync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns.

However, if a .runtimeidle() callback is already running when pmruntimegetsync() is called, the latter will notice that the runtime PM status of the device is RPMACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtimeidle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited).

Thus in general, whoever is providing a .runtimeidle() callback needs to protect it from running in parallel with whatever code runs after pmruntimegetsync(). [Note that .runtimeidle() will not start after pmruntimegetsync() has returned, but it may continue running then if it has started earlier.]

One way to address that race condition is to call pmruntimebarrier() after pmruntimegetsync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtimeidle() callback to complete should it be running at that point. A suitable place for doing that is in pcideviceremove() which calls pmruntimegetsync() before removing the driver, so it may as well call pmruntimebarrier() subsequently, which will prevent the race in question from occurring, not just in the rtsxpcr driver, but in any PCI drivers providing .runtimeidle() callbacks.

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

ext4: fix corruption during on-line resize

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2024-35807-2a9e@gregkh/T

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:

powerpc/pseries: Fix potential memleak in paprgetattr()

buf is allocated in paprgetattr(), and krealloc() of buf could fail. We need to free the original buf in the case of failure.

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:

pdscore: fix debugfslookup dentry leak and error handling

debugfslookup() returns a dentry with an elevated reference count that must be released with dput(). The current code discards the returned dentry without calling dput(), causing a reference leak on every firmware reset recovery.

Additionally, when CONFIGDEBUGFS is disabled, debugfslookup() returns ERRPTR(-ENODEV), not NULL. The current check passes for error pointers and would call dput() on an invalid pointer, causing a crash.

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:

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