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

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

net: atm: fix crash due to unvalidated vcc pointer in sigdsend()

Reproducer available at [1].

The ATM send path (sendmsg -> vccsendmsg -> sigdsend) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged:

int fd = socket(AFATMSVC, SOCKDGRAM, 0); ioctl(fd, ATMSIGDCTRL); // become ATM signaling daemon struct msghdr msg = { .msgiov = &iov, ... }; (unsigned long )(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef

In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigdenq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values.

Fix this by introducing findgetvcc() which validates the pointer by searching through vcchash (similar to how sigdclose() iterates over all VCCs), and acquires a reference via sockhold() if found.

Since struct atmvcc embeds struct sock as its first member, they share the same lifetime. Therefore using sockhold/sockput is sufficient to keep the vcc alive while it is being used.

Note that there may be a race with sigdclose() which could mark the vcc with various flags (e.g., ATMVFRELEASED) after findgetvcc() returns. However, sockhold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety.

[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3

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

mm: thp: deny THP for files on anonymous inodes

filethpenabled() incorrectly allows THP for files on anonymous inodes (e.g. guestmemfd and secretmem). These files are created via allocfilepseudo(), which does not call getwriteaccess() and leaves inode->iwritecount at 0. Combined with SISREG(inode->imode) being true, they appear as read-only regular files when CONFIGREADONLYTHPFORFS is enabled, making them eligible for THP collapse.

Anonymous inodes can never pass the inodeisopenforwrite() check since their iwritecount is never incremented through the normal VFS open path. The right thing to do is to exclude them from THP eligibility altogether, since CONFIGREADONLYTHPFORFS was designed for real filesystem files (e.g. shared libraries), not for pseudo-filesystem inodes.

For guestmemfd, this allows khugepaged and MADVCOLLAPSE to create large folios in the page cache via the collapse path, but the guestmemfd fault handler does not support large folios. This triggers WARNONONCE(foliotestlarge(folio)) in kvmgmemfaultusermapping().

For secretmem, collapsefile() tries to copy page contents through the direct map, but secretmem pages are removed from the direct map. This can result in a kernel crash:

BUG: unable to handle page fault for address: ffff88810284d000 RIP: 0010:memcpyorig+0x16/0x130 Call Trace: collapsefile hpagecollapsescanfile madvisecollapse

Secretmem is not affected by the crash on upstream as the memory failure recovery handles the failed copy gracefully, but it still triggers confusing false memory failure reports:

Memory failure: 0x106d96f: recovery action for clean unevictable LRU page: Recovered

Check ISANONFILE(inode) in filethpenabled() to deny THP for all anonymous inode files.

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

netfilter: nftables: clone set on flush only

Syzbot with fault injection triggered a failing memory allocation with GFPKERNEL which results in a WARN splat:

iter.err WARNING: net/netfilter/nftablesapi.c:845 at nftmapdeactivate+0x34e/0x3c0 net/netfilter/nftablesapi.c:845, CPU#0: syz.0.17/5992 Modules linked in: CPU: 0 UID: 0 PID: 5992 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026 RIP: 0010:nftmapdeactivate+0x34e/0x3c0 net/netfilter/nftablesapi.c:845 Code: 8b 05 86 5a 4e 09 48 3b 84 24 a0 00 00 00 75 62 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc e8 63 6d fa f7 90 <0f> 0b 90 43 +80 7c 35 00 00 0f 85 23 fe ff ff e9 26 fe ff ff 89 d9 RSP: 0018:ffffc900045af780 EFLAGS: 00010293 RAX: ffffffff89ca45bd RBX: 00000000fffffff4 RCX: ffff888028111e40 RDX: 0000000000000000 RSI: 00000000fffffff4 RDI: 0000000000000000 RBP: ffffc900045af870 R08: 0000000000400dc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff1d141db R12: ffffc900045af7e0 R13: 1ffff920008b5f24 R14: dffffc0000000000 R15: ffffc900045af920 FS: 000055557a6a5500(0000) GS:ffff888125496000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb5ea271fc0 CR3: 000000003269e000 CR4: 00000000003526f0 Call Trace: <TASK> nftreleasetable+0xceb/0x11f0 net/netfilter/nftablesapi.c:12115 nftrcvnlevent+0xc25/0xdb0 net/netfilter/nftablesapi.c:12187 notifiercallchain+0x19d/0x3a0 kernel/notifier.c:85 blockingnotifiercallchain+0x6a/0x90 kernel/notifier.c:380 netlinkrelease+0x123b/0x1ad0 net/netlink/afnetlink.c:761 sockrelease net/socket.c:662 [inline] sockclose+0xc3/0x240 net/socket.c:1455

Restrict set clone to the flush set command in the preparation phase. Add NFTITERUPDATECLONE and use it for this purpose, update the rbtree and pipapo backends to only clone the set when this iteration type is used.

As for the existing NFTITERUPDATE type, update the pipapo backend to use the existing set clone if available, otherwise use the existing set representation. After this update, there is no need to clone a set that is being deleted, this includes bound anonymous set.

An alternative approach to NFTITERUPDATECLONE is to add a .clone interface and call it from the flush set path.

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

rtnetlink: add missing netlinknscapable() check for peer netns

rtnlnewlink() lacks a CAPNETADMIN capability check on the peer network namespace when creating paired devices (veth, vxcan, netkit). This allows an unprivileged user with a user namespace to create interfaces in arbitrary network namespaces, including initnet.

Add a netlinknscapable() check for CAPNETADMIN in the peer namespace before allowing device creation to proceed.

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

net: sched: actcsum: validate nested VLAN headers

tcfcsumact() walks nested VLAN headers directly from skb->data when an skb still carries in-payload VLAN tags. The current code reads vlan->hvlanencapsulatedproto and then pulls VLANHLEN bytes without first ensuring that the full VLAN header is present in the linear area.

If only part of an inner VLAN header is linearized, accessing hvlanencapsulatedproto reads past the linear area, and the following skbpull(VLANHLEN) may violate skb invariants.

Fix this by requiring pskbmaypull(skb, VLANHLEN) before accessing and pulling each nested VLAN header. If the header still is not fully available, drop the packet through the existing error path.

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

btrfs: log new dentries when logging parent dir of a conflicting inode

If we log the parent directory of a conflicting inode, we are not logging the new dentries of the directory, so when we finish we have the parent directory's inode marked as logged but we did not log its new dentries. As a consequence if the parent directory is explicitly fsynced later and it does not have any new changes since we logged it, the fsync is a no-op and after a power failure the new dentries are missing.

Example scenario:

$ mkdir foo

$ sync

$rmdir foo

$ mkdir dir1 $ mkdir dir2

# A file with the same name and parent as the directory we just deleted # and was persisted in a past transaction. So the deleted directory's # inode is a conflicting inode of this new file's inode. $ touch foo

$ ln foo dir2/link

# The fsync on dir2 will log the parent directory (".") because the # conflicting inode (deleted directory) does not exists anymore, but it # it does not log its new dentries (dir1). $ xfsio -c "fsync" dir2

# This fsync on the parent directory is no-op, since the previous fsync # logged it (but without logging its new dentries). $ xfsio -c "fsync" .

<power failure>

# After log replay dir1 is missing.

Fix this by ensuring we log new dir dentries whenever we log the parent directory of a no longer existing conflicting inode.

A test case for fstests will follow soon.

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

spi: fix statistics allocation

The controller per-cpu statistics is not allocated until after the controller has been registered with driver core, which leaves a window where accessing the sysfs attributes can trigger a NULL-pointer dereference.

Fix this by moving the statistics allocation to controller allocation while tying its lifetime to that of the controller (rather than using implicit devres).

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

drm/imagination: Synchronize interrupts before suspending the GPU

The runtime PM suspend callback doesn't know whether the IRQ handler is in progress on a different CPU core and doesn't wait for it to finish.

Depending on timing, the IRQ handler could be running while the GPU is suspended, leading to kernel crashes when trying to access GPU registers. See example signature below.

In a power off sequence initiated by the runtime PM suspend callback, wait for any IRQ handlers in progress on other CPU cores to finish, by calling synchronizeirq().

At the same time, remove the runtime PM resume/put calls in the threaded IRQ handler. On top of not being the right approach to begin with, and being at the wrong place as they should have wrapped all GPU register accesses, the driver would hit a deadlock between synchronizeirq() being called from a runtime PM suspend callback, holding the device power lock, and the resume callback requiring the same.

Example crash signature on a TI AM68 SK platform:

[ 337.241218] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError [ 337.241239] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT [ 337.241246] Tainted: [M]=MACHINECHECK [ 337.241249] Hardware name: Texas Instruments AM68 SK (DT) [ 337.241252] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 337.241256] pc : pvrriscvirqpending+0xc/0x24 [ 337.241277] lr : pvrdeviceirqthreadhandler+0x64/0x310 [ 337.241282] sp : ffff800085b0bd30 [ 337.241284] x29: ffff800085b0bd50 x28: ffff0008070d9eab x27: ffff800083a5ce10 [ 337.241291] x26: ffff000806e48f80 x25: ffff0008070d9eac x24: 0000000000000000 [ 337.241296] x23: ffff0008068e9bf0 x22: ffff0008068e9bd0 x21: ffff800085b0bd30 [ 337.241301] x20: ffff0008070d9e00 x19: ffff0008068e9000 x18: 0000000000000001 [ 337.241305] x17: 637365645f656c70 x16: 0000000000000000 x15: ffff000b7df9ff40 [ 337.241310] x14: 0000a585fe3c0d0e x13: 000000999704f060 x12: 000000000002771a [ 337.241314] x11: 00000000000000c0 x10: 0000000000000af0 x9 : ffff800085b0bd00 [ 337.241318] x8 : ffff0008071175d0 x7 : 000000000000b955 x6 : 0000000000000003 [ 337.241323] x5 : 0000000000000000 x4 : 0000000000000002 x3 : 0000000000000000 [ 337.241327] x2 : ffff800080e39d20 x1 : ffff800080e3fc48 x0 : 0000000000000000 [ 337.241333] Kernel panic - not syncing: Asynchronous SError Interrupt [ 337.241337] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT [ 337.241342] Tainted: [M]=MACHINECHECK [ 337.241343] Hardware name: Texas Instruments AM68 SK (DT) [ 337.241345] Call trace: [ 337.241348] showstack+0x18/0x24 (C) [ 337.241357] dumpstacklvl+0x60/0x80 [ 337.241364] dumpstack+0x18/0x24 [ 337.241368] vpanic+0x124/0x2ec [ 337.241373] abort+0x0/0x4 [ 337.241377] addtaint+0x0/0xbc [ 337.241384] arm64serrorpanic+0x70/0x80 [ 337.241389] doserror+0x3c/0x74 [ 337.241392] el1h64errorhandler+0x30/0x48 [ 337.241400] el1h64error+0x6c/0x70 [ 337.241404] pvrriscvirqpending+0xc/0x24 (P) [ 337.241410] irqthreadfn+0x2c/0xb0 [ 337.241416] irqthread+0x170/0x334 [ 337.241421] kthread+0x12c/0x210 [ 337.241428] retfromfork+0x10/0x20 [ 337.241434] SMP: stopping secondary CPUs [ 337.241451] Kernel Offset: disabled [ 337.241453] CPU features: 0x040000,02002800,20002001,0400421b [ 337.241456] Memory Limit: none [ 337.457921] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---

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

