f2fs: fix ISCHECKPOINTED flag inconsistency issue caused by concurrent atomic commit and checkpoint writes

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

gve: Fix stats report corruption on queue count change

The driver and the NIC share a region in memory for stats reporting. The NIC calculates its offset into this region based on the total size of the stats region and the size of the NIC's stats.

When the number of queues is changed, the driver's stats region is resized. If the queue count is increased, the NIC can write past the end of the allocated stats region, causing memory corruption. If the queue count is decreased, there is a gap between the driver and NIC stats, leading to incorrect stats reporting.

This change fixes the issue by allocating stats region with maximum size, and the offset calculation for NIC stats is changed to match with the calculation of the NIC.

btrfs: do not free data reservation in fallback from inline due to -ENOSPC

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

perf/core: Fix refcount bug and potential UAF in perfmmap

Syzkaller reported a refcountt: addition on 0; use-after-free warning in perfmmap.

The issue is caused by a race condition between a failing mmap() setup and a concurrent mmap() on a dependent event (e.g., using output redirection).

In perfmmap(), the ringbuffer (rb) is allocated and assigned to event->rb with the mmapmutex held. The mutex is then released to perform maprange().

If maprange() fails, perfmmapclose() is called to clean up. However, since the mutex was dropped, another thread attaching to this event (via inherited events or output redirection) can acquire the mutex, observe the valid event->rb pointer, and attempt to increment its reference count. If the cleanup path has already dropped the reference count to zero, this results in a use-after-free or refcount saturation warning.

Fix this by extending the scope of mmapmutex to cover the maprange() call. This ensures that the ring buffer initialization and mapping (or cleanup on failure) happens atomically effectively, preventing other threads from accessing a half-initialized or dying ring buffer.

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

RDMA/siw: Fix potential NULL pointer dereference in header processing

If siwgethdr() returns -EINVAL before setrxfpducontext(), qp->rxfpdu can be NULL. The error path in siwtcprxdata() dereferences qp->rxfpdu->moreddpsegs without checking, which may lead to a NULL pointer deref. Only check moreddpsegs when rxfpdu is present.

KASAN splat: [ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7] [ 101.385869] RIP: 0010:siwtcprxdata+0x13ad/0x1e50

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

RDMA/umad: Reject negative datalen in ibumadwrite

ibumadwrite computes datalen from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, datalen can become negative and reach ibcreatesendmad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in allocsendrmpplist().

Add an explicit check to reject negative datalen before creating the send buffer.

KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ibcreatesendmad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spraythread/102 [ 211.365867] ibcreatesendmad+0xa01/0x11b0 [ 211.365887] ibumadwrite+0x853/0x1c80

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

f2fs: fix out-of-bounds access in sysfs attribute read/write

Some f2fs sysfs attributes suffer from out-of-bounds memory access and incorrect handling of integer values whose size is not 4 bytes.

For example: vm:~# echo 65537 > /sys/fs/f2fs/vde/carveout vm:~# cat /sys/fs/f2fs/vde/carveout 65537 vm:~# echo 4294967297 > /sys/fs/f2fs/vde/atgcagethreshold vm:~# cat /sys/fs/f2fs/vde/atgcagethreshold 1

carveout maps to {struct f2fssbinfo}->carveout, which is a 8-bit integer. However, the sysfs interface allows setting it to a value larger than 255, resulting in an out-of-range update.

atgcagethreshold maps to {struct atgcmanagement}->agethreshold, which is a 64-bit integer, but its sysfs interface cannot correctly set values larger than UINTMAX.

The root causes are: 1. sbistore() treats all default values as unsigned int, which prevents updating integers larger than 4 bytes and causes out-of-bounds writes for integers smaller than 4 bytes.

2. f2fssbishow() also assumes all default values are unsigned int, leading to out-of-bounds reads and incorrect access to integers larger than 4 bytes.

This patch introduces {struct f2fsattr}->size to record the actual size of the integer associated with each sysfs attribute. With this information, sysfs read and write operations can correctly access and update values according to their real data size, avoiding memory corruption and truncation.

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

