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

usb: phy: fsl-usb: Fix use-after-free in delayed work during device removal

The delayed work item otgevent is initialized in fslotgconf() and scheduled under two conditions: 1. When a host controller binds to the OTG controller. 2. When the USB ID pin state changes (cable insertion/removal).

A race condition occurs when the device is removed via fslotgremove(): the fslotg instance may be freed while the delayed work is still pending or executing. This leads to use-after-free when the work function fslotgevent() accesses the already freed memory.

The problematic scenario:

(detach thread) | (delayed work) fslotgremove() | kfree(fslotgdev) //FREE| fslotgevent() | og = containerof(...) //USE | og-> //USE

Fix this by calling disabledelayedworksync() in fslotgremove() before deallocating the fslotg structure. This ensures the delayed work is properly canceled and completes execution prior to memory deallocation.

This bug was identified through static analysis.

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

net: cpsw: Execute ndosetrxmode callback in a work queue

Commit 1767bb2d47b7 ("ipv6: mcast: Don't hold RTNL for IPV6ADDMEMBERSHIP and MCASTJOINGROUP.") removed the RTNL lock for IPV6ADDMEMBERSHIP and MCASTJOINGROUP operations. However, this change triggered the following call trace on my BeagleBone Black board: WARNING: net/8021q/vlancore.c:236 at vlanforeach+0x120/0x124, CPU#0: rpcbind/481 RTNL: assertion failed at net/8021q/vlancore.c (236) Modules linked in: CPU: 0 UID: 997 PID: 481 Comm: rpcbind Not tainted 6.19.0-rc7-next-20260130-yocto-standard+ #35 PREEMPT Hardware name: Generic AM33XX (Flattened Device Tree) Call trace: unwindbacktrace from showstack+0x28/0x2c showstack from dumpstacklvl+0x30/0x38 dumpstacklvl from warn+0xb8/0x11c warn from warnslowpathfmt+0x130/0x194 warnslowpathfmt from vlanforeach+0x120/0x124 vlanforeach from cpswaddmcaddr+0x54/0x98 cpswaddmcaddr from hwaddrrefsyncdev+0xc4/0xec hwaddrrefsyncdev from devmcadd+0x78/0x88 devmcadd from igmp6groupadded+0x84/0xec igmp6groupadded from ipv6devmcinc+0x1fc/0x2f0 ipv6devmcinc from ipv6sockmcjoin+0x124/0x1b4 ipv6sockmcjoin from doipv6setsockopt+0x84c/0x1168 doipv6setsockopt from ipv6setsockopt+0x88/0xc8 ipv6setsockopt from dosocksetsockopt+0xe8/0x19c dosocksetsockopt from syssetsockopt+0x84/0xac syssetsockopt from retfastsyscall+0x0/0x54

This trace occurs because vlanforeach() is called within cpswndosetrxmode(), which expects the RTNL lock to be held. Since modifying vlanforeach() to operate without the RTNL lock is not straightforward, and because ndosetrxmode() is invoked both with and without the RTNL lock across different code paths, simply adding rtnllock() in cpswndosetrxmode() is not a viable solution.

To resolve this issue, we opt to execute the actual processing within a work queue, following the approach used by the icssg-prueth driver.

Please note: To reproduce this issue, I manually reverted the changes to am335x-bone-common.dtsi from commit c477358e66a3 ("ARM: dts: am335x-bone: switch to new cpsw switch drv") in order to revert to the legacy cpsw driver.

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

net: octeonepvf: fix freeirq devid mismatch in IRQ rollback

octepvfrequestirqs() requests MSI-X queue IRQs with devid set to ioqvector. If requestirq() fails part-way, the rollback loop calls freeirq() with devid set to 'oct', which does not match the original devid and may leave the irqaction registered.

This can keep IRQ handlers alive while ioqvector is later freed during unwind/teardown, leading to a use-after-free or crash when an interrupt fires.

Fix the error path to free IRQs with the same ioqvector devid used during requestirq().

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

libceph: return the handler error from monhandleauthdone()

Currently any error from cephauthhandlereplydone() is propagated via finishauth() but isn't returned from monhandleauthdone(). This results in higher layers learning that (despite the monitor considering us to be successfully authenticated) something went wrong in the authentication phase and reacting accordingly, but msgr2 still trying to proceed with establishing the session in the background. In the case of secure mode this can trigger a WARN in setupcrypto() and later lead to a NULL pointer dereference inside of prepareauthsignature().

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