soc: fsl: qbman: fix race condition in qmandestroyfq

When QMANFQFLAGDYNAMICFQID is set, there's a race condition between fqtable[fq->idx] state and freeing/allocating from the pool and WARNON(fqtable[fq->idx]) in qmancreatefq() gets triggered.

Indeed, we can have: Thread A Thread B qmandestroyfq() qmancreatefq() qmanreleasefqid() qmanshutdownfq() genpoolfree() -- At this point, the fqid is available again -- qmanallocfqid() -- so, we can get the just-freed fqid in thread B -- fq->fqid = fqid; fq->idx = fqid 2; WARNON(fqtable[fq->idx]); fqtable[fq->idx] = fq; fqtable[fq->idx] = NULL;

And adding some logs between qmanreleasefqid() and fqtable[fq->idx] = NULL makes the WARNON() trigger a lot more.

To prevent that, ensure that fqtable[fq->idx] is set to NULL before genpoolfree() is called by using smpwmb().

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

soc: microchip: mpfs: Fix memory leak in mpfssyscontrollerprobe()

In mpfssyscontrollerprobe(), if ofgetmtddevicebynode() fails, the function returns immediately without freeing the allocated memory for syscontroller, leading to a memory leak.

Fix this by jumping to the outfree label to ensure the memory is properly freed.

