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

wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode

Currently, whenever there is a need to transmit an Action frame, the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR to firmware. The P2P interfaces were available when wpasupplicant is managing the wlan interface.

However, the P2P interfaces are not created/initialized when only hostapd is managing the wlan interface. And if hostapd receives an ANQP Query REQ Action frame even from an un-associated STA, the brcmfmac driver tries to use an uninitialized P2P vif pointer for sending the IOVAR to firmware. This NULL pointer dereferencing triggers a driver crash.

[ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmfp2psendactionframe+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmfcfg80211mgmttx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211mlmemgmttx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211txmgmt+0x238/0x388 [cfg80211] [ 1417.076281] genlfamilyrcvmsgdoit+0xe0/0x158 [ 1417.076302] genlrcvmsg+0x220/0x2a0 [ 1417.076317] netlinkrcvskb+0x68/0x140 [ 1417.076330] genlrcv+0x40/0x60 [ 1417.076343] netlinkunicast+0x330/0x3b8 [ 1417.076357] netlinksendmsg+0x19c/0x3f8 [ 1417.076370] socksendmsg+0x64/0xc0 [ 1417.076391] syssendmsg+0x268/0x2a0 [ 1417.076408] syssendmsg+0xb8/0x118 [ 1417.076427] syssendmsg+0x90/0xf8 [ 1417.076445] arm64syssendmsg+0x2c/0x40 [ 1417.076465] invokesyscall+0x50/0x120 [ 1417.076486] el0svccommon.constprop.0+0x48/0xf0 [ 1417.076506] doel0svc+0x24/0x38 [ 1417.076525] el0svc+0x30/0x100 [ 1417.076548] el0t64synchandler+0x100/0x130 [ 1417.076569] el0t64sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000)

Fix this, by always using the vif corresponding to the wdev on which the Action frame Transmission request was initiated by the userspace. This way, even if P2P vif is not available, the IOVAR is sent to firmware on AP vif and the ANQP Query RESP Action frame is transmitted without crashing the driver.

Move initcompletion() for "sendafdone" from brcmfp2pcreatep2pdev() to brcmfp2pattach(). Because the former function would not get executed when only hostapd is managing wlan interface, and it is not safe to do reinitcompletion() later in brcmfp2ptxactionframe(), without any prior initcompletion().

And in the brcmfp2ptxactionframe() function, the condition check for P2P Presence response frame is not needed, since the wpasupplicant is properly sending the P2P Presense Response frame on the P2P-GO vif instead of the P2P-Device vif.

[Cc stable]

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.

binfmtmisc: restore write access before closing files opened by openexec()

accel/habanalabs: support mapping cb with vmalloc-backed coherent memory

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

PCI/AER: Fix NULL pointer access by aerinfo

The kzalloc(GFPKERNEL) may return NULL, so all accesses to aerinfo->xxx will result in kernel panic. Fix it.

iio: accel: bmc150: Fix irq assumption regression

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

driver core: fix potential null-ptr-deref in deviceadd()

I got the following null-ptr-deref report while doing fault injection test:

BUG: kernel NULL pointer dereference, address: 0000000000000058 CPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G B W N 6.1.0-rc3+ RIP: 0010:klistput+0x2d/0xd0 Call Trace: <TASK> klistremove+0xf1/0x1c0 devicereleasedriverinternal+0x196/0x210 busremovedevice+0x1bd/0x240 deviceadd+0xd3d/0x1100 w1addmasterdevice+0x476/0x490 [wire] ds2482probe+0x303/0x3e0 [ds2482]

This is how it happened:

w1allocdev() // The dev->driver is set to w1masterdriver. memcpy(&dev->dev, device, sizeof(struct device)); deviceadd() busadddevice() dpmsysfsadd() // It fails, calls busremovedevice.

// error path busremovedevice() // The dev->driver is not null, but driver is not bound. devicereleasedriver() klistremove(&dev->p->knodedriver) <-- It causes null-ptr-deref.

// normal path busprobedevice() // It's not called yet. devicebinddriver()