wifi: rtlwifi: 8192cu: fix tid out of range in rtl92cutxfilldesc()

TID getting from ieee80211gettid() might be out of range of array size of staentry->tids[], so check TID is less than MAXTIDCOUNT. Othwerwise, UBSAN warn:

UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:514:30 index 10 is out of range for type 'rtltiddata [9]'

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

KVM: Disallow toggling KVMMEMGUESTMEMFD on an existing memslot

Reject attempts to disable KVMMEMGUESTMEMFD on a memslot that was initially created with a guestmemfd binding, as KVM doesn't support toggling KVMMEMGUESTMEMFD on existing memslots. KVM prevents enabling KVMMEMGUESTMEMFD, but doesn't prevent clearing the flag.

Failure to reject the new memslot results in a use-after-free due to KVM not unbinding from the guestmemfd instance. Unbinding on a FLAGSONLY change is easy enough, and can/will be done as a hardening measure (in anticipation of KVM supporting dirty logging on guestmemfd at some point), but fixing the use-after-free would only address the immediate symptom.

================================================================== BUG: KASAN: slab-use-after-free in kvmgmemrelease+0x362/0x400 [kvm] Write of size 8 at addr ffff8881111ae908 by task repro/745

CPU: 7 UID: 1000 PID: 745 Comm: repro Not tainted 6.18.0-rc6-115d5de2eef3-next-kasan #3 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dumpstacklvl+0x51/0x60 printreport+0xcb/0x5c0 kasanreport+0xb4/0xe0 kvmgmemrelease+0x362/0x400 [kvm] fput+0x2fa/0x9d0 taskworkrun+0x12c/0x200 doexit+0x6ae/0x2100 dogroupexit+0xa8/0x230 x64sysexitgroup+0x3a/0x50 x64syscall+0x737/0x740 dosyscall64+0x5b/0x900 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7f581f2eac31 </TASK>

Allocated by task 745 on cpu 6 at 9.746971s: kasansavestack+0x20/0x40 kasansavetrack+0x13/0x50 kasankmalloc+0x77/0x90 kvmsetmemoryregion.part.0+0x652/0x1110 [kvm] kvmvmioctl+0x14b0/0x3290 [kvm] x64sysioctl+0x129/0x1a0 dosyscall64+0x5b/0x900 entrySYSCALL64afterhwframe+0x4b/0x53

Freed by task 745 on cpu 6 at 9.747467s: kasansavestack+0x20/0x40 kasansavetrack+0x13/0x50 kasansavefreeinfo+0x37/0x50 kasanslabfree+0x3b/0x60 kfree+0xf5/0x440 kvmsetmemslot+0x3c2/0x1160 [kvm] kvmsetmemoryregion.part.0+0x86a/0x1110 [kvm] kvmvmioctl+0x14b0/0x3290 [kvm] x64sysioctl+0x129/0x1a0 dosyscall64+0x5b/0x900 entrySYSCALL64afterhwframe+0x4b/0x53

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

net/handshake: duplicate handshake cancellations leak socket

When a handshake request is cancelled it is removed from the handshakenet->hnrequests list, but it is still present in the handshakerhashtbl until it is destroyed.

If a second cancellation request arrives for the same handshake request, then removepending() will return false... and assuming HANDSHAKEFREQCOMPLETED isn't set in req->hrflags, we'll continue processing through the outtrue label, where we put another reference on the sock and a refcount underflow occurs.

This can happen for example if a handshake times out - particularly if the SUNRPC client sends the AUTHTLS probe to the server but doesn't follow it up with the ClientHello due to a problem with tlshd. When the timeout is hit on the server, the server will send a FIN, which triggers a cancellation request via xsresettransport(). When the timeout is hit on the client, another cancellation request happens via xstlshandshakesync().

Add a testandsetbit(HANDSHAKEFREQCOMPLETED) in the pending cancel path so duplicate cancels can be detected.

ALSA: firewire-motu: add bounds check in putuser loop for DSP events

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

spi: tegra210-quad: Fix timeout handling

When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached.

While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the currxfer field pointing at stale memory.

