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:
RDMA/hns: fix memory leak in hnsroceallocmr()
When hnsrocemrenable() failed in hnsroceallocmr(), mrkey is not released. Compiled test only.
In the Linux kernel, the following vulnerability has been resolved:
net: nfc: fix deadlock between nfcunregisterdevice and rfkillfopwrite
A deadlock can occur between nfcunregisterdevice() and rfkillfopwrite() due to lock ordering inversion between devicelock and rfkillglobalmutex.
The problematic lock order is:
Thread A (rfkillfopwrite): rfkillfopwrite() mutexlock(&rfkillglobalmutex) rfkillsetblock() nfcrfkillsetblock() nfcdevdown() devicelock(&dev->dev) <- waits for devicelock
Thread B (nfcunregisterdevice): nfcunregisterdevice() devicelock(&dev->dev) rfkillunregister() mutexlock(&rfkillglobalmutex) <- waits for rfkillglobalmutex
This creates a classic ABBA deadlock scenario.
Fix this by moving rfkillunregister() and rfkilldestroy() outside the devicelock critical section. Store the rfkill pointer in a local variable before releasing the lock, then call rfkillunregister() after releasing devicelock.
This change is safe because rfkillfopwrite() holds rfkillglobalmutex while calling the rfkill callbacks, and rfkillunregister() also acquires rfkillglobalmutex before cleanup. Therefore, rfkillunregister() will wait for any ongoing callback to complete before proceeding, and devicedel() is only called after rfkillunregister() returns, preventing any use-after-free.
The similar lock ordering in nfcregisterdevice() (devicelock -> rfkillglobalmutex via rfkillregister) is safe because during registration the device is not yet in rfkilllist, so no concurrent rfkill operations can occur on this device.
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: stm32: dmamux: fix device leak on route allocation
Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation.
Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.
In the Linux kernel, the following vulnerability has been resolved:
erofs: Fix pcluster memleak when its block address is zero
syzkaller reported a memleak: https://syzkaller.appspot.com/bug?id=62f37ff612f0021641eda5b17f056f1668aa9aed
unreferenced object 0xffff88811009c7f8 (size 136): ... backtrace: [<ffffffff821db19b>] zerofsdoreadpage+0x99b/0x1740 [<ffffffff821dee9e>] zerofsreadahead+0x24e/0x580 [<ffffffff814bc0d6>] readpages+0x86/0x3d0 ...
syzkaller constructed a case: in zerofsregisterpcluster(), ztailpacking = false and map->mpa = zero. This makes pcl->obj.index be zero although pcl is not a inline pcluster.
Then following path adds refcount for grp, but the refcount won't be put because pcl is inline.
zerofsreadahead() zerofsdoreadpage() # for another page zerofscollectorbegin() erofsfindworkgroup() erofsworkgroupget()
Since it's illegal for the block address of a non-inlined pcluster to be zero, add check here to avoid registering the pcluster which would be leaked.
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Wake up the error handler when final completions race against each other
The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance.
First, there is an memory ordering issue within scsidechostbusy(). The write which clears SCMDSTATEINFLIGHT may be reordered with reads counting in scsihostbusy(). While the local CPU will see its own write, reordering can allow other CPUs in scsidechostbusy() or scsiehinchostfailed() to see a raised busy count, causing no CPU to see a host busy equal to the hostfailed count.
This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands.
Second, there is a general ordering issue with scsiehinchostfailed(). By counting busy commands before incrementing hostfailed, it can race with a final command in scsidechostbusy(), such that scsidechostbusy() does not see hostfailed incremented but scsiehinchostfailed() counts busy commands before SCMDSTATEINFLIGHT is cleared by scsidechostbusy(), resulting in neither waking the error handler task.
This needs the call to scsihostbusy() to be moved after hostfailed is incremented to close the race condition.
In the Linux kernel, the following vulnerability has been resolved:
NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags
When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the "ro" flag.
In the Linux kernel, the following vulnerability has been resolved:
x86/apic: Don't disable x2APIC if locked
The APIC supports two modes, legacy APIC (or xAPIC), and Extended APIC (or x2APIC). X2APIC mode is mostly compatible with legacy APIC, but it disables the memory-mapped APIC interface in favor of one that uses MSRs. The APIC mode is controlled by the EXT bit in the APIC MSR.
The MMIO/xAPIC interface has some problems, most notably the APIC LEAK [1]. This bug allows an attacker to use the APIC MMIO interface to extract data from the SGX enclave.
Introduce support for a new feature that will allow the BIOS to lock the APIC in x2APIC mode. If the APIC is locked in x2APIC mode and the kernel tries to disable the APIC or revert to legacy APIC mode a GP fault will occur.
Introduce support for a new MSR (IA32XAPICDISABLESTATUS) and handle the new locked mode when the LEGACYXAPICDISABLED bit is set by preventing the kernel from trying to disable the x2APIC.
On platforms with the IA32XAPICDISABLESTATUS MSR, if SGX or TDX are enabled the LEGACYXAPICDISABLED will be set by the BIOS. If legacy APIC is required, then it SGX and TDX need to be disabled in the BIOS.
[1]: https://aepicleak.com/aepicleak.pdf
In the Linux kernel, the following vulnerability has been resolved:
net: hvnetvsc: reject RSS hash key programming without RX indirection table
RSS configuration requires a valid RX indirection table. When the device reports a single receive queue, rndisfilterdeviceadd() does not allocate an indirection table, accepting RSS hash key updates in this state leads to a hang.
Fix this by gating netvscsetrxfh() on ndc->rxtablesz and return -EOPNOTSUPP when the table is absent. This aligns setrxfh with the device capabilities and prevents incorrect behavior.
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Avoid UBSAN error on truesectorsperclst()
syzbot reported UBSAN error as below:
[ 76.901829][ T6677] ================================================================================ [ 76.903908][ T6677] UBSAN: shift-out-of-bounds in fs/ntfs3/super.c:675:13 [ 76.905363][ T6677] shift exponent -247 is negative
This patch avoid this error.
In the Linux kernel, the following vulnerability has been resolved:
scsi: aic94xx: fix use-after-free in device removal path
The asdpciremove() function fails to synchronize with pending tasklets before freeing the asdha structure, leading to a potential use-after-free vulnerability.
When a device removal is triggered (via hot-unplug or module unload), race condition can occur.
The fix adds taskletkill() before freeing the asdha structure, ensuring all scheduled tasklets complete before cleanup proceeds.
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: athdmac: fix device leak on ofdmaxlate()
Make sure to drop the reference taken when looking up the DMA platform device during ofdmaxlate() when releasing channel resources.
Note that commit 3832b78b3ec2 ("dmaengine: athdmac: add missing putdevice() call in atdmaxlate()") fixed the leak in a couple of error paths but the reference is still leaking on successful allocation.
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: fix possible memory leak in stmmacdvrprobe()
The bitmapfree() should be called to free priv->afxdpzcqps when createsinglethreadworkqueue() fails, otherwise there will be a memory leak, so we add the err path errorwqinit to fix it.
In the Linux kernel, the following vulnerability has been resolved:
crypto: akcipher - default implementation for setting a private key
Changes from v1: removed the default implementation from setpubkey: it is assumed that an implementation must always have this callback defined as there are no use case for an algorithm, which doesn't need a public key
Many akcipher implementations (like ECDSA) support only signature verifications, so they don't have all callbacks defined.
Commit 78a0324f4a53 ("crypto: akcipher - default implementations for request callbacks") introduced default callbacks for sign/verify operations, which just return an error code.
However, these are not enough, because before calling sign the caller would likely call setprivkey first on the instantiated transform (as the in-kernel testmgr does). This function does not have a default stub, so the kernel crashes, when trying to set a private key on an akcipher, which doesn't support signature generation.
I've noticed this, when trying to add a KAT vector for ECDSA signature to the testmgr.
With this patch the testmgr returns an error in dmesg (as it should) instead of crashing the kernel NULL ptr dereference.
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix a memleak in multitransactionnew()
In multitransactionnew(), the variable t is not freed or passed out on the failure of copyfromuser(t->data, buf, size), which could lead to a memleak.
Fix this bug by adding a putmultitransaction(t) in the error path.
In the Linux kernel, the following vulnerability has been resolved:
spi: fsl-cpm: Check length parity before switching to 16 bit mode
Commit fc96ec826bce ("spi: fsl-cpm: Use 16 bit mode for large transfers with even size") failed to make sure that the size is really even before switching to 16 bit mode. Until recently the problem went unnoticed because kernfs uses a pre-allocated bounce buffer of size PAGESIZE for reading EEPROM.
But commit 8ad6249c51d0 ("eeprom: at25: convert to spi-mem API") introduced an additional dynamically allocated bounce buffer whose size is exactly the size of the transfer, leading to a buffer overrun in the fsl-cpm driver when that size is odd.
Add the missing length parity verification and remain in 8 bit mode when the length is not even.
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:
ksmbd: Fix resource leak in ksmbdsessionrpcopen()
When ksmbdrpcopen() fails then it must call ksmbdrpcidfree() to undo the result of ksmbdipcidalloc().
In the Linux kernel, the following vulnerability has been resolved:
misc: ocxl: fix possible name leak in ocxlfileregisterafu()
If deviceregister() returns error in ocxlfileregisterafu(), the name allocated by devsetname() need be freed. As comment of deviceregister() says, it should use putdevice() to give up the reference in the error path. So fix this by calling putdevice(), then the name can be freed in kobjectcleanup(), and info is freed in inforelease().
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: hifusb: fix memory leak of urbs in ath9khifusbdealloctxurbs()
Syzkaller reports a long-known leak of urbs in ath9khifusbdealloctxurbs().
The cause of the leak is that usbgeturb() is called but usbfreeurb() (or usbputurb()) is not called inside usbkillurb() as urb->dev or urb->ep fields have not been initialized and usbkillurb() returns immediately.
The patch removes trying to kill urbs located in hifdev->tx.txbuf because hifdev->tx.txbuf is not supposed to contain urbs which are in pending state (the pending urbs are stored in hifdev->tx.txpending). The tx.txlock is acquired so there should not be any changes in the list.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
In the Linux kernel, the following vulnerability has been resolved:
wifi: ipw2200: fix memory leak in ipwwdevinit()
In the error path of ipwwdevinit(), exception value is returned, and the memory applied for in the function is not released. Also the memory is not released in ipwpciprobe(). As a result, memory leakage occurs. So memory release needs to be added to the error path of ipwwdevinit().
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:
cpufreq: qcom-hw: Fix memory leak in qcomcpufreqhwreadlut()
If "cpudev" fails to get opp table in qcomcpufreqhwreadlut(), the program will return, resulting in "table" resource is not released.
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: fix invalid address access when enabling SCAN log level
The variable i is changed when setting random MAC address and causes invalid address access when printing the value of pi->reqs[i]->reqid.
We replace reqs index with ri to fix the issue.
[ 136.726473] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000 [ 136.737365] Mem abort info: [ 136.740172] ESR = 0x96000004 [ 136.743359] Exception class = DABT (current EL), IL = 32 bits [ 136.749294] SET = 0, FnV = 0 [ 136.752481] EA = 0, S1PTW = 0 [ 136.755635] Data abort info: [ 136.758514] ISV = 0, ISS = 0x00000004 [ 136.762487] CM = 0, WnR = 0 [ 136.765522] user pgtable: 4k pages, 48-bit VAs, pgdp = 000000005c4e2577 [ 136.772265] [0000000000000000] pgd=0000000000000000 [ 136.777160] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 136.782732] Modules linked in: brcmfmac(O) brcmutil(O) cfg80211(O) compat(O) [ 136.789788] Process wificond (pid: 3175, stack limit = 0x00000000053048fb) [ 136.796664] CPU: 3 PID: 3175 Comm: wificond Tainted: G O 4.19.42-00001-g531a5f5 #1 [ 136.805532] Hardware name: Freescale i.MX8MQ EVK (DT) [ 136.810584] pstate: 60400005 (nZCv daif +PAN -UAO) [ 136.815429] pc : brcmfpnoconfigschedscans+0x6cc/0xa80 [brcmfmac] [ 136.821811] lr : brcmfpnoconfigschedscans+0x67c/0xa80 [brcmfmac] [ 136.828162] sp : ffff00000e9a3880 [ 136.831475] x29: ffff00000e9a3890 x28: ffff800020543400 [ 136.836786] x27: ffff8000b1008880 x26: ffff0000012bf6a0 [ 136.842098] x25: ffff80002054345c x24: ffff800088d22400 [ 136.847409] x23: ffff0000012bf638 x22: ffff0000012bf6d8 [ 136.852721] x21: ffff8000aced8fc0 x20: ffff8000ac164400 [ 136.858032] x19: ffff00000e9a3946 x18: 0000000000000000 [ 136.863343] x17: 0000000000000000 x16: 0000000000000000 [ 136.868655] x15: ffff0000093f3b37 x14: 0000000000000050 [ 136.873966] x13: 0000000000003135 x12: 0000000000000000 [ 136.879277] x11: 0000000000000000 x10: ffff000009a61888 [ 136.884589] x9 : 000000000000000f x8 : 0000000000000008 [ 136.889900] x7 : 303a32303d726464 x6 : ffff00000a1f957d [ 136.895211] x5 : 0000000000000000 x4 : ffff00000e9a3942 [ 136.900523] x3 : 0000000000000000 x2 : ffff0000012cead8 [ 136.905834] x1 : ffff0000012bf6d8 x0 : 0000000000000000 [ 136.911146] Call trace: [ 136.913623] brcmfpnoconfigschedscans+0x6cc/0xa80 [brcmfmac] [ 136.919658] brcmfpnostartschedscan+0xa4/0x118 [brcmfmac] [ 136.925430] brcmfcfg80211schedscanstart+0x80/0xe0 [brcmfmac] [ 136.931636] nl80211startschedscan+0x140/0x308 [cfg80211] [ 136.937298] genlrcvmsg+0x358/0x3f4 [ 136.940960] netlinkrcvskb+0xb4/0x118 [ 136.944795] genlrcv+0x34/0x48 [ 136.947935] netlinkunicast+0x264/0x300 [ 136.951856] netlinksendmsg+0x2e4/0x33c [ 136.955781] syssendto+0x120/0x19c
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:
ext4: refresh inline data size before write operations
The cached ei->iinlinesize can become stale between the initial size check and when ext4updateinlinedata()/ext4createinlinedata() use it. Although ext4getmaxinlinesize() reads the correct value at the time of the check, concurrent xattr operations can modify iinlinesize before ext4writelockxattr() is acquired.
This causes ext4updateinlinedata() and ext4createinlinedata() to work with stale capacity values, leading to a BUGON() crash in ext4writeinlinedata():
kernel BUG at fs/ext4/inline.c:1331! BUGON(pos + len > EXT4I(inode)->iinlinesize);
The race window: 1. ext4getmaxinlinesize() reads iinlinesize = 60 (correct) 2. Size check passes for 50-byte write 3. [Another thread adds xattr, iinlinesize changes to 40] 4. ext4writelockxattr() acquires lock 5. ext4updateinlinedata() uses stale iinlinesize = 60 6. Attempts to write 50 bytes but only 40 bytes actually available 7. BUGON() triggers
Fix this by recalculating iinlinesize via ext4findinlinedatanolock() immediately after acquiring xattrsem. This ensures ext4updateinlinedata() and ext4createinlinedata() work with current values that are protected from concurrent modifications.
This is similar to commit a54c4613dac1 ("ext4: fix race writing to an inlinedata file while its xattrs are changing") which fixed iinlineoff staleness. This patch addresses the related iinlinesize staleness issue.
In the Linux kernel, the following vulnerability has been resolved:
PCI: Fix pcideviceispresent() for VFs by checking PF
pcideviceispresent() previously didn't work for VFs because it reads the Vendor and Device ID, which are 0xffff for VFs, which looks like they aren't present. Check the PF instead.
Wei Gong reported that if virtio I/O is in progress when the driver is unbound or "0" is written to /sys/.../sriovnumvfs, the virtio I/O operation hangs, which may result in output like this:
task:bash state:D stack: 0 pid: 1773 ppid: 1241 flags:0x00004002 Call Trace: schedule+0x4f/0xc0 blkmqfreezequeuewait+0x69/0xa0 blkmqfreezequeue+0x1b/0x20 blkcleanupqueue+0x3d/0xd0 virtblkremove+0x3c/0xb0 [virtioblk] virtiodevremove+0x4b/0x80 ... deviceunregister+0x1b/0x60 unregistervirtiodevice+0x18/0x30 virtiopciremove+0x41/0x80 pcideviceremove+0x3e/0xb0
This happened because pcideviceispresent(VF) returned "false" in virtiopciremove(), so it called virtiobreakdevice(). The broken vq meant that vringinterrupt() skipped the vq.callback() that would have completed the virtio I/O operation via virtblkdone().
[bhelgaas: commit log, simplify to always use pciphysfn(), add stable tag]
In the Linux kernel, the following vulnerability has been resolved:
clk: st: Fix memory leak in stofquadfssetup()
If stclkregisterquadfspll() fails, @lock should be freed before goto @errexit, otherwise will cause meory leak issue, fix it.
In the Linux kernel, the following vulnerability has been resolved:
mailbox: zynq-ipi: fix error handling while deviceregister() fails
If deviceregister() fails, it has two issues: 1. The name allocated by devsetname() is leaked. 2. The parent of device is not NULL, deviceunregister() is called in zynqmpipifreemboxes(), it will lead a kernel crash because of removing not added device.
Call putdevice() to give up the reference, so the name is freed in kobjectcleanup(). Add device registered check in zynqmpipifreemboxes() to avoid null-ptr-deref.
In the Linux kernel, the following vulnerability has been resolved:
nvmem: core: Fix memleak in nvmemregister()
devsetname will alloc memory for nvmem->dev.kobj.name in nvmemregister, when nvmemvalidatekeepouts failed, nvmem's memory will be freed and return, but nobody will free memory for nvmem->dev.kobj.name, there will be memleak, so moving nvmemvalidatekeepouts() after deviceregister() and let the device core deal with cleaning name in error cases.