If dev->driver is set, in the error path after calling busadddevice() in deviceadd(), busremovedevice() is called, then the device will be detached from driver. But devicebinddriver() is not called yet, so it causes null-ptr-deref while access the 'knodedriver'. To fix this, set dev->driver to null in the error path before calling busremovedevice().

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

net: usb: asix: validate PHY address before use

The ASIX driver reads the PHY address from the USB device via asixreadphyaddr(). A malicious or faulty device can return an invalid address (>= PHYMAXADDR), which causes a warning in mdiobusgetphy():

addr 207 out of range WARNING: drivers/net/phy/mdiobus.c:76

Validate the PHY address in asixreadphyaddr() and remove the now-redundant check in ax88172a.c.

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

net/mlx5e: Don't store mlx5epriv in mlx5edev devlink priv

mlx5epriv is an unstable structure that can be memset(0) if profile attaching fails, mlx5epriv in mlx5edev devlink private is used to reference the netdev and mdev associated with that struct. Instead, store netdev directly into mlx5edev and get mdev from the containing mlx5adev aux device structure.

This fixes a kernel oops in mlx5eremove when switchdev mode fails due to change profile failure.

$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5core 0012:03:00.1: mlx5enetdevinitprofile:6214:(pid 37199): mlx5eprivinit failed, err=-12 mlx5core 0012:03:00.1 gpu3rdma1: mlx5enetdevchangeprofile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5core 0012:03:00.1: mlx5enetdevinitprofile:6214:(pid 37199): mlx5eprivinit failed, err=-12 mlx5core 0012:03:00.1 gpu3rdma1: mlx5enetdevchangeprofile: failed to rollback to orig profile, -12

$ devlink dev reload pci/0000:00:03.0 ==> oops

BUG: kernel NULL pointer dereference, address: 0000000000000520 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5eremove+0x68/0x130 RSP: 0018:ffffc900034838f0 EFLAGS: 00010246 RAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10 R10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0 R13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400 FS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0 Call Trace: <TASK> devicereleasedriverinternal+0x19c/0x200 busremovedevice+0xc6/0x130 devicedel+0x160/0x3d0 ? devlparamdriverinitvalueget+0x2d/0x90 mlx5detachdevice+0x89/0xe0 mlx5unloadonedevllocked+0x3a/0x70 mlx5devlinkreloaddown+0xc8/0x220 devlinkreload+0x7d/0x260 devlinknlreloaddoit+0x45b/0x5a0 genlfamilyrcvmsgdoit+0xe8/0x140

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:

iommu/io-pgtable-arm: fix sizet signedness bug in unmap path

armlpaeunmap() returns sizet but was returning -ENOENT (negative error code) when encountering an unmapped PTE. Since sizet is unsigned, -ENOENT (typically -2) becomes a huge positive value (0xFFFFFFFFFFFFFFFE on 64-bit systems).

This corrupted value propagates through the call chain: armlpaeunmap() returns -ENOENT as sizet -> armlpaeunmappages() returns it -> iommuunmap() adds it to iova address -> iommupgsize() triggers BUGON due to corrupted iova

This can cause IOVA address overflow in iommuunmap() loop and trigger BUGON in iommupgsize() from invalid address alignment.

Fix by returning 0 instead of -ENOENT. The WARNON already signals the error condition, and returning 0 (meaning "nothing unmapped") is the correct semantic for sizet return type. This matches the behavior of other io-pgtable implementations (io-pgtable-arm-v7s, io-pgtable-dart) which return 0 on error conditions.

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

l2tp: avoid one data-race in l2tptunneldelwork()

We should read sk->sksocket only when dealing with kernel sockets.

syzbot reported the following data-race:

BUG: KCSAN: data-race in l2tptunneldelwork / skcommonrelease