Also, consolidate the error handling for the mboxrequestchannel() failure case to use the same label.

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

drm/i915/dmc: Fix an unlikely NULL pointer deference at probe

inteldmcupdatedc6allowedcount() oopses when DMC hasn't been initialized, and dmc is thus NULL.

That would be the case when the call path is intelpowerdomainsinithw() -> {skl,bxt,icl}displaycoreinit() -> gen9setdcstate() -> inteldmcupdatedc6allowedcount(), as intelpowerdomainsinithw() is called before inteldmcinit().

However, gen9setdcstate() calls inteldmcupdatedc6allowedcount() conditionally, depending on the current and target DC states. At probe, the target is disabled, but if DC6 is enabled, the function is called, and an oops follows. Apparently it's quite unlikely that DC6 is enabled at probe, as we haven't seen this failure mode before.

It is also strange to have DC6 enabled at boot, since that would require the DMC firmware (loaded by BIOS); the BIOS loading the DMC firmware and the driver stopping / reprogramming the firmware is a poorly specified sequence and as such unlikely an intentional BIOS behaviour. It's more likely that BIOS is leaving an unintentionally enabled DC6 HW state behind (without actually loading the required DMC firmware for this).

The tracking of the DC6 allowed counter only works if starting / stopping the counter depends on the SW DC6 state vs. the current HW DC6 state (since stopping the counter requires the DC5 counter captured when the counter was started). Thus, using the HW DC6 state is incorrect and it also leads to the above oops. Fix both issues by using the SW DC6 state for the tracking.