smb: client: split cachedfid bitfields to avoid shared-byte RMW races

isopen, haslease and onlist are stored in the same bitfield byte in struct cachedfid but are updated in different code paths that may run concurrently. Bitfield assignments generate byte read–modify–write operations (e.g. orb $mask, addr on x8664), so updating one flag can restore stale values of the others.

A possible interleaving is: CPU1: load old byte (haslease=1, onlist=1) CPU2: clear both flags (store 0) CPU1: RMW store (old | ISOPEN) -> reintroduces cleared bits

To avoid this class of races, convert these flags to separate bool fields.

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

ALSA: usb-audio: Prevent excessive number of frames

In this case, the user constructed the parameters with maxpacksize 40 for rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffer size for each data URB is maxpacksize packets, which in this example is 40 6 = 240; When the user performs a write operation to send audio data into the ALSA PCM playback stream, the calculated number of frames is packsize[0] packets = 264, which exceeds the allocated URB buffer size, triggering the out-of-bounds (OOB) issue reported by syzbot [1].

Added a check for the number of single data URB frames when calculating the number of frames to prevent [1].

[1] BUG: KASAN: slab-out-of-bounds in copytourb+0x261/0x460 sound/usb/pcm.c:1487 Write of size 264 at addr ffff88804337e800 by task syz.0.17/5506 Call Trace: copytourb+0x261/0x460 sound/usb/pcm.c:1487 prepareplaybackurb+0x953/0x13d0 sound/usb/pcm.c:1611 prepareoutboundurb+0x377/0xc50 sound/usb/endpoint.c:333

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

net/sched: clsu32: use skbheaderpointercareful()

skbheaderpointer() does not fully validate negative @offset values.

Use skbheaderpointercareful() instead.

GangMin Kim provided a report and a repro fooling u32classify():

BUG: KASAN: slab-out-of-bounds in u32classify+0x1180/0x11b0 net/sched/clsu32.c:221

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

rustbinder: correctly handle FDA objects of length zero

Fix a bug where an empty FDA (fd array) object with 0 fds would cause an out-of-bounds error. The previous implementation used skip == 0 to mean "this is a pointer fixup", but 0 is also the correct skip length for an empty FDA. If the FDA is at the end of the buffer, then this results in an attempt to write 8-bytes out of bounds. This is caught and results in an EINVAL error being returned to userspace.

The pattern of using skip == 0 as a special value originates from the C-implementation of Binder. As part of fixing this bug, this pattern is replaced with a Rust enum.

I considered the alternate option of not pushing a fixup when the length is zero, but I think it's cleaner to just get rid of the zero-is-special stuff.

The root cause of this bug was diagnosed by Gemini CLI on first try. I used the following prompt:

There appears to be a bug in @drivers/android/binder/thread.rs where the Fixups oob bug is triggered with 316 304 316 324. This implies that we somehow ended up with a fixup where buffer A has a pointer to buffer B, but the pointer is located at an index in buffer A that is out of bounds. Please investigate the code to find the bug. You may compare with @drivers/android/binder.c that implements this correctly.

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

ALSA: aloop: Fix racy access at PCM trigger

The PCM trigger callback of aloop driver tries to check the PCM state and stop the stream of the tied substream in the corresponding cable. Since both check and stop operations are performed outside the cable lock, this may result in UAF when a program attempts to trigger frequently while opening/closing the tied stream, as spotted by fuzzers.

For addressing the UAF, this patch changes two things: - It covers the most of code in loopbackcheckformat() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses. - In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF.

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

dmaengine: mmppdma: Fix race condition in mmppdmaresidue()

Add proper locking in mmppdmaresidue() to prevent use-after-free when accessing descriptor list and descriptor contents.

The race occurs when multiple threads call txstatus() while the tasklet on another CPU is freeing completed descriptors:

CPU 0 CPU 1 ----- ----- mmppdmatxstatus() mmppdmaresidue() -> NO LOCK held listforeachentry(sw, ..) DMA interrupt dmadotasklet() -> spinlock(&desclock) listmove(sw->node, ...) spinunlock(&desclock) | dmapoolfree(sw) <- FREED! -> access sw->desc <- UAF!