write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sksetsocket include/net/sock.h:2092 [inline] sockorphan include/net/sock.h:2118 [inline] skcommonrelease+0xae/0x230 net/core/sock.c:4003 udplibclose+0x15/0x20 include/net/udp.h:325 inetrelease+0xce/0xf0 net/ipv4/afinet.c:437 sockrelease net/socket.c:662 [inline] sockclose+0x6b/0x150 net/socket.c:1455 fput+0x29b/0x650 fs/filetable.c:468 fput+0x1c/0x30 fs/filetable.c:496 taskworkrun+0x131/0x1a0 kernel/taskwork.c:233 resumeusermodework include/linux/resumeusermode.h:50 [inline] exittousermodeloop kernel/entry/common.c:44 [inline] exittousermodeloop+0x1fe/0x740 kernel/entry/common.c:75 exittousermodeprepare include/linux/irq-entry-common.h:226 [inline] syscallexittousermodeprepare include/linux/irq-entry-common.h:256 [inline] syscallexittousermodework include/linux/entry-common.h:159 [inline] syscallexittousermode include/linux/entry-common.h:194 [inline] dosyscall64+0x1e1/0x2b0 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f

read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tptunneldelwork+0x2f/0x1a0 net/l2tp/l2tpcore.c:1418 processonework kernel/workqueue.c:3257 [inline] processscheduledworks+0x4ce/0x9d0 kernel/workqueue.c:3340 workerthread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 retfromfork+0x149/0x290 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246

value changed: 0xffff88811b818000 -> 0x0000000000000000

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

mISDN: annotate data-race around dev->work

dev->work can re read locklessly in mISDNread() and mISDNpoll(). Add READONCE()/WRITEONCE() annotations.

BUG: KCSAN: data-race in mISDNioctl / mISDNread

write to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1: misdnaddtimer drivers/isdn/mISDN/timerdev.c:175 [inline] mISDNioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:597 [inline] sesysioctl+0xce/0x140 fs/ioctl.c:583 x64sysioctl+0x43/0x50 fs/ioctl.c:583 x64syscall+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls64.h:17 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xd8/0x2c0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

read to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0: mISDNread+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112 doloopreadvwritev fs/readwrite.c:847 [inline] vfsreadv+0x3fb/0x690 fs/readwrite.c:1020 doreadv+0xe7/0x210 fs/readwrite.c:1080 dosysreadv fs/readwrite.c:1165 [inline] sesysreadv fs/readwrite.c:1162 [inline] x64sysreadv+0x45/0x50 fs/readwrite.c:1162 x64syscall+0x2831/0x3000 arch/x86/include/generated/asm/syscalls64.h:20 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xd8/0x2c0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

value changed: 0x00000000 -> 0x00000001

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:

octeonep: Fix memory leak in octepdevicesetup()

In octepdevicesetup(), if octepctrlnetinit() fails, the function returns directly without unmapping the mapped resources and freeing the allocated configuration memory.

Fix this by jumping to the unsupporteddev label, which performs the necessary cleanup. This aligns with the error handling logic of other paths in this function.

Compile tested only. Issue found using a prototype static analysis tool and code review.

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

gpio: loongson-64bit: Fix incorrect NULL check after devmkcalloc()

Fix incorrect NULL check in loongsongpioinitirqchip(). The function checks chip->parent instead of chip->irq.parents.

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

drm/amd/pm: Disable MMIO access during SMU Mode 1 reset

During Mode 1 reset, the ASIC undergoes a reset cycle and becomes temporarily inaccessible via PCIe. Any attempt to access MMIO registers during this window (e.g., from interrupt handlers or other driver threads) can result in uncompleted PCIe transactions, leading to NMI panics or system hangs.

To prevent this, set the nohwaccess flag to true immediately after triggering the reset. This signals other driver components to skip register accesses while the device is offline.

A memory barrier smpmb() is added to ensure the flag update is globally visible to all cores before the driver enters the sleep/wait state.

(cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)

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

net: liquidio: Initialize netdev pointer before queue setup

In setupnicdevices(), the netdev is allocated using allocetherdevmq(). However, the pointer to this structure is stored in oct->props[i].netdev only after the calls to netifsetrealnumrxqueues() and netifsetrealnumtxqueues().

If either of these functions fails, setupnicdevices() returns an error without freeing the allocated netdev. Since oct->props[i].netdev is still NULL at this point, the cleanup function liquidiodestroynicdevice() will fail to find and free the netdev, resulting in a memory leak.