This is v2 of the fix originally sent by Jani, updated based on the first Link: discussion below.

(cherry picked from commit 2344b93af8eb5da5d496b4e0529d35f0f559eaf0)

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

mtd: Avoid boot crash in RedBoot partition table parser

Given CONFIGFORTIFYSOURCE=y and a recent compiler, commit 439a1bcac648 ("fortify: Use builtindynamicobjectsize() when available") produces the warning below and an oops.

Searching for RedBoot partition table in 50000000.flash at offset 0x7e0000 ------------[ cut here ]------------ WARNING: lib/stringhelpers.c:1035 at 0xc029e04c, CPU#0: swapper/0/1 memcmp: detected buffer overflow: 15 byte read of buffer size 14 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0 #1 NONE

As Kees said, "'names' is pointing to the final 'namelen' many bytes of the allocation ... 'namelen' could be basically any length at all. This fortify warning looks legit to me -- this code used to be reading beyond the end of the allocation."

Since the size of the dynamic allocation is calculated with strlen() we can use strcmp() instead of memcmp() and remain within bounds.

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

net/rose: fix NULL pointer dereference in rosetransmitlink on reconnect

syzkaller reported a bug [1], and the reproducer is available at [2].

ROSE sockets use four sk->skstate values: TCPCLOSE, TCPLISTEN, TCPSYNSENT, and TCPESTABLISHED. roseconnect() already rejects calls for TCPESTABLISHED (-EISCONN) and TCPCLOSE with SSCONNECTING (-ECONNREFUSED), but lacks a check for TCPSYNSENT.

When roseconnect() is called a second time while the first connection attempt is still in progress (TCPSYNSENT), it overwrites rose->neighbour via rosegetneigh(). If that returns NULL, the socket is left with rose->state == ROSESTATE1 but rose->neighbour == NULL. When the socket is subsequently closed, roserelease() sees ROSESTATE1 and calls rosewriteinternal() -> rosetransmitlink(skb, NULL), causing a NULL pointer dereference.

Per connect(2), a second connect() while a connection is already in progress should return -EALREADY. Add this missing check for TCPSYNSENT to complete the state validation in roseconnect().

[1] https://syzkaller.appspot.com/bug?extid=d00f90e0af54102fb271 [2] https://gist.github.com/mrpre/9e6779e0d13e2c66779b1653fef80516

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

drm/imagination: Fix deadlock in soft reset sequence

The soft reset sequence is currently executed from the threaded IRQ handler, hence it cannot call disableirq() which internally waits for IRQ handlers, i.e. itself, to complete.

Use disableirqnosync() during a soft reset instead.

drm/amdgpu: Limit BO list entry count to prevent resource exhaustion

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