This issue can be reproduced when running dmatest on the same channel with multiple threads (threadsperchan > 1).

Fix by protecting the chainrunning list iteration and descriptor access with the chan->desclock spinlock.

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

mptcp: fix race in mptcppmnlflushaddrsdoit()

syzbot and Eulgyu Kim reported crashes in mptcppmnlgetlocalid() and/or mptcppmnlisbackup()

Root cause is listspliceinit() in mptcppmnlflushaddrsdoit() which is not RCU ready.

listspliceinitrcu() can not be called here while holding pernet->lock spinlock.

Many thanks to Eulgyu Kim for providing a repro and testing our patches.

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

gpio: virtuser: fix UAF in configfs release path

The gpio-virtuser configfs release path uses guard(mutex) to protect the device structure. However, the device is freed before the guard cleanup runs, causing mutexunlock() to operate on freed memory.

Specifically, gpiovirtuserdeviceconfiggrouprelease() destroys the mutex and frees the device while still inside the guard(mutex) scope. When the function returns, the guard cleanup invokes mutexunlock(&dev->lock), resulting in a slab use-after-free.

Limit the mutex lifetime by using a scopedguard() only around the activation check, so that the lock is released before mutexdestroy() and kfree() are called.

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

nvmet: fix race in nvmetbiodone() leading to NULL pointer dereference

There is a race condition in nvmetbiodone() that can cause a NULL pointer dereference in blkcgroupbiostart():

1. nvmetbiodone() is called when a bio completes 2. nvmetreqcomplete() is called, which invokes req->ops->queueresponse(req) 3. The queueresponse callback can re-queue and re-submit the same request 4. The re-submission reuses the same inlinebio from nvmetreq 5. Meanwhile, nvmetreqbioput() (called after nvmetreqcomplete) invokes biouninit() for inlinebio, which sets bio->biblkg to NULL 6. The re-submitted bio enters submitbionoacctnocheck() 7. blkcgroupbiostart() dereferences bio->biblkg, causing a crash:

BUG: kernel NULL pointer dereference, address: 0000000000000028 #PF: supervisor read access in kernel mode RIP: 0010:blkcgroupbiostart+0x10/0xd0 Call Trace: submitbionoacctnocheck+0x44/0x250 nvmetbdevexecuterw+0x254/0x370 [nvmet] processonework+0x193/0x3c0 workerthread+0x281/0x3a0

Fix this by reordering nvmetbiodone() to call nvmetreqbioput() BEFORE nvmetreqcomplete(). This ensures the bio is cleaned up before the request can be re-submitted, preventing the race condition.

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

iommu/sva: invalidate stale IOTLB entries for kernel address space

Introduce a new IOMMU interface to flush IOTLB paging cache entries for the CPU kernel address space. This interface is invoked from the x86 architecture code that manages combined user and kernel page tables, specifically before any kernel page table page is freed and reused.

This addresses the main issue with vfree() which is a common occurrence and can be triggered by unprivileged users. While this resolves the primary problem, it doesn't address some extremely rare case related to memory unplug of memory that was present as reserved memory at boot, which cannot be triggered by unprivileged users. The discussion can be found at the link below.

Enable SVA on x86 architecture since the IOMMU can now receive notification to flush the paging cache before freeing the CPU kernel page table pages.

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

net/sched: qfq: Use clisactive to determine whether class is active in qfqrmfromag

This is more of a preventive patch to make the code more consistent and to prevent possible exploits that employ child qlen manipulations on qfq. use clisactive instead of relying on the child qdisc's qlen to determine class activation.

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

bonding: limit BONDMODE8023AD to Ethernet devices

BONDMODE8023AD makes sense for ARPHRDETHER only.

syzbot reported:

BUG: KASAN: global-out-of-bounds in hwaddrcreate net/core/devaddrlists.c:63 [inline] BUG: KASAN: global-out-of-bounds in hwaddraddex+0x25d/0x760 net/core/devaddrlists.c:118 Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497

CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full) Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: <TASK> dumpstacklvl+0xe8/0x150 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xca/0x240 mm/kasan/report.c:482 kasanreport+0x118/0x150 mm/kasan/report.c:595 checkregioninline mm/kasan/generic.c:-1 [inline] kasancheckrange+0x2b0/0x2c0 mm/kasan/generic.c:200 asanmemcpy+0x29/0x70 mm/kasan/shadow.c:105 hwaddrcreate net/core/devaddrlists.c:63 [inline] hwaddraddex+0x25d/0x760 net/core/devaddrlists.c:118 devmcadd net/core/devaddrlists.c:868 [inline] devmcadd+0xa1/0x120 net/core/devaddrlists.c:886 bondenslave+0x2b8b/0x3ac0 drivers/net/bonding/bondmain.c:2180 dosetmaster+0x533/0x6d0 net/core/rtnetlink.c:2963 dosetlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165 rtnlchangelink net/core/rtnetlink.c:3776 [inline] rtnlnewlink net/core/rtnetlink.c:3935 [inline] rtnlnewlink+0x161c/0x1c90 net/core/rtnetlink.c:4072 rtnetlinkrcvmsg+0x7cf/0xb70 net/core/rtnetlink.c:6958 netlinkrcvskb+0x208/0x470 net/netlink/afnetlink.c:2550 netlinkunicastkernel net/netlink/afnetlink.c:1318 [inline] netlinkunicast+0x82f/0x9e0 net/netlink/afnetlink.c:1344 netlinksendmsg+0x805/0xb30 net/netlink/afnetlink.c:1894 socksendmsgnosec net/socket.c:727 [inline] socksendmsg+0x21c/0x270 net/socket.c:742 syssendmsg+0x505/0x820 net/socket.c:2592 syssendmsg+0x21f/0x2a0 net/socket.c:2646 syssendmsg+0x164/0x220 net/socket.c:2678 dosyscall32irqson arch/x86/entry/syscall32.c:83 [inline] dofastsyscall32+0x1dc/0x560 arch/x86/entry/syscall32.c:307 dofastsyscall32+0x34/0x80 arch/x86/entry/syscall32.c:332 entrySYSENTERcompatafterhwframe+0x84/0x8e </TASK>

The buggy address belongs to the variable: lacpdumcastaddr+0x0/0x40

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

gue: Fix skb memleak with inner IP protocol 0.

syzbot reported skb memleak below. [0]

The repro generated a GUE packet with its inner protocol 0.

gueudprecv() returns -guehdr->protoctype for "resubmit" in ipprotocoldeliverrcu(), but this only works with non-zero protocol number.

Let's drop such packets.

Note that 0 is a valid number (IPv6 Hop-by-Hop Option).

I think it is not practical to encap HOPOPT in GUE, so once someone starts to complain, we could pass down a resubmit flag pointer to distinguish two zeros from the upper layer:

no error resubmit HOPOPT

[0] BUG: memory leak unreferenced object 0xffff888109695a00 (size 240): comm "syz.0.17", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleakallocrecursive include/linux/kmemleak.h:44 [inline] slabpostallochook mm/slub.c:4958 [inline] slaballocnode mm/slub.c:5263 [inline] kmemcacheallocnoprof+0x3b4/0x590 mm/slub.c:5270 buildskb+0x23/0x60 net/core/skbuff.c:474 buildskb+0x20/0x190 net/core/skbuff.c:490 tunbuildskb drivers/net/tun.c:1541 [inline] tunbuildskb+0x4a1/0xa40 drivers/net/tun.c:1636 tungetuser+0xc12/0x2030 drivers/net/tun.c:1770 tunchrwriteiter+0x71/0x120 drivers/net/tun.c:1999 newsyncwrite fs/readwrite.c:593 [inline] vfswrite+0x45d/0x710 fs/readwrite.c:686 ksyswrite+0xa7/0x170 fs/readwrite.c:738 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xa4/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

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