Fix this by initializing oct->props[i].netdev before calling the queue setup functions. This ensures that the netdev is properly accessible for cleanup in case of errors.

Compile tested only. Issue found using a prototype static analysis tool and code review.

atm/fore200e: Fix possible data race in fore200eopen()

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

spi: tegra210-quad: Protect currxfer check in IRQ handler

Now that all other accesses to currxfer are done under the lock, protect the currxfer NULL check in tegraqspiisrthread() with the spinlock. Without this protection, the following race can occur:

CPU0 (ISR thread) CPU1 (timeout path) ---------------- ------------------- if (!tqspi->currxfer) // sees non-NULL spinlock() tqspi->currxfer = NULL spinunlock() handlexfer() spinlock() t = tqspi->currxfer // NULL! ... t->len ... // NULL dereference!

With this patch, all currxfer accesses are now properly synchronized.

Although all accesses to currxfer are done under the lock, in tegraqspiisrthread() it checks for NULL, releases the lock and reacquires it later in handlecpubasedxfer()/handledmabasedxfer(). There is a potential for an update in between, which could cause a NULL pointer dereference.

To handle this, add a NULL check inside the handlers after acquiring the lock. This ensures that if the timeout path has already cleared currxfer, the handler will safely return without dereferencing the NULL pointer.

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

mm: slub: avoid wake up kswapd in settrackprepare

settrackprepare() can incur lock recursion. The issue is that it is called from hrtimerstartrangens holding the percpu(hrtimerbases)[n].lock, but when enabled CONFIGDEBUGOBJECTSTIMERS, may wake up kswapd in settrackprepare, and try to hold the percpu(hrtimerbases)[n].lock.

Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain GFPKSWAPDRECLAIM in the debugobjectsfillpool() case. Inside stack depot they are processed by gfpnestedmask(). Since slaballoc() has preemption disabled, we mask out GFPDIRECTRECLAIM from the flags there.

The oops looks something like:

BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .ownercpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spinbug+0x0 rawspinlockirqsave+0x80 hrtimertrytocancel+0x94 taskcontending+0x10c enqueuedlentity+0x2a4 dlserverstart+0x74 enqueuetaskfair+0x568 enqueuetask+0xac doactivatetask+0x14c ttwudoactivate+0xcc trytowakeup+0x6c8 defaultwakefunction+0x20 autoremovewakefunction+0x1c wakeup+0xac wakeupkswapd+0x19c wakeallkswapds+0x78 allocpagesslowpath+0x1ac allocpagesnoprof+0x298 stackdepotsaveflags+0x6b0 stackdepotsave+0x14 settrackprepare+0x5c slaballoc+0xccc kmalloccachenoprof+0x470 setpageowner+0x2bc postallochook[jt]+0x1b8 prepnewpage+0x28 getpagefromfreelist+0x1edc allocpagesnoprof+0x13c allocslabpage+0x244 allocateslab+0x7c slaballoc+0x8e8 kmemcacheallocnoprof+0x450 debugobjectsfillpool+0x22c debugobjectactivate+0x40 enqueuehrtimer[jt]+0xdc hrtimerstartrangens+0x5f8 ...

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

can: j1939: implement NETDEVUNREGISTER notification handler

syzbot is reporting

unregisternetdevice: waiting for vcan0 to become free. Usage count = 2

problem, for j1939 protocol did not have NETDEVUNREGISTER notification handler for undoing changes made by j1939skbind().

Commit 25fe97cb7620 ("can: j1939: move j1939privput() into skdestruct callback") expects that a call to j1939privput() can be unconditionally delayed until j1939sksockdestruct() is called. But we need to call j1939privput() against an extra ref held by j1939skbind() call (as a part of undoing changes made by j1939skbind()) as soon as NETDEVUNREGISTER notification fires (i.e. before j1939sksockdestruct() is called via j1939skrelease()). Otherwise, the extra ref on "struct j1939priv" held by j1939skbind() call prevents "struct netdevice" from dropping the usage count to 1; making it impossible for unregisternetdevice() to continue.

[mkl: remove space in front of label]

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

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.