mac80211: fix crash in ieee80211chanbwchange for APVLAN stations

ieee80211chanbwchange() iterates all stations and accesses link->reserved.oper via sta->sdata->link[linkid]. For stations on APVLAN interfaces (e.g. 4addr WDS clients), sta->sdata points to the VLAN sdata, whose link never participates in chanctx reservations. This leaves link->reserved.oper zero-initialized with chan == NULL, causing a NULL pointer dereference in ieee80211stacaprxbw() when accessing chandef->chan->band during CSA.

Resolve the VLAN sdata to its parent AP sdata using getbsssdata() before accessing link data.

[also change sta->sdata in ARRAYSIZE even if it doesn't matter]

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

crypto: atmel-sha204a - Fix OOM ->tfmcount leak

If memory allocation fails, decrement ->tfmcount to avoid blocking future reads.

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

drm/xe: Fix memory leak in xevmmadviseioctl

When checkboargsaresane() validation fails, jump to the new freevmas cleanup label to properly free the allocated resources. This ensures proper cleanup in this error path.

(cherry picked from commit 29bd06faf727a4b76663e4be0f7d770e2d2a7965)

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

sunrpc: fix cacherequest leak in cacherelease

When a reader's file descriptor is closed while in the middle of reading a cacherequest (rp->offset != 0), cacherelease() decrements the request's readers count but never checks whether it should free the request.

In cacheread(), when readers drops to 0 and CACHEPENDING is clear, the cacherequest is removed from the queue and freed along with its buffer and cachehead reference. cacherelease() lacks this cleanup.

The only other path that frees requests with readers == 0 is cachedequeue(), but it runs only when CACHEPENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cachedequeue() will have skipped the request, and no subsequent call will clean it up.

Add the same cleanup logic from cacheread() to cacherelease(): after decrementing readers, check if it reached 0 with CACHEPENDING clear, and if so, dequeue and free the cacherequest.

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

ksmbd: use volume UUID in FSOBJECTIDINFORMATION

Use sb->suuid for a proper volume identifier as the primary choice. For filesystems that do not provide a UUID, fall back to stfs.ffsid obtained from vfsstatfs().

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

drm/xe/regsr: Fix leak on xastore failure

Free the newly allocated entry when xastore() fails to avoid a memory leak on the error path.

v2: use goto failfree. (Bala)

(cherry picked from commit 6bc6fec71ac45f52db609af4e62bdb96b9f5fadb)

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

drm/logicvc: Fix device node reference leak in logicvcdrmconfigparse()

The logicvcdrmconfigparse() function calls ofgetchildbyname() to find the "layers" node but fails to release the reference, leading to a device node reference leak.

Fix this by using the free(devicenode) cleanup attribute to automatic release the reference when the variable goes out of scope.

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

btrfs: free pages on error in btrfsuringreadextent()

In this function the 'pages' object is never freed in the hopes that it is picked up by btrfsuringreadfinished() whenever that executes in the future. But that's just the happy path. Along the way previous allocations might have gone wrong, or we might not get -EIOCBQUEUED from btrfsencodedreadregularfillpages(). In all these cases, we go to a cleanup section that frees all memory allocated by this function without assuming any deferred execution, and this also needs to happen for the 'pages' allocation.

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

wifi: wlcore: Fix a locking bug

Make sure that wl->mutex is locked before it is unlocked. This has been detected by the Clang thread-safety analyzer.

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

drm/xe/configfs: Free ctxrestoremidbb in release

ctxrestoremidbb memory is allocated in wabbstore(), but xeconfigdevicerelease() only frees ctxrestorepostbb.

Free ctxrestoremidbb[0].cs as well to avoid leaking the allocation when the configfs device is removed.

(cherry picked from commit a235e7d0098337c3f2d1e8f3610c719a589e115f)

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

spi: amlogic-spisg: Fix memory leak in amlspisgprobe()

In amlspisgprobe(), ctlr is allocated by spialloctarget()/spiallochost(), but fails to call spicontrollerput() in several error paths. This leads to a memory leak whenever the driver fails to probe after the initial allocation.

Convert to use devmspiallochost()/devmspialloctarget() to fix the memory leak.

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

ipv6: add NULL checks for idev in SRv6 paths

in6devget() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6MINMTU or after NETDEVUNREGISTER).