To avoid this, clear currxfer to NULL upon timeout and check for this condition when the IRQ thread is finally run.

While at it, also make sure to clear interrupts on failure so that new interrupts can be run.

A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.

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

drm/panthor: Prevent potential UAF in group creation

This commit prevents the possibility of a use after free issue in the GROUPCREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUPDESTROY ioctl from another thread around the same time as GROUPCREATE ioctl.

To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUPCREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet.

v2: Add R-bs and fixes tags

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

crypto: aead - Fix reqsize handling

Commit afddce13ce81d ("crypto: api - Add reqsize to cryptoalg") introduced crareqsize field in cryptoalg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks.

However, this is being recommended for use in all crypto algs instead of setting reqsize using cryptosetreqsize(). Using crareqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from crareqsize. [1]

Add proper setreqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework.

[1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b

ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events

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

staging: rtl8723bs: fix out-of-bounds read in rtwgetie() parser

The Information Element (IE) parser rtwgetie() trusted the length byte of each IE without validating that the IE body (len bytes after the 2-byte header) fits inside the remaining frame buffer. A malformed frame can advertise an IE length larger than the available data, causing the parser to increment its pointer beyond the buffer end. This results in out-of-bounds reads or, depending on the pattern, an infinite loop.

Fix by validating that (offset + 2 + len) does not exceed the limit before accepting the IE or advancing to the next element.

This prevents OOB reads and ensures the parser terminates safely on malformed frames.

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

nvme-multipath: fix lockdep WARN due to partition scan work

Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->openmutex, kblockd workqueue completion and partitionscanwork completion.

To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partitionscanwork not by kblockd workqueue but by nvmewq.

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

drm/radeon: Remove calls to drmputdev()

Since the allocation of the drivers main structure was changed to devmdrmdevalloc() drmputdev()'ing to trigger it to be free'd should be done by devres.

However, drmputdev() is still in the probe error and device remove paths. When the driver fails to probe warnings like the following are shown because devres is trying to drmputdev() after the driver already did it.

[ 5.642230] radeon 0000:01:05.0: probe with driver radeon failed with error -22 [ 5.649605] ------------[ cut here ]------------ [ 5.649607] refcountt: underflow; use-after-free. [ 5.649620] WARNING: CPU: 0 PID: 357 at lib/refcount.c:28 refcountwarnsaturate+0xbe/0x110

(cherry picked from commit 3eb8c0b4c091da0a623ade0d3ee7aa4a93df1ea4)

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

ASoC: Intel: avs: Disable periods-elapsed work when closing PCM

avsdaifeshutdown() handles the shutdown procedure for HOST HDAudio stream while period-elapsed work services its IRQs. As the former frees the DAI's private context, these two operations shall be synchronized to avoid slab-use-after-free or worse errors.

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

virtio-net: fix received length check in big packets

Since commit 4959aebba8c0 ("virtio-net: use mtu size as buffer length for big packets"), when guest gso is off, the allocated size for big packets is not MAXSKBFRAGS PAGESIZE anymore but depends on negotiated MTU. The number of allocated frags for big packets is stored in vi->bigpacketsnumskbfrags.

Because the host announced buffer length can be malicious (e.g. the host vhostnet driver's getrxbufs is modified to announce incorrect length), we need a check in virtionet receive path. Currently, the check is not adapted to the new change which can lead to NULL page pointer dereference in the below while loop when receiving length that is larger than the allocated one.

This commit fixes the received length check corresponding to the new change.

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

gpio: cdev: make sure the cdev fd is still active before emitting events

With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier.

Using the regular getfile() routine in this situation triggers the following warning:

struct file::fcount incremented from zero; use-after-free condition present!

So use the getfileactive() variant that will return NULL on file descriptors that have been or are being released.

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

btrfs: fix incorrect splitting in btrfsdropextentmaprange

In production we were seeing a variety of WARNON()'s in the extentmap code, specifically in btrfsdropextentmaprange() when we have to call addextentmapping() for our second split.

Consider the following extent map layout

PINNED [0 16K) [32K, 48K)

and then we call btrfsdropextentmaprange for [0, 36K), with skippinned == true. The initial loop will have

start = 0 end = 36K len = 36K

we will find the [0, 16k) extent, but since we are pinned we will skip it, which has this code

start = emend; if (end != (u64)-1) len = start + len - emend;

emend here is 16K, so now the values are

start = 16K len = 16K + 36K - 16K = 36K

len should instead be 20K. This is a problem when we find the next extent at [32K, 48K), we need to split this extent to leave [36K, 48k), however the code for the split looks like this

split->start = start + len; split->len = emend - (start + len);

In this case we have

emend = 48K split->start = 16K + 36K // this should be 16K + 20K split->len = 48K - (16K + 36K) // this overflows as 16K + 36K is 52K

and now we have an invalid extentmap in the tree that potentially overlaps other entries in the extent map. Even in the non-overlapping case we will have split->start set improperly, which will cause problems with any block related calculations.

We don't actually need len in this loop, we can simply use end as our end point, and only adjust start up when we find a pinned extent we need to skip.

Adjust the logic to do this, which keeps us from inserting an invalid extent map.

We only skippinned in the relocation case, so this is relatively rare, except in the case where you are running relocation a lot, which can happen with auto relocation on.

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

soundwire: fix enumeration completion

The soundwire subsystem uses two completion structures that allow drivers to wait for soundwire device to become enumerated on the bus and initialised by their drivers, respectively.

The code implementing the signalling is currently broken as it does not signal all current and future waiters and also uses the wrong reinitialisation function, which can potentially lead to memory corruption if there are still waiters on the queue.

Not signalling future waiters specifically breaks sound card probe deferrals as codec drivers can not tell that the soundwire device is already attached when being reprobed. Some codec runtime PM implementations suffer from similar problems as waiting for enumeration during resume can also timeout despite the device already having been enumerated.

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

drm/ttm: Don't leak a resource on swapout move error

If moving the bo to system for swapout failed, we were leaking a resource. Fix.

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

md/raid5: Remove unnecessary bioput() in raid5readonechunk()

When running chunk-sized reads on disks with badblocks duplicate bio free/puts are observed:

============================================================================= BUG bio-200 (Not tainted): Object already free ----------------------------------------------------------------------------- Allocated in mempoolallocslab+0x17/0x20 age=3 cpu=2 pid=7504 slaballoc.constprop.0+0x5a/0xb0 kmemcachealloc+0x31e/0x330 mempoolallocslab+0x17/0x20 mempoolalloc+0x100/0x2b0 bioallocbioset+0x181/0x460 dompagereadpage+0x776/0xd00 mpagereadahead+0x166/0x320 blkdevreadahead+0x15/0x20 readpages+0x13f/0x5f0 pagecacheraunbounded+0x18d/0x220 forcepagecachera+0x181/0x1c0 pagecachesyncra+0x65/0xb0 filemapgetpages+0x1df/0xaf0 filemapread+0x1e1/0x700 blkdevreaditer+0x1e5/0x330 vfsread+0x42a/0x570 Freed in mempoolfreeslab+0x17/0x20 age=3 cpu=2 pid=7504 kmemcachefree+0x46d/0x490 mempoolfreeslab+0x17/0x20 mempoolfree+0x66/0x190 biofree+0x78/0x90 bioput+0x100/0x1a0 raid5makerequest+0x2259/0x2450 mdhandlerequest+0x402/0x600 mdsubmitbio+0xd9/0x120 submitbio+0x11f/0x1b0 submitbionoacctnocheck+0x204/0x480 submitbionoacct+0x32e/0xc70 submitbio+0x98/0x1a0 mpagereadahead+0x250/0x320 blkdevreadahead+0x15/0x20 readpages+0x13f/0x5f0 pagecacheraunbounded+0x18d/0x220 Slab 0xffffea000481b600 objects=21 used=0 fp=0xffff8881206d8940 flags=0x17ffffc0010201(locked|slab|head|node=0|zone=2|lastcpupid=0x1fffff) CPU: 0 PID: 34525 Comm: kworker/u24:2 Not tainted 6.0.0-rc2-localyes-265166-gf11c5343fa3f #143 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: raid5wq raid5dowork Call Trace: <TASK> dumpstacklvl+0x5a/0x78 dumpstack+0x10/0x16 printtrailer+0x158/0x165 objecterr+0x35/0x50 freedebugprocessing.cold+0xb7/0xbe slabfree+0x1ae/0x330 kmemcachefree+0x46d/0x490 mempoolfreeslab+0x17/0x20 mempoolfree+0x66/0x190 biofree+0x78/0x90 bioput+0x100/0x1a0 mpageendio+0x36/0x150 bioendio+0x2fd/0x360 mdendioacct+0x7e/0x90 bioendio+0x2fd/0x360 handlefailedstripe+0x960/0xb80 handlestripe+0x1348/0x3760 handleactivestripes.constprop.0+0x72a/0xaf0 raid5dowork+0x177/0x330 processonework+0x616/0xb20 workerthread+0x2bd/0x6f0 kthread+0x179/0x1b0 retfromfork+0x22/0x30 </TASK>

The double free is caused by an unnecessary bioput() in the if(isbadblock(...)) error path in raid5readonechunk().

The error path was moved ahead of bioallocclone() in c82aa1b76787c ("md/raid5: move checking badblock before clone bio in raid5readonechunk"). The previous code checked and freed alignbio which required a bioput. After the move that is no longer needed as raidbio is returned to the control of the common io path which performs its own endio resulting in a double free on bad device blocks.

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

net: rds: don't hold sock lock when cancelling work from rdstcpresetcallbacks()

syzbot is reporting lockdep warning at rdstcpresetcallbacks() [1], for commit ac3615e7f3cffe2a ("RDS: TCP: Reduce code duplication in rdstcpresetcallbacks()") added canceldelayedworksync() into a section protected by locksock() without realizing that rdssendxmit() might call locksock().

We don't need to protect canceldelayedworksync() using locksock(), for even if rds{send,recv}worker() re-queued this work while flushwork() from canceldelayedworksync() was waiting for this work to complete, retried rds{send,recv}worker() is no-op due to the absence of RDSCONNUP bit.

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

dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation

Make sure to drop the reference taken when looking up the crossbar platform device during am335x route allocation.

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

ipv4: Fix reference count leak when using error routes with nexthop objects

When a nexthop object is deleted, it is marked as dead and then fibtableflush() is called to flush all the routes that are using the dead nexthop.

The current logic in fibtableflush() is to only flush error routes (e.g., blackhole) when it is called as part of network namespace dismantle (i.e., with flushall=true). Therefore, error routes are not flushed when their nexthop object is deleted:

# ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show blackhole 198.51.100.2 nhid 1 dev dummy1

As such, they keep holding a reference on the nexthop object which in turn holds a reference on the nexthop device, resulting in a reference count leak:

# ip link del dev dummy1 [ 70.516258] unregisternetdevice: waiting for dummy1 to become free. Usage count = 2

Fix by flushing error routes when their nexthop is marked as dead.

IPv6 does not suffer from this problem.

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

mm/damon/sysfs: cleanup attrs subdirs on context dir setup failure

When a context DAMON sysfs directory setup is failed after setup of attrs/ directory, subdirectories of attrs/ directory are not cleaned up. As a result, DAMON sysfs interface is nearly broken until the system reboots, and the memory for the unremoved directory is leaked.

Cleanup the directories under such failures.

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

scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue

When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash.

Add flag 'ioadminresetsync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable.

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

libceph: fix potential use-after-free in havemonandosdmap()

The wait loop in cephopensession() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both cephmonchandlemap() and handleonemap() install a new map immediately after freeing the old one

kfree(monc->monmap); monc->monmap = monmap;

cephosdmapdestroy(osdc->osdmap); osdc->osdmap = newmap;

under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in havemonandosdmap() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in

client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch;

condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled:

BUG: KASAN: slab-use-after-free in havemonandosdmap+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: <TASK> havemonandosdmap+0x56/0x70 cephopensession+0x182/0x290 cephgettree+0x333/0x680 vfsgettree+0x49/0x180 donewmount+0x1a3/0x2d0 pathmount+0x6dd/0x730 domount+0x99/0xe0 dosysmount+0x141/0x180 dosyscall64+0x9f/0x100 entrySYSCALL64afterhwframe+0x76/0x7e </TASK>

Allocated by task 13305: cephosdmapalloc+0x16/0x130 cephosdcinit+0x27a/0x4c0 cephcreateclient+0x153/0x190 createfsclient+0x50/0x2a0 cephgettree+0xff/0x680 vfsgettree+0x49/0x180 donewmount+0x1a3/0x2d0 pathmount+0x6dd/0x730 domount+0x99/0xe0 dosysmount+0x141/0x180 dosyscall64+0x9f/0x100 entrySYSCALL64afterhwframe+0x76/0x7e

Freed by task 9475: kfree+0x212/0x290 handleonemap+0x23c/0x3b0 cephosdchandlemap+0x3c9/0x590 mondispatch+0x655/0x6f0 cephconprocessmessage+0xc3/0xe0 cephconv1tryread+0x614/0x760 cephconworkfn+0x2de/0x650 processonework+0x486/0x7c0 processscheduledworks+0x73/0x90 workerthread+0x1c8/0x2a0 kthread+0x2ec/0x300 retfromfork+0x24/0x40 retfromforkasm+0x1a/0x30

Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mounttimeout could be exceeded in case waiteventinterruptibletimeout() slept more than once) and access client->autherr under client->monc.mutex to match how it's set in finishauth().

monmapshow() and osdmapshow() now take the respective lock before accessing the map as well.

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

ASoC: Intel: bytcrrt5640: Fix invalid quirk input mapping

When an invalid value is passed via quirk option, currently bytcrrt5640 driver only shows an error message but leaves as is. This may lead to unepxected results like OOB access.

This patch corrects the input mapping to the certain default value if an invalid value is passed.

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

devlink: rate: Unset parent pointer in devlratenodesdestroy

The function devlratenodesdestroy is documented to "Unset parent for all rate objects". However, it was only calling the driver-specific rateleafparentset or ratenodeparentset ops and decrementing the parent's refcount, without actually setting the devlinkrate->parent pointer to NULL.

This leaves a dangling pointer in the devlinkrate struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of devlinknlrateparentnodeset, where the parent pointer is correctly cleared.

This patch fixes the issue by explicitly setting devlinkrate->parent to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects.

[1] repro steps: echo 1 > /sys/bus/netdevsim/newdevice devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriovnumvfs devlink port function rate add netdevsim/netdevsim1/testnode devlink port function rate set netdevsim/netdevsim1/128 parent testnode echo 1 > /sys/bus/netdevsim/deldevice

dmesg: refcountt: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcountwarnsaturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcountwarnsaturate+0x42/0xe0 Call Trace: <TASK> devlrateleafdestroy+0x8d/0x90 nsimdevportdel+0x6c/0x70 [netdevsim] nsimdevreloaddestroy+0x11c/0x140 [netdevsim] nsimdrvremove+0x2b/0xb0 [netdevsim] devicereleasedriverinternal+0x194/0x1f0 busremovedevice+0xc6/0x130 devicedel+0x159/0x3c0 deviceunregister+0x1a/0x60 deldevicestore+0x111/0x170 [netdevsim] kernfsfopwriteiter+0x12e/0x1e0 vfswrite+0x215/0x3d0 ksyswrite+0x5f/0xd0 dosyscall64+0x55/0x10f0 entrySYSCALL64afterhwframe+0x4b/0x53

[2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5ib mlx5fwctl mlx5core

dmesg: refcountt: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcountwarnsaturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7forupstreammindebug202510021244 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcountwarnsaturate+0x42/0xe0 Call Trace: <TASK> devlrateleafdestroy+0x8d/0x90 mlx5eswoffloadsdevlinkportunregister+0x33/0x60 [mlx5core] mlx5eswoffloadsunloadrep+0x3f/0x50 [mlx5core] mlx5eswitchunloadsfvport+0x40/0x90 [mlx5core] mlx5sfeswevent+0xc4/0x120 [mlx5core] notifiercallchain+0x33/0xa0 blockingnotifiercallchain+0x3b/0x50 mlx5eswitchdisablelocked+0x50/0x110 [mlx5core] mlx5eswitchdisable+0x63/0x90 [mlx5core] mlx5unload+0x1d/0x170 [mlx5core] mlx5uninitone+0xa2/0x130 [mlx5core] removeone+0x78/0xd0 [mlx5core] pcideviceremove+0x39/0xa0 devicereleasedriverinternal+0x194/0x1f0 unbindstore+0x99/0xa0 kernfsfopwriteiter+0x12e/0x1e0 vfswrite+0x215/0x3d0 ksyswrite+0x5f/0xd0 dosyscall64+0x53/0x1f0 entrySYSCALL64afterhwframe+0x4b/0x53