ipv6: Fix use-after-free in inet6addrdel().

syzbot reported use-after-free of inet6ifaddr in inet6addrdel(). [0]

The cited commit accidentally moved ipv6deladdr() for mngtmpaddr before reading its ifp->flags for temporary addresses in inet6addrdel().

Let's move ipv6deladdr() down to fix the UAF.

[0]: BUG: KASAN: slab-use-after-free in inet6addrdel.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117 Read of size 4 at addr ffff88807b89c86c by task syz.3.1618/9593

CPU: 0 UID: 0 PID: 9593 Comm: syz.3.1618 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xcd/0x630 mm/kasan/report.c:482 kasanreport+0xe0/0x110 mm/kasan/report.c:595 inet6addrdel.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117 addrconfdelifaddr+0x11e/0x190 net/ipv6/addrconf.c:3181 inet6ioctl+0x1e5/0x2b0 net/ipv6/afinet6.c:582 sockdoioctl+0x118/0x280 net/socket.c:1254 sockioctl+0x227/0x6b0 net/socket.c:1375 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:597 [inline] sesysioctl fs/ioctl.c:583 [inline] x64sysioctl+0x18e/0x210 fs/ioctl.c:583 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f164cf8f749 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f164de64038 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f164d1e5fa0 RCX: 00007f164cf8f749 RDX: 0000200000000000 RSI: 0000000000008936 RDI: 0000000000000003 RBP: 00007f164d013f91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f164d1e6038 R14: 00007f164d1e5fa0 R15: 00007ffde15c8288 </TASK>

Allocated by task 9593: kasansavestack+0x33/0x60 mm/kasan/common.c:56 kasansavetrack+0x14/0x30 mm/kasan/common.c:77 poisonkmallocredzone mm/kasan/common.c:397 [inline] kasankmalloc+0xaa/0xb0 mm/kasan/common.c:414 kmallocnoprof include/linux/slab.h:957 [inline] kzallocnoprof include/linux/slab.h:1094 [inline] ipv6addaddr+0x4e3/0x2010 net/ipv6/addrconf.c:1120 inet6addradd+0x256/0x9b0 net/ipv6/addrconf.c:3050 addrconfaddifaddr+0x1fc/0x450 net/ipv6/addrconf.c:3160 inet6ioctl+0x103/0x2b0 net/ipv6/afinet6.c:580 sockdoioctl+0x118/0x280 net/socket.c:1254 sockioctl+0x227/0x6b0 net/socket.c:1375 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:597 [inline] sesysioctl fs/ioctl.c:583 [inline] x64sysioctl+0x18e/0x210 fs/ioctl.c:583 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

Freed by task 6099: kasansavestack+0x33/0x60 mm/kasan/common.c:56 kasansavetrack+0x14/0x30 mm/kasan/common.c:77 kasansavefreeinfo+0x3b/0x60 mm/kasan/generic.c:584 poisonslabobject mm/kasan/common.c:252 [inline] kasanslabfree+0x5f/0x80 mm/kasan/common.c:284 kasanslabfree include/linux/kasan.h:234 [inline] slabfreehook mm/slub.c:2540 [inline] slabfreefreelisthook mm/slub.c:2569 [inline] slabfreebulk mm/slub.c:6696 [inline] kmemcachefreebulk mm/slub.c:7383 [inline] kmemcachefreebulk+0x2bf/0x680 mm/slub.c:7362 kfreebulk include/linux/slab.h:830 [inline] kvfreercubulk+0x1b7/0x1e0 mm/slabcommon.c:1523 kvfreercudrainready mm/slabcommon.c:1728 [inline] kfreercumonitor+0x1d0/0x2f0 mm/slabcommon.c:1801 processonework+0x9ba/0x1b20 kernel/workqueue.c:3257 processscheduledworks kernel/workqu ---truncated---

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

net/sched: schqfq: do not free existing class in qfqchangeclass()

Fixes qfqchangeclass() error case.

cl->qdisc and cl should only be freed if a new class and qdisc were allocated, or we risk various UAF.

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