Add NULL checks for idev returned by in6devget() in both seg6hmacvalidateskb() and ipv6srhrcv() to prevent potential NULL pointer dereferences.

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

net/mlx5e: Prevent concurrent access to IPSec ASO context

The query or updating IPSec offload object is through Access ASO WQE. The driver uses a single mlx5eipsecaso struct for each PF, which contains a shared DMA-mapped context for all ASO operations.

A race condition exists because the ASO spinlock is released before the hardware has finished processing WQE. If a second operation is initiated immediately after, it overwrites the shared context in the DMA area.

When the first operation's completion is processed later, it reads this corrupted context, leading to unexpected behavior and incorrect results.

This commit fixes the race by introducing a private context within each IPSec offload object. The shared ASO context is now copied to this private context while the ASO spinlock is held. Subsequent processing uses this saved, per-object context, ensuring its integrity is maintained.

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

PM: runtime: Fix a race condition related to device removal

The following code in pmruntimework() may dereference the dev->parent pointer after the parent device has been freed:

/ Maybe the parent is now able to suspend. / if (parent && !parent->power.ignorechildren) { spinunlock(&dev->power.lock);

spinlock(&parent->power.lock); rpmidle(parent, RPMASYNC); spinunlock(&parent->power.lock);

spinlock(&dev->power.lock); }

Fix this by inserting a flushwork() call in pmruntimeremove().

Without this patch blktest block/001 triggers the following complaint sporadically:

BUG: KASAN: slab-use-after-free in lockacquire+0x70/0x160 Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081 Workqueue: pm pmruntimework Call Trace: <TASK> dumpstacklvl+0x61/0x80 printaddressdescription.constprop.0+0x8b/0x310 printreport+0xfd/0x1d7 kasanreport+0xd8/0x1d0 kasancheckbyte+0x42/0x60 lockacquire.part.0+0x38/0x230 lockacquire+0x70/0x160 rawspinlock+0x36/0x50 rpmsuspend+0xc6a/0xfe0 rpmidle+0x578/0x770 pmruntimework+0xee/0x120 processonework+0xde3/0x1410 workerthread+0x5eb/0xfe0 kthread+0x37b/0x480 retfromfork+0x6cb/0x920 retfromforkasm+0x11/0x20 </TASK>

Allocated by task 4314: kasansavestack+0x2a/0x50 kasansavetrack+0x18/0x40 kasansaveallocinfo+0x3d/0x50 kasankmalloc+0xa0/0xb0 kmallocnoprof+0x311/0x990 scsialloctarget+0x122/0xb60 [scsimod] scsiscantarget+0x101/0x460 [scsimod] scsiscanchannel+0x179/0x1c0 [scsimod] scsiscanhostselected+0x259/0x2d0 [scsimod] storescan+0x2d2/0x390 [scsimod] devattrstore+0x43/0x80 sysfskfwrite+0xde/0x140 kernfsfopwriteiter+0x3ef/0x670 vfswrite+0x506/0x1470 ksyswrite+0xfd/0x230 x64syswrite+0x76/0xc0 x64syscall+0x213/0x1810 dosyscall64+0xee/0xfc0 entrySYSCALL64afterhwframe+0x4b/0x53

Freed by task 4314: kasansavestack+0x2a/0x50 kasansavetrack+0x18/0x40 kasansavefreeinfo+0x3f/0x50 kasanslabfree+0x67/0x80 kfree+0x225/0x6c0 scsitargetdevrelease+0x3d/0x60 [scsimod] devicerelease+0xa3/0x220 kobjectcleanup+0x105/0x3a0 kobjectput+0x72/0xd0 putdevice+0x17/0x20 scsidevicedevrelease+0xacf/0x12c0 [scsimod] devicerelease+0xa3/0x220 kobjectcleanup+0x105/0x3a0 kobjectput+0x72/0xd0 putdevice+0x17/0x20 scsideviceput+0x7f/0xc0 [scsimod] sdevstoredelete+0xa5/0x120 [scsimod] devattrstore+0x43/0x80 sysfskfwrite+0xde/0x140 kernfsfopwriteiter+0x3ef/0x670 vfswrite+0x506/0x1470 ksyswrite+0xfd/0x230 x64syswrite+0x76/0xc0 x64syscall+0x213/0x1810