In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: validate Dirty Page Table capacity in logreplay copylcns
In the analysis pass of $LogFile journal replay, logreplay() copies LCNs from each action log record into an existing Dirty Page Table (DPT) entry without bounding the destination index. A crafted NTFS image with DPT entry lcnsfollow=1 and an action log record with lcnsfollow=2 produces a kernel slab out-of-bounds write at mount time:
BUG: KASAN: slab-out-of-bounds in logreplay+0x654c/0xdb60 Write of size 8 at addr ffff8880095e1040 by task mount
Two attacker-controlled fields can drive j+i past the allocated pagelcns[] array:
1. dp->lcnsfollow (capacity) can be smaller than lrh->lcnsfollow. 2. lrh->targetvcn may be smaller than dp->vcn, making the u64 subtraction wrap to a huge sizet.
Validate target VCN delta and per-record LCN count against the DPT entry capacity, bail via the existing out: cleanup label with -EINVAL.
This mirrors the bounds-check pattern added in commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot") and commit 0ca0485e4b2e ("fs/ntfs3: validate rec->used in journal-replay file record check").
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: add a permission check for FSCTLSETZERODATA
FSCTLSETZERODATA in smb2ioctl() destroys file data via ksmbdvfszerodata() -> vfsfallocate(PUNCHHOLE/ZERORANGE) after checking only the share-level KSMBDTREECONNFLAGWRITABLE, with no per-handle access check. A handle opened with only FILEWRITEATTRIBUTES still yields an FMODEWRITE filp (FILEWRITEATTRIBUTES is part of FILEWRITEDESIREACCESSLE, so smb2createopenflags() opens it OWRONLY), so the vfsfallocate FMODEWRITE check does not stop it; only the missing fp->daccess gate would. Reproduced on mainline 7.1-rc7 with KASAN by an authenticated SMB client: a FILEWRITEATTRIBUTES-only handle zeroed 4096 bytes of file data it had no FILEWRITEDATA right to (6/6; a FILEREADDATA-only handle was correctly denied).
This is the unfixed sibling of commit cc57232cae23 ("ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTLSETSPARSE"). Because SETZERODATA writes data (not an attribute), require FILEWRITEDATA.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: require source read access for duplicate extents
FSCTLDUPLICATEEXTENTSTOFILE passes the source file directly to vfsclonefilerange() or vfscopyfilerange() without checking the SMB access mask granted to the source handle. A handle opened with attribute access can consequently be used to copy file contents into an attacker-readable destination.
Require FILEREADDATA on the source handle before either VFS operation, matching other ksmbd data-copy paths.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix UAF of struct filelock in SMB2LOCK deferred-lock cancellation
When a blocking byte-range lock request is deferred in the FILELOCKDEFERRED path, ksmbd registers the asynchronous work into the connection's asyncrequests list via setupasyncwork(). The cancel callback smb2removeblockedlock() holds a reference to the flock.
If the lock waiter is subsequently woken up but the work state is no longer KSMBDWORKACTIVE (e.g., due to a concurrent cancellation), the cleanup path calls locksfreelock(flock) without dequeuing the work from the asyncrequests list. Concurrently, smb2cancel() walks the list under conn->requestlock and invokes the cancel callback, which then dereferences the already freed 'flock'. This leads to a slab-use-after-free inside wakeupcommon.
Fix this by restructuring the cleanup logic after the worker returns from ksmbdvfsposixlockwait(). Move listdel(&smblock->llist) and releaseasyncwork(work) to the top of the cleanup block. This guarantees that the async work is completely dequeued and serialized under conn->requestlock before locksfreelock(flock) is called, rendering the flock unreachable for any concurrent smb2cancel().
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: add a WRITEDAC/WRITEOWNER check to SMB2 SETINFO SECURITY
commit cc57232cae23 ("ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTLSETSPARSE") added a fp->daccess gate to fsctlsetsparse and noted that "similar handle-level checks exist in other functions but are missing here." The SMB2 SETINFO SECURITY arm is one of the missing ones, and the most security-relevant: smb2setinfosec() calls setinfosec() with no per-handle access check.
setinfosec() (fs/smb/server/smbacl.c) re-permissions the file: it rewrites owner/group/mode via notifychange(), rewrites the POSIX ACL via setposixacl(), and on KSMBDSHAREFLAGACLXATTR shares removes and rewrites the Windows security descriptor via ksmbdvfssetsdxattr(). Every other persistent-mutation arm of the sibling handler smb2setinfofile() checks fp->daccess first (FILEWRITEDATA / FILEDELETE / FILEWRITEEA / FILEWRITEATTRIBUTES); the SECURITY arm — which mutates the access control itself — is the only one with no gate.
A client can therefore open a handle with FILEWRITEATTRIBUTES only (no FILEWRITEDAC / FILEWRITEOWNER) and use SMB2SETINFO with InfoType SMB2OINFOSECURITY to rewrite the file's DACL and owner, granting itself access the handle's daccess never carried. Unlike the FSCTL data arms this is a metadata/xattr operation, so there is no FMODEWRITE VFS backstop — the missing fp->daccess check is the entire gate.
Setting a security descriptor is the WRITEDAC / WRITEOWNER operation, so require at least one of those on the handle before re-permissioning the file. -EACCES is mapped to STATUSACCESSDENIED by smb2setinfo().
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: track the connection owning a byte-range lock
SMB2LOCK adds each granted byte-range lock to both the file lock list and the lock list of the connection which handled the request. The final close and durable handle paths, however, remove the connection list entry while holding fp->conn->llistlock.
With SMB3 multichannel, the connection handling the LOCK request can be different from the connection which opened the file. The entry can therefore be removed under a different spinlock from the one protecting the list it belongs to. A concurrent traversal can then access freed struct ksmbdlock and struct filelock objects.
Record the connection owning each lock's clist entry and hold a reference to it while the entry is linked. Use that connection and its llistlock for unlock, rollback, close, and durable preserve. Durable reconnect assigns the new connection as the owner when publishing the locks again.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate NTLMv2 response before updating session key
ksmbdauthntlmv2() derives the NTLMv2 session key into sess->sesskey before it verifies the NTLMv2 response. ksmbddecodentlmsspauthblob() then continues into KEYXCH even when ksmbdauthntlmv2() failed.
With SMB3 multichannel binding, the failed authentication operates on an existing session and the session setup error path does not expire binding sessions. A client can send a binding session setup with a bad NT proof and KEYXCH and still modify sess->sesskey before STATUSLOGONFAILURE is returned.
Relevant path:
smb2sesssetup() -> conn->binding = true -> ntlmauthenticate() -> sessionuser() -> ksmbddecodentlmsspauthblob() -> ksmbdauthntlmv2() -> calcntlmv2hash() -> hmacmd5usingrawkey(..., sess->sesskey) -> cryptomemneq() returns mismatch -> KEYXCH arc4crypt(..., sess->sesskey, ...) -> outerr without expiring the binding session
Derive the base session key into a local buffer and copy it to sess->sesskey only after the proof matches. Return immediately on authentication failure so KEYXCH is only processed after successful authentication.
In the Linux kernel, the following vulnerability has been resolved:
power: reset: linkstation-poweroff: fix use-after-free in the linkstationpoweroffinit()
Move ofnodeput(dn) after the ofmatchnode() call, which still needs the node pointer. The node reference is correctly released after use.
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: Fix iommumapsgtable() return value check and avoid WARN
Commit "iommu: return full error code from iommumapsgatomic" changed iommumapsgtable() to return an ssizet and negative values in error cases, rather than a sizet and a zero.
Store the return value in the appropriate type and in case of error, return it rather than WARNing.
Patchwork: https://patchwork.freedesktop.org/patch/719685/
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate SID in parent security descriptor during ACL inheritance
Introduce smbvalidatentsdsid() helper to safely validate Owner SID and Group SID inside the NT Security Descriptor (smbntsd) retrieved from the parent directory.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: ioam: add NULL check for idev in ipv6hopioam()
Reported by Sashiko:
The function ipv6hopioam() accesses in6devget(skb->dev)->cnf.ioam6enabled without validating the returned idev pointer. Because addrconfifdown() can concurrently clear dev->ip6ptr via RCU, in6devget() can return NULL during interface teardown, which could cause a NULL pointer dereference when processing an IOAM Hop-by-Hop option.
Let's add a check and use SKBDROPREASONIPV6DISABLED accordingly.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xtables: add and use xtablesunregistertableexit
Previous change added xtablesunregistertablepreexit to detach the table from the packetpath and to unlink it from the active table list. In case of rmmod, userspace that is doing set/getsockopt for this table will not be able to re-instantiate the table: 1. The larval table has been removed already 2. existing instantiated table is no longer on the xt pernet table list.
This adds the second stage helper:
unlink the table from the dying list, free the hook ops (if any) and do the audit notification. It replaces xtunregistertable().
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ebtables: move to two-stage removal scheme
Like previous patches for xtables, follow same pattern in ebtables. We can't reuse xt helpers: ebttable struct layout is incompatible.
table->ops assignment is now done while still holding the ebt mutex to make sure we never expose partially-filled table struct.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free of a deferred filelock on double SMB2CANCEL
A deferred byte-range lock (an SMB2LOCK that blocks) registers an async work on conn->asyncrequests via setupasyncwork(), with cancelfn = smb2removeblockedlock and cancelargv[0] pointing at the struct filelock.
When the request is cancelled, the worker frees the filelock with locksfreelock() and takes the cancelled early-exit, which "goto out"s and never reaches releaseasyncwork() -- the only site that unlinks the work from conn->asyncrequests and clears cancelfn/cancelargv. The work therefore stays matchable on asyncrequests with a live cancelfn pointing at the freed filelock, until connection teardown finally runs releaseasyncwork().
smb2cancel() fires cancelfn unconditionally with no state guard, so a second SMB2CANCEL for the same AsyncId, arriving in that window, re-runs smb2removeblockedlock() on the freed filelock -- a slab use-after-free:
BUG: KASAN: slab-use-after-free in locksdeleteblock locksdeleteblock locksdeleteblock ksmbdvfsposixlockunblock smb2removeblockedlock smb2cancel <- 2nd SMB2CANCEL fires cancelfn handleksmbdwork Allocated by ...: locksalloclock <- smb2lock Freed by ...: locksfreelock <- smb2lock (cancelled branch) ... cache filelockcache of size 192
Reproduced on mainline with KASAN by an authenticated SMB client.
Skip a work whose state is already KSMBDWORKCANCELLED so its cancel callback cannot be fired a second time.
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: rtwmlme: add bounds checks before ielength subtraction
Add guards to ensure ielength is large enough before subtracting fixed IE offsets to prevent unsigned integer underflow.
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix buffer over-read in rtwupdateprotection
rtwupdateprotection() is called with a pointer offset into the ies buffer but the full ielength is passed, causing a potential buffer over-read.
In the Linux kernel, the following vulnerability has been resolved:
net, bpf: fix null-ptr-deref in xdpmasterredirect() for down master
syzkaller reported a kernel panic in bondrrgenslaveid() reached via xdpmasterredirect(). Full decoded trace:
https://syzkaller.appspot.com/bug?extid=80e046b8da2820b6ba73
bondrrgenslaveid() dereferences bond->rrtxcounter, a per-CPU counter that bonding only allocates in bondopen() when the mode is round-robin. If the bond device was never brought up, rrtxcounter stays NULL.
The XDP redirect path can still reach that code on a bond that was never opened: bpfmasterredirectenabledkey is a global static key, so as soon as any bond device has native XDP attached, the XDPTX -> xdpmasterredirect() interception is enabled for every slave system-wide. The path xdpmasterredirect() -> bondxdpgetxmitslave() -> bondxdpxmitroundrobinslaveget() -> bondrrgenslaveid() then runs against a bond that has no rrtxcounter and crashes.
Fix this in the generic xdpmasterredirect() by refusing to call into the master's ->ndoxdpgetxmitslave() when the master device is not up. IFFUP is only set after ->ndoopen() has successfully returned, so this reliably excludes masters whose XDP state has not been fully initialized. Drop the frame with XDPABORTED so the exception is visible via tracexdpexception() rather than silently falling through. This is not specific to bonding: any current or future master that defers XDP state allocation to ->ndoopen() is protected.
bpf, sockmap: Fix afunix null-ptr-deref in proto update
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Take state lock for afunix iter
When a BPF iterator program updates a sockmap, there is a race condition in unixstreambpfupdateproto() where the peer pointer can become stale[1] during a state transition TCPESTABLISHED -> TCPCLOSE.
CPU0 bpf CPU1 close -------- ---------- // unixstreambpfupdateproto() skpair = unixpeer(sk) if (unlikely(!skpair)) return -EINVAL; // unixreleasesock() skpair = unixpeer(sk); unixpeer(sk) = NULL; sockput(skpair) sockhold(skpair) // UaF
More practically, this fix guarantees that the iterator program is consistently provided with a unix socket that remains stable during iterator execution.
[1]: BUG: KASAN: slab-use-after-free in unixstreambpfupdateproto+0x155/0x490 Write of size 4 at addr ffff8881178c9a00 by task testprogs/2231 Call Trace: dumpstacklvl+0x5d/0x80 printreport+0x170/0x4f3 kasanreport+0xe4/0x1c0 kasancheckrange+0x125/0x200 unixstreambpfupdateproto+0x155/0x490 sockmaplink+0x71c/0xec0 sockmapupdatecommon+0xbc/0x600 sockmapupdateelem+0x19a/0x1f0 bpfprogbbbf56096cdd4f01selectivedumpunix+0x20c/0x217 bpfiterrunprog+0x21e/0xae0 bpfiterunixseqshow+0x1e0/0x2a0 bpfseqread+0x42c/0x10d0 vfsread+0x171/0xb20 ksysread+0xff/0x200 dosyscall64+0xf7/0x5e0 entrySYSCALL64afterhwframe+0x76/0x7e
Allocated by task 2236: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasanslaballoc+0x63/0x80 kmemcacheallocnoprof+0x1d5/0x680 skprotalloc+0x59/0x210 skalloc+0x34/0x470 unixcreate1+0x86/0x8a0 unixstreamconnect+0x318/0x15b0 sysconnect+0xfd/0x130 x64sysconnect+0x72/0xd0 dosyscall64+0xf7/0x5e0 entrySYSCALL64afterhwframe+0x76/0x7e
Freed by task 2236: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x70 kasanslabfree+0x47/0x70 kmemcachefree+0x11c/0x590 skdestruct+0x432/0x6e0 unixreleasesock+0x9b3/0xf60 unixrelease+0x8a/0xf0 sockrelease+0xb0/0x270 sockclose+0x18/0x20 fput+0x36e/0xac0 fputclosesync+0xe5/0x1a0 x64sysclose+0x7d/0xd0 dosyscall64+0xf7/0x5e0 entrySYSCALL64afterhwframe+0x76/0x7e
fs/ntfs3: terminate the cached volume label after UTF-8 conversion
In the Linux kernel, the following vulnerability has been resolved:
afunix: Drop all SCM attributes for SOCKMAP.
SOCKMAP can hide inflight fd from AFUNIX GC.
When a socket in SOCKMAP receives skb with inflight fd, skpsockverdictdataready() looks up the mapped socket and enqueue skb to its psock->ingressskb.
Since neither the old nor the new GC can inspect the psock queue, the hidden skb leaks the inflight sockets. Note that this cannot be detected via kmemleak because inflight sockets are linked to a global list.
In addition, SOCKMAP redirect breaks the Tarjan-based GC's assumption that unixedge.successor is always alive, which is no longer true once skb is redirected, resulting in use-after-free below. [0]
Moreover, SOCKMAP does not call scmstatdel() properly, so unixshowfdinfo() could report an incorrect fd count.
skmsgrecvmsg() does not support any SCM attributes in the first place.
Let's drop all SCM attributes before passing skb to the SOCKMAP layer.
[0]: BUG: KASAN: slab-use-after-free in unixdeledges (net/unix/garbage.c:118 net/unix/garbage.c:181 net/unix/garbage.c:251) Read of size 8 at addr ffff888125362670 by task kworker/56:1/496
CPU: 56 UID: 0 PID: 496 Comm: kworker/56:1 Not tainted 7.0.0-rc7-00263-gb9d8b856689d #3 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: events skpsockbacklog Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:122) printreport (mm/kasan/report.c:379) kasanreport (mm/kasan/report.c:597) unixdeledges (net/unix/garbage.c:118 net/unix/garbage.c:181 net/unix/garbage.c:251) unixdestroyfpl (net/unix/garbage.c:317) unixdestructscm (./include/net/scm.h:80 ./include/net/scm.h:86 net/unix/afunix.c:1976) skpsockbacklog (./include/linux/skbuff.h:?) processscheduledworks (kernel/workqueue.c:?) workerthread (kernel/workqueue.c:?) kthread (kernel/kthread.c:438) retfromfork (arch/x86/kernel/process.c:164) retfromforkasm (arch/x86/entry/entry64.S:258) </TASK>
Allocated by task 955: kasansavetrack (mm/kasan/common.c:58 mm/kasan/common.c:78) kasanslaballoc (mm/kasan/common.c:369) kmemcacheallocnoprof (mm/slub.c:4539) skprotalloc (net/core/sock.c:2240) skalloc (net/core/sock.c:2301) unixcreate1 (net/unix/afunix.c:1099) unixcreate (net/unix/afunix.c:1169) sockcreate (net/socket.c:1606) syssocketpair (net/socket.c:1811) x64syssocketpair (net/socket.c:1863 net/socket.c:1860 net/socket.c:1860) dosyscall64 (arch/x86/entry/syscall64.c:?) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)
Freed by task 496: kasansavetrack (mm/kasan/common.c:58 mm/kasan/common.c:78) kasansavefreeinfo (mm/kasan/generic.c:587) kasanslabfree (mm/kasan/common.c:287) kmemcachefree (mm/slub.c:6165) skdestruct (net/core/sock.c:2282 net/core/sock.c:2384) skpsockdestroy (./include/net/sock.h:?) processscheduledworks (kernel/workqueue.c:?) workerthread (kernel/workqueue.c:?) kthread (kernel/kthread.c:438) retfromfork (arch/x86/kernel/process.c:164) retfromforkasm (arch/x86/entry/entry64.S:258)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: scope conn->binding slowpath to bound sessions only
When the binding SESSIONSETUP sets conn->binding = true, the flag stays set after the call so that the global session lookup in ksmbdsessionlookupall() can find the session, which was not added to conn->sessions. Because the flag is connection-wide, the global lookup path will also resolve any other session by id if asked.
Tighten the global lookup so that the returned session must have this connection registered in its channel xarray (sess->ksmbdchannlist). The channel entry is installed by the existing bindingsession path in ntlmauthenticate()/krb5authenticate() when a SESSIONSETUP completes successfully, so this condition is a strict equivalent of "this connection has been accepted as a channel of this session". Connections that have not bound to a given session cannot reach it via the global table.
The existing conn->binding gate for entering the slowpath is preserved so that non-binding connections keep the fast-path-only behavior, and the session->state check is unchanged.
In the Linux kernel, the following vulnerability has been resolved:
ntfs3: add buffer boundary checks to rununpack()
rununpack() checks runbuf < runlast at the top of the while loop but then reads sizesize and offsetsize bytes via rununpacks64() without verifying they fit within the remaining buffer. A crafted NTFS image with truncated run data in an MFT attribute triggers an OOB heap read of up to 15 bytes when the filesystem is mounted.
Add boundary checks before each rununpacks64() call to ensure the declared field size does not exceed the remaining buffer.
Found by fuzzing with a source-patched harness (LibAFL + QEMU).
In the Linux kernel, the following vulnerability has been resolved:
ntfs3: fix integer overflow in rununpack() volume boundary check
The volume boundary check lcn + len > sbi->used.bitmap.nbits uses raw addition which can wrap around for large lcn and len values, bypassing the validation. Use checkaddoverflow() as is already done for the adjacent prevlcn + dlcn and vcn64 + len checks added by commit 3ac37e100385 ("ntfs3: Fix integer overflow in rununpack()").
Found by fuzzing with a source-patched harness (LibAFL + QEMU).
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot
In the 'DeleteIndexEntryRoot' case of the 'doaction' function, the entry size ('esize') is retrieved from the log record without adequate bounds checking.
Specifically, the code calculates the end of the entry ('e2') using: e2 = Add2Ptr(e1, esize);
It then calculates the size for memmove using 'PtrOffset(e2, ...)', which subtracts the end pointer from the buffer limit. If 'esize' is maliciously large, 'e2' exceeds the used buffer size. This results in a negative offset which, when cast to sizet for memmove, interprets as a massive unsigned integer, leading to a heap buffer overflow.
This commit adds a check to ensure that the entry size ('esize') strictly fits within the remaining used space of the index header before performing memory operations.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate inherited ACE SID length
smbinheritdacl() walks the parent directory DACL loaded from the security descriptor xattr. It verifies that each ACE contains the fixed SID header before using it, but does not verify that the variable-length SID described by sid.numsubauth is fully contained in the ACE.
A malformed inheritable ACE can advertise more subauthorities than are present in the ACE. comparesids() may then read past the ACE. smbsetace() also clamps the copied destination SID, but used the unchecked source SID count to compute the inherited ACE size. That could advance the temporary inherited ACE buffer pointer and ntsize accounting past the allocated buffer.
Fix this by validating the parent ACE SID count and SID length before using the SID during inheritance. Compute the inherited ACE size from the copied SID so the size matches the bounded destination SID. Reject the inherited DACL if size accumulation would overflow smbacl.size or the security descriptor allocation size.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: Don't log keys in SMB3 signing and encryption key generation
When KSMBDDEBUGAUTH logging is enabled, generatesmb3signingkey() and generatesmb3encryptionkey() log the session, signing, encryption, and decryption key bytes. Remove the logs to avoid exposing credentials.
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: handle attrsetsize() errors when truncating files
If attrsetsize() fails while truncating down, the error is silently ignored and the inode may be left in an inconsistent state.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: ioam: fix potential NULL dereferences in ioam6filltracedata()
We need to check in6devget() for possible NULL value, as suggested by Yiming Qian.
Also add skbdstdevrcu() instead of skbdstdev(), and two missing READONCE().
Note that @dev can't be NULL.
In the Linux kernel, the following vulnerability has been resolved:
net: macb: fix clk handling on PCI glue driver removal
platformdeviceunregister() may still want to use the registered clks during runtime resume callback.
Note that there is a commit d82d5303c4c5 ("net: macb: fix use after free on rmmod") that addressed the similar problem of clk vs platform device unregistration but just moved the bug to another place.
Save the pointers to clks into local variables for reuse after platform device is unregistered.
BUG: KASAN: use-after-free in clkprepare+0x5a/0x60 Read of size 8 at addr ffff888104f85e00 by task modprobe/597
CPU: 2 PID: 597 Comm: modprobe Not tainted 6.1.164+ #114 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x8d/0xba printreport+0x17f/0x496 kasanreport+0xd9/0x180 clkprepare+0x5a/0x60 macbruntimeresume+0x13d/0x410 [macb] pmgenericruntimeresume+0x97/0xd0 rpmcallback+0xc8/0x4d0 rpmcallback+0xf6/0x230 rpmresume+0xeeb/0x1a70 pmruntimeresume+0xb4/0x170 busremovedevice+0x2e3/0x4b0 devicedel+0x5b3/0xdc0 platformdevicedel+0x4e/0x280 platformdeviceunregister+0x11/0x50 pcideviceremove+0xae/0x210 deviceremove+0xcb/0x180 devicereleasedriverinternal+0x529/0x770 driverdetach+0xd4/0x1a0 busremovedriver+0x135/0x260 driverunregister+0x72/0xb0 pciunregisterdriver+0x26/0x220 dosysdeletemodule+0x32e/0x550 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x6e/0xd8 </TASK>
Allocated by task 519: kasansavestack+0x2c/0x50 kasansettrack+0x21/0x30 kasankmalloc+0x8e/0x90 clkregister+0x458/0x2890 clkhwregister+0x1a/0x60 clkhwregisterfixedrate+0x255/0x410 clkregisterfixedrate+0x3c/0xa0 macbprobe+0x1d8/0x42e [macbpci] localpciprobe+0xd7/0x190 pcideviceprobe+0x252/0x600 reallyprobe+0x255/0x7f0 driverprobedevice+0x1ee/0x330 driverprobedevice+0x4c/0x1f0 driverattach+0x1df/0x4e0 busforeachdev+0x15d/0x1f0 busadddriver+0x486/0x5e0 driverregister+0x23a/0x3d0 dooneinitcall+0xfd/0x4d0 doinitmodule+0x18b/0x5a0 loadmodule+0x5663/0x7950 dosysfinitmodule+0x101/0x180 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x6e/0xd8
Freed by task 597: kasansavestack+0x2c/0x50 kasansettrack+0x21/0x30 kasansavefreeinfo+0x2a/0x50 kasanslabfree+0x106/0x180 kmemcachefree+0xbc/0x320 clkunregister+0x6de/0x8d0 macbremove+0x73/0xc0 [macbpci] pcideviceremove+0xae/0x210 deviceremove+0xcb/0x180 devicereleasedriverinternal+0x529/0x770 driverdetach+0xd4/0x1a0 busremovedriver+0x135/0x260 driverunregister+0x72/0xb0 pciunregisterdriver+0x26/0x220 dosysdeletemodule+0x32e/0x550 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x6e/0xd8