libceph: make freechooseargmap() resilient to partial allocation

freechooseargmap() may dereference a NULL pointer if its caller fails after a partial allocation.

For example, in decodechooseargs(), if allocation of argmap->args fails, execution jumps to the fail label and freechooseargmap() is called. Since argmap->size is updated to a non-zero value before memory allocation, freechooseargmap() will iterate over argmap->args and dereference a NULL pointer.

To prevent this potential NULL pointer dereference and make freechooseargmap() more resilient, add checks for pointers before iterating.

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

libceph: replace overzealous BUGON in osdmapapplyincremental()

If the osdmap is (maliciously) corrupted such that the incremental osdmap epoch is different from what is expected, there is no need to BUG. Instead, just declare the incremental osdmap to be invalid.

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

nfsd: provide locking for v4endgrace

Writing to v4endgrace can race with server shutdown and result in memory being accessed after it was freed - reclaimstrhashtbl in particularly.

We cannot hold nfsdmutex across the nfsd4endgrace() call as that is held while clienttrackingop->init() is called and that can wait for an upcall to nfsdcltrack which can write to v4endgrace, resulting in a deadlock.

nfsd4endgrace() is also called by the landromat work queue and this doesn't require locking as server shutdown will stop the work and wait for it before freeing anything that nfsd4endgrace() might access.

However, we must be sure that writing to v4endgrace doesn't restart the work item after shutdown has already waited for it. For this we add a new flag protected with nn->clientlock. It is set only while it is safe to make client tracking calls, and v4endgrace only schedules work while the flag is set with the spinlock held.

So this patch adds a nfsdnet field "clienttrackingactive" which is set as described. Another field "graceendforced", is set when v4endgrace is written. After this is set, and providing clienttrackingactive is set, the laundromat is scheduled. This "graceendforced" field bypasses other checks for whether the grace period has finished.

This resolves a race which can result in use-after-free.

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

netfilter: nfconncount: fix leaked ct in error paths

There are some situations where ct might be leaked as error paths are skipping the refcounted check and return immediately. In order to solve it make sure that the check is always called.

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

usb: phy: isp1301: fix non-OF device reference imbalance

A recent change fixing a device reference leak in a UDC driver introduced a potential use-after-free in the non-OF case as the isp1301getclient() helper only increases the reference count for the returned I2C device in the OF case.

Increment the reference count also for non-OF so that the caller can decrement it unconditionally.

Note that this is inherently racy just as using the returned I2C device is since nothing is preventing the PHY driver from being unbound while in use.

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

octeontx2-pf: fix "UBSAN: shift-out-of-bounds error"

This patch ensures that the RX ring size (rxpending) is not set below the permitted length. This avoids UBSAN shift-out-of-bounds errors when users passes small or zero ring sizes via ethtool -G.

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

crypto: seqiv - Do not use req->iv after cryptoaeadencrypt

As soon as cryptoaeadencrypt is called, the underlying request may be freed by an asynchronous completion. Thus dereferencing req->iv after it returns is invalid.

Instead of checking req->iv against info, create a new variable unalignedinfo and use it for that purpose instead.

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

mm/slub: reset KASAN tag in deferfree() before accessing freed memory

When CONFIGSLUBTINY is enabled, kfreenolock() calls kasanslabfree() before deferfree(). On ARM64 with MTE (Memory Tagging Extension), kasanslabfree() poisons the memory and changes the tag from the original (e.g., 0xf3) to a poison tag (0xfe).

When deferfree() then tries to write to the freed object to build the deferred free list via llistadd(), the pointer still has the old tag, causing a tag mismatch and triggering a KASAN use-after-free report:

BUG: KASAN: slab-use-after-free in deferfree+0x3c/0xbc mm/slub.c:6537 Write at addr f3f000000854f020 by task kworker/u8:6/983 Pointer tag: [f3], memory tag: [fe]

Fix this by calling kasanresettag() before accessing the freed memory. This is safe because deferfree() is part of the allocator itself and is expected to manipulate freed memory for bookkeeping purposes.