erofs: fix metabuf leak in inode xattr initialization

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

net: dsa: improve shutdown sequence

Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there.

The first problem is that lan9303 is unique among DSA drivers in that it calls devgetdrvdata() at "arbitrary runtime" (not probe, not shutdown, not remove):

phystatemachine() -> ... -> dsauserphyread() -> ds->ops->phyread() -> lan9303phyread() -> chip->ops->phyread() -> lan9303mdiophyread() -> devgetdrvdata()

But we never stop the phystatemachine(), so it may continue to run after dsaswitchshutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD.

The second problem is that the way in which we set dp->conduit->dsaptr = NULL; is concurrent with receive packet processing. dsaswitchrcv() checks once whether dev->dsaptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsaptr is dereferenced again and again without NULL checks: dsaconduitfinduser() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid.

Both problems have the common aspect that closing the conduit interface solves them.

In the first case, devclose(conduit) triggers the NETDEVGOINGDOWN event in dsausernetdeviceevent() which closes user ports as well. dsaportdisablert() calls phylinkstop(), which synchronously stops the phylink state machine, and ds->ops->phyread() will thus no longer call into the driver after this point.

In the second case, devclose(conduit) should do this, as per Documentation/networking/driver.rst:

| Quiescence | ---------- | | After the ndostop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands.

So it should be sufficient to ensure that later, when we zeroize conduit->dsaptr, there will be no concurrent dsaswitchrcv() call on this conduit.

The addition of the netifdevicedetach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them.

The race condition actually did not exist when commit 0650bf52b31f ("net: dsa: be compatible with masters which unregister on shutdown") first introduced dsaswitchshutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsaptr (one which doesn't ensure that the interfaces aren't up).

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

x86/fpu: Clear XSTATEBV[i] in guest XSAVE state whenever XFD[i]=1

When loading guest XSAVE state via KVMSETXSAVE, and when updating XFD in response to a guest WRMSR, clear XFD-disabled features in the saved (or to be restored) XSTATEBV to ensure KVM doesn't attempt to load state for features that are disabled via the guest's XFD. Because the kernel executes XRSTOR with the guest's XFD, saving XSTATEBV[i]=1 with XFD[i]=1 will cause XRSTOR to #NM and panic the kernel.

E.g. if fpuupdateguestxfd() sets XFD without clearing XSTATEBV:

------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at excdevicenotavailable+0x101/0x110, CPU#29: amxtest/848 Modules linked in: kvmintel kvm irqbypass CPU: 29 UID: 1000 PID: 848 Comm: amxtest Not tainted 6.19.0-rc2-ffa07f7fd437-x86amxnmxfdnoninit-vm #171 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:excdevicenotavailable+0x101/0x110 Call Trace: <TASK> asmexcdevicenotavailable+0x1a/0x20 RIP: 0010:restorefpregsfromfpstate+0x36/0x90 switchfpureturn+0x4a/0xb0 kvmarchvcpuioctlrun+0x1245/0x1e40 [kvm] kvmvcpuioctl+0x2c3/0x8f0 [kvm] x64sysioctl+0x8f/0xd0 dosyscall64+0x62/0x940 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]---

This can happen if the guest executes WRMSR(MSRIA32XFD) to set XFD[18] = 1, and a host IRQ triggers kernelfpubegin() prior to the vmexit handler's call to fpuupdateguestxfd().

and if userspace stuffs XSTATEBV[i]=1 via KVMSETXSAVE:

------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at excdevicenotavailable+0x101/0x110, CPU#14: amxtest/867 Modules linked in: kvmintel kvm irqbypass CPU: 14 UID: 1000 PID: 867 Comm: amxtest Not tainted 6.19.0-rc2-2dace9faccd6-x86amxnmxfdnoninit-vm #168 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:excdevicenotavailable+0x101/0x110 Call Trace: <TASK> asmexcdevicenotavailable+0x1a/0x20 RIP: 0010:restorefpregsfromfpstate+0x36/0x90 fpuswapkvmfpstate+0x6b/0x120 kvmloadguestfpu+0x30/0x80 [kvm] kvmarchvcpuioctlrun+0x85/0x1e40 [kvm] kvmvcpuioctl+0x2c3/0x8f0 [kvm] x64sysioctl+0x8f/0xd0 dosyscall64+0x62/0x940 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]---

The new behavior is consistent with the AMX architecture. Per Intel's SDM, XSAVE saves XSTATEBV as '0' for components that are disabled via XFD (and non-compacted XSAVE saves the initial configuration of the state component):

If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i, the instruction does not generate #NM when XCR0[i] = IA32XFD[i] = 1; instead, it operates as if XINUSE[i] = 0 (and the state component was in its initial state): it saves bit i of XSTATEBV field of the XSAVE header as 0; in addition, XSAVE saves the initial configuration of the state component (the other instructions do not save state component i).

Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by using a constant XFD based on the set of enabled features when XSAVEing for a struct fpuguest. However, having XSTATEBV[i]=1 for XFD-disabled features can only happen in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, because fpuswapkvmfpstate()'s call to savefpregstofpstate() saves the outgoing FPU state with the current XFD; and that is (on all but the first WRMSR to XFD) the guest XFD.

Therefore, XFD can only go out of sync with XSTATEBV in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, and it we can consider it (de facto) part of KVM ABI that KVMGETXSAVE returns XSTATEBV[i]=0 for XFD-disabled features.

[Move clea ---truncated---

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

net: qrtr: Drop the MHI autoqueue feature for IPCR DL channels

MHI stack offers the 'autoqueue' feature, which allows the MHI stack to auto queue the buffers for the RX path (DL channel). Though this feature simplifies the client driver design, it introduces race between the client drivers and the MHI stack. For instance, with autoqueue, the 'dlcallback' for the DL channel may get called before the client driver is fully probed. This means, by the time the dlcallback gets called, the client driver's structures might not be initialized, leading to NULL ptr dereference.

Currently, the drivers have to workaround this issue by initializing the internal structures before calling mhipreparefortransferautoqueue(). But even so, there is a chance that the client driver's internal code path may call the MHI queue APIs before mhipreparefortransferautoqueue() is called, leading to similar NULL ptr dereference. This issue has been reported on the Qcom X1E80100 CRD machines affecting boot.

So to properly fix all these races, drop the MHI 'autoqueue' feature altogether and let the client driver (QRTR) manage the RX buffers manually. In the QRTR driver, queue the RX buffers based on the ring length during probe and recycle the buffers in 'dlcallback' once they are consumed. This also warrants removing the setting of 'autoqueue' flag from controller drivers.

Currently, this 'autoqueue' feature is only enabled for IPCR DL channel. So only the QRTR client driver requires the modification.

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

drm/mediatek: Fix potential NULL dereference in mtkcrtcdestroy()

In mtkcrtccreate(), if the call to mboxrequestchannel() fails then we set the "mtkcrtc->cmdqclient.chan" pointer to NULL. In that situation, we do not call cmdqpktcreate().

During the cleanup, we need to check if the "mtkcrtc->cmdqclient.chan" is NULL first before calling cmdqpktdestroy(). Calling cmdqpktdestroy() is unnecessary if we didn't call cmdqpktcreate() and it will result in a NULL pointer dereference.

HID: magicmouse: avoid memory leak in magicmousereportfixup()

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

mm/hugememory: avoid PMD-size page cache if needed

xarray can't support arbitrary page cache size. the largest and supported page cache size is defined as MAXPAGECACHEORDER by commit 099d90642a71 ("mm/filemap: make MAXPAGECACHEORDER acceptable to xarray"). However, it's possible to have 512MB page cache in the huge memory's collapsing path on ARM64 system whose base page size is 64KB. 512MB page cache is breaking the limitation and a warning is raised when the xarray entry is split as shown in the following example.

[root@dhcp-10-26-1-207 ~]# cat /proc/1/smaps | grep KernelPageSize KernelPageSize: 64 kB [root@dhcp-10-26-1-207 ~]# cat /tmp/test.c : int main(int argc, char argv) { const char filename = TESTXFSFILENAME; int fd = 0; void buf = (void )-1, p; int pgsize = getpagesize(); int ret = 0;

if (pgsize != 0x10000) { fprintf(stdout, "System with 64KB base page size is required!\n"); return -EPERM; }

system("echo 0 > /sys/devices/virtual/bdi/253:0/readaheadkb"); system("echo 1 > /proc/sys/vm/dropcaches");

/ Open the xfs file / fd = open(filename, ORDONLY); assert(fd > 0);

/ Create VMA / buf = mmap(NULL, TESTMEMSIZE, PROTREAD, MAPSHARED, fd, 0); assert(buf != (void )-1); fprintf(stdout, "mapped buffer at 0x%p\n", buf);

/ Populate VMA / ret = madvise(buf, TESTMEMSIZE, MADVNOHUGEPAGE); assert(ret == 0); ret = madvise(buf, TESTMEMSIZE, MADVPOPULATEREAD); assert(ret == 0);

/ Collapse VMA / ret = madvise(buf, TESTMEMSIZE, MADVHUGEPAGE); assert(ret == 0); ret = madvise(buf, TESTMEMSIZE, MADVCOLLAPSE); if (ret) { fprintf(stdout, "Error %d to madvise(MADVCOLLAPSE)\n", errno); goto out; }

/ Split xarray entry. Write permission is needed / munmap(buf, TESTMEMSIZE); buf = (void )-1; close(fd); fd = open(filename, ORDWR); assert(fd > 0); fallocate(fd, FALLOCFLKEEPSIZE | FALLOCFLPUNCHHOLE, TESTMEMSIZE - pgsize, pgsize); out: if (buf != (void )-1) munmap(buf, TESTMEMSIZE); if (fd > 0) close(fd);

return ret; }

[root@dhcp-10-26-1-207 ~]# gcc /tmp/test.c -o /tmp/test [root@dhcp-10-26-1-207 ~]# /tmp/test ------------[ cut here ]------------ WARNING: CPU: 25 PID: 7560 at lib/xarray.c:1025 xassplitalloc+0xf8/0x128 Modules linked in: nftfibinet nftfibipv4 nftfibipv6 nftfib \ nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct \ nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 \ ipset rfkill nftables nfnetlink vfat fat virtioballoon drm fuse \ xfs libcrc32c crct10difce ghashce sha2ce sha256arm64 virtionet \ sha1ce netfailover virtioblk virtioconsole failover dimlib virtiommio CPU: 25 PID: 7560 Comm: test Kdump: loaded Not tainted 6.10.0-rc7-gavin+ #9 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : xassplitalloc+0xf8/0x128 lr : splithugepagetolisttoorder+0x1c4/0x780 sp : ffff8000ac32f660 x29: ffff8000ac32f660 x28: ffff0000e0969eb0 x27: ffff8000ac32f6c0 x26: 0000000000000c40 x25: ffff0000e0969eb0 x24: 000000000000000d x23: ffff8000ac32f6c0 x22: ffffffdfc0700000 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffdfc0700000 x18: 0000000000000000 x17: 0000000000000000 x16: ffffd5f3708ffc70 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: ffffffffffffffc0 x10: 0000000000000040 x9 : ffffd5f3708e692c x8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff0000e0969eb8 x5 : ffffd5f37289e378 x4 : 0000000000000000 x3 : 0000000000000c40 x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000 Call trace: xassplitalloc+0xf8/0x128 splithugepagetolisttoorder+0x1c4/0x780 truncateinodepartialfolio+0xdc/0x160 truncateinodepagesrange+0x1b4/0x4a8 truncatepagecacherange+0x84/0xa ---truncated---

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

md/raid10: wait barrier before returning discard request with REQNOWAIT

raid10handlediscard should wait barrier before returning a discard bio which has REQNOWAIT. And there is no need to print warning calltrace if a discard bio has REQNOWAIT flag. Quality engineer usually checks dmesg and reports error if dmesg has warning/error calltrace.

Bluetooth: btmtksdio: fix infinite loop in btmtksdiotxrxwork()

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

media: staging: media: zoran: move videodev alloc

Move some code out of zr36057init() and create new functions for handling zr->videodev. This permit to ease code reading and fix a zr->videodev memory leak.

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

x86/mce: use iscopyfromuser() to determine copy-from-user context

Patch series "mm/hwpoison: Fix regressions in memory failure handling", v4.

1. What am I trying to do:

This patchset resolves two critical regressions related to memory failure handling that have appeared in the upstream kernel since version 5.17, as compared to 5.10 LTS.

- copyin case: poison found in user page while kernel copying from user space - instr case: poison found while instruction fetching in user space

2. What is the expected outcome and why

- For copyin case:

Kernel can recover from poison found where kernel is doing getuser() or copyfromuser() if those places get an error return and the kernel return -EFAULT to the process instead of crashing. More specifily, MCE handler checks the fixup handler type to decide whether an in kernel #MC can be recovered. When EXTYPEUACCESS is found, the PC jumps to recovery code specified in ASMEXTABLEFAULT() and return a -EFAULT to user space.

- For instr case:

If a poison found while instruction fetching in user space, full recovery is possible. User process takes #PF, Linux allocates a new page and fills by reading from storage.

3. What actually happens and why

- For copyin case: kernel panic since v5.17

Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new extable fixup type, EXTYPEEFAULTREG, and later patches updated the extable fixup type for copy-from-user operations, changing it from EXTYPEUACCESS to EXTYPEEFAULTREG. It breaks previous EXTYPEUACCESS handling when posion found in getuser() or copyfromuser().

- For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE race

When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed.

Background: why UNcorrected errors tied to CMCI in Intel platform [1]

Prior to Icelake memory controllers reported patrol scrub events that detected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an SRAO (Software Recoverable Action Optional) signature in the machine check bank. This was overkill because it's not an urgent problem that no core is on the verge of consuming that bad data. It's also found that multi SRAO UCE may cause nested MCE interrupts and finally become an IERR.

Hence, Intel downgrades the machine check bank signature of patrol scrub from SRAO to UCNA (Uncorrected, No Action required), and signal changed to #CMCI. Just to add to the confusion, Linux does take an action (in ucdecodenotifier()) to try to offline the page despite the UCNA signature name.

Background: why #CMCI and #MCE race when poison is consuming in Intel platform [1]

Having decided that CMCI/UCNA is the best action for patrol scrub errors, the memory controller uses it for reads too. But the memory controller is executing asynchronously from the core, and can't tell the difference between a "real" read and a speculative read. So it will do CMCI/UCNA if an error is found in any read.

Thus:

1) Core is clever and thinks address A is needed soon, issues a speculative read.

2) Core finds it is going to use address A soon after sending the read request

3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A.

Quite often (because speculation has got better) the CMCI from the memory controller is delivered before the core is committed to the instruction reading address A, so the interrupt is taken, and Linux offlines the page (marking it as poison).

Why user process is killed for instr case

Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported "not ---truncated---

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

module: decompress: check return value of moduleextendmaxpages()

moduleextendmaxpages() calls kvrealloc() internally and returns -ENOMEM on allocation failure. The return value is never checked.

If the initial allocation fails, info->pages remains NULL and info->maxpages remains 0. Subsequent calls to modulegetnextpage() will attempt to dynamically grow the array by calling moduleextendmaxpages(info, 0) since info->usedpages is 0. This results in kvrealloc(NULL, 0) returning ZEROSIZEPTR, which is treated as a success, leading to a dereference of ZEROSIZEPTR and a kernel oops.

Fix: add the missing error check after moduleextendmaxpages() and return immediately on failure. This matches the pattern used by every other kvrealloc() caller in the module loading path.

[Sami: Corrected the analysis in the commit message.]

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

nfsd: reset write verifier on deferred writeback errors

nfsdvfswrite() and nfsdcommit() both call filemapcheckwberr() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commitresetwriteverifier() before returning an error.

The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32).

Add commitresetwriteverifier() calls at both filemapcheckwberr() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.

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

vlan: fix memory leak in vlannewlink()

Blamed commit added back a bug I fixed in commit 9bbd917e0bec ("vlan: fix memory leak in vlandevsetegresspriority")

If a memory allocation fails in vlanchangelink() after other allocations succeeded, we need to call vlandevfreeegresspriority() to free all allocated memory because after a failed ->newlink() we do not call any methods like ndouninit() or dev->privdestructor().

In following example, if the allocation for last element 2000:2001 fails, we need to free eight prior allocations:

ip link add link dummy0 dummy0.100 type vlan id 100 \ egress-qos-map 1:2 2:3 3:4 4:5 5:6 6:7 7:8 8:9 2000:2001

syzbot report was:

BUG: memory leak unreferenced object 0xffff888117bd1060 (size 32): comm "syz-executor408", pid 3759, jiffies 4294956555 (age 34.090s) hex dump (first 32 bytes): 09 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff83fc60ad>] kmalloc include/linux/slab.h:600 [inline] [<ffffffff83fc60ad>] vlandevsetegresspriority+0xed/0x170 net/8021q/vlandev.c:193 [<ffffffff83fc6628>] vlanchangelink+0x178/0x1d0 net/8021q/vlannetlink.c:128 [<ffffffff83fc67c8>] vlannewlink+0x148/0x260 net/8021q/vlannetlink.c:185 [<ffffffff838b1278>] rtnlnewlinkcreate net/core/rtnetlink.c:3363 [inline] [<ffffffff838b1278>] rtnlnewlink+0xa58/0xdc0 net/core/rtnetlink.c:3580 [<ffffffff838b1629>] rtnlnewlink+0x49/0x70 net/core/rtnetlink.c:3593 [<ffffffff838ac66c>] rtnetlinkrcvmsg+0x21c/0x5c0 net/core/rtnetlink.c:6089 [<ffffffff839f9c37>] netlinkrcvskb+0x87/0x1d0 net/netlink/afnetlink.c:2501 [<ffffffff839f8da7>] netlinkunicastkernel net/netlink/afnetlink.c:1319 [inline] [<ffffffff839f8da7>] netlinkunicast+0x397/0x4c0 net/netlink/afnetlink.c:1345 [<ffffffff839f9266>] netlinksendmsg+0x396/0x710 net/netlink/afnetlink.c:1921 [<ffffffff8384dbf6>] socksendmsgnosec net/socket.c:714 [inline] [<ffffffff8384dbf6>] socksendmsg+0x56/0x80 net/socket.c:734 [<ffffffff8384e15c>] syssendmsg+0x36c/0x390 net/socket.c:2488 [<ffffffff838523cb>] syssendmsg+0x8b/0xd0 net/socket.c:2542 [<ffffffff838525b8>] syssendmsg net/socket.c:2571 [inline] [<ffffffff838525b8>] dosyssendmsg net/socket.c:2580 [inline] [<ffffffff838525b8>] sesyssendmsg net/socket.c:2578 [inline] [<ffffffff838525b8>] x64syssendmsg+0x78/0xf0 net/socket.c:2578 [<ffffffff845ad8d5>] dosyscallx64 arch/x86/entry/common.c:50 [inline] [<ffffffff845ad8d5>] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff8460006a>] entrySYSCALL64afterhwframe+0x46/0xb0

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

tpm: use trygetops() in tpm-space.c

As part of the series conversion to remove nested TPM operations:

https://lore.kernel.org/all/20190205224723.19671-1-jarkko.sakkinen@linux.intel.com/

exposure of the chip->tpmmutex was removed from much of the upper level code. In this conversion, tpm2delspace() was missed. This didn't matter much because it's usually called closely after a converted operation, so there's only a very tiny race window where the chip can be removed before the space flushing is done which causes a NULL deref on the mutex. However, there are reports of this window being hit in practice, so fix this by converting tpm2delspace() to use tpmtrygetops(), which performs all the teardown checks before acquring the mutex.

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

drm/amd/display: Fix memory leak

[why] Resource release is needed on the error handling path to prevent memory leak.

[how] Fix this by adding kfree on the error handling path.

drm/amdkfd: svm range restore work deadlock when process exit

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

ath11k: pci: fix crash on suspend if board file is not found

Mario reported that the kernel was crashing on suspend if ath11k was not able to find a board file:

[ 473.693286] PM: Suspending system (s2idle) [ 473.693291] printk: Suspending console(s) (use noconsolesuspend to debug) [ 474.407787] BUG: unable to handle page fault for address: 0000000000002070 [ 474.407791] #PF: supervisor read access in kernel mode [ 474.407794] #PF: errorcode(0x0000) - not-present page [ 474.407798] PGD 0 P4D 0 [ 474.407801] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 474.407805] CPU: 2 PID: 2350 Comm: kworker/u32:14 Tainted: G W 5.16.0 #248 [...] [ 474.407868] Call Trace: [ 474.407870] <TASK> [ 474.407874] ? rawspinlockirqsave+0x2a/0x60 [ 474.407882] ? locktimerbase+0x72/0xa0 [ 474.407889] ? rawspinunlockirqrestore+0x29/0x3d [ 474.407892] ? trytodeltimersync+0x54/0x80 [ 474.407896] ath11kdprxpktlogstop+0x49/0xc0 [ath11k] [ 474.407912] ath11kcoresuspend+0x34/0x130 [ath11k] [ 474.407923] ath11kpcipmsuspend+0x1b/0x50 [ath11kpci] [ 474.407928] pcipmsuspend+0x7e/0x170 [ 474.407935] ? pcipmfreeze+0xc0/0xc0 [ 474.407939] dpmruncallback+0x4e/0x150 [ 474.407947] devicesuspend+0x148/0x4c0 [ 474.407951] asyncsuspend+0x20/0x90 dmesg-efi-164255130401001: Oops#1 Part1 [ 474.407955] asyncrunentryfn+0x33/0x120 [ 474.407959] processonework+0x220/0x3f0 [ 474.407966] workerthread+0x4a/0x3d0 [ 474.407971] kthread+0x17a/0x1a0 [ 474.407975] ? processonework+0x3f0/0x3f0 [ 474.407979] ? setkthreadstruct+0x40/0x40 [ 474.407983] retfromfork+0x22/0x30 [ 474.407991] </TASK>

The issue here is that board file loading happens after ath11kpciprobe() succesfully returns (ath11k initialisation happends asynchronously) and the suspend handler is still enabled, of course failing as ath11k is not properly initialised. Fix this by checking ATH11KFLAGQMIFAIL during both suspend and resume.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPLV1V2SILICONZLITE-2

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

drm/amd/amdgpu/amdgpucs: fix refcount leak of a dmafence obj

This issue takes place in an error path in amdgpucsfencetohandleioctl(). When info->in.what falls into default case, the function simply returns -EINVAL, forgetting to decrement the reference count of a dmafence obj, which is bumped earlier by amdgpucsgetfence(). This may result in reference count leaks.

Fix it by decreasing the refcount of specific object before returning the error code.

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

f2fs: use spinlock to avoid hang

[14696.634553] task:cat state:D stack: 0 pid:1613738 ppid:1613735 flags:0x00000004 [14696.638285] Call Trace: [14696.639038] <TASK> [14696.640032] schedule+0x302/0x930 [14696.640969] schedule+0x58/0xd0 [14696.641799] schedulepreemptdisabled+0x18/0x30 [14696.642890] mutexlock.constprop.0+0x2fb/0x4f0 [14696.644035] ? modobjcgstate+0x10c/0x310 [14696.645040] ? objcgroupcharge+0xe1/0x170 [14696.646067] mutexlockslowpath+0x13/0x20 [14696.647126] mutexlock+0x34/0x40 [14696.648070] statshow+0x25/0x17c0 [f2fs] [14696.649218] seqreaditer+0x120/0x4b0 [14696.650289] ? aafileperm+0x12a/0x500 [14696.651357] ? lrucacheadd+0x1c/0x20 [14696.652470] seqread+0xfd/0x140 [14696.653445] fullproxyread+0x5c/0x80 [14696.654535] vfsread+0xa0/0x1a0 [14696.655497] ksysread+0x67/0xe0 [14696.656502] x64sysread+0x1a/0x20 [14696.657580] dosyscall64+0x3b/0xc0 [14696.658671] entrySYSCALL64afterhwframe+0x44/0xae [14696.660068] RIP: 0033:0x7efe39df1cb2 [14696.661133] RSP: 002b:00007ffc8badd948 EFLAGS: 00000246 ORIGRAX: 0000000000000000 [14696.662958] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007efe39df1cb2 [14696.664757] RDX: 0000000000020000 RSI: 00007efe399df000 RDI: 0000000000000003 [14696.666542] RBP: 00007efe399df000 R08: 00007efe399de010 R09: 00007efe399de010 [14696.668363] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000000000 [14696.670155] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 [14696.671965] </TASK> [14696.672826] task:umount state:D stack: 0 pid:1614985 ppid:1614984 flags:0x00004000 [14696.674930] Call Trace: [14696.675903] <TASK> [14696.676780] schedule+0x302/0x930 [14696.677927] schedule+0x58/0xd0 [14696.679019] schedulepreemptdisabled+0x18/0x30 [14696.680412] mutexlock.constprop.0+0x2fb/0x4f0 [14696.681783] ? destroyinode+0x65/0x80 [14696.683006] mutexlockslowpath+0x13/0x20 [14696.684305] mutexlock+0x34/0x40 [14696.685442] f2fsdestroystats+0x1e/0x60 [f2fs] [14696.686803] f2fsputsuper+0x158/0x390 [f2fs] [14696.688238] genericshutdownsuper+0x7a/0x120 [14696.689621] killblocksuper+0x27/0x50 [14696.690894] killf2fssuper+0x7f/0x100 [f2fs] [14696.692311] deactivatelockedsuper+0x35/0xa0 [14696.693698] deactivatesuper+0x40/0x50 [14696.694985] cleanupmnt+0x139/0x190 [14696.696209] cleanupmnt+0x12/0x20 [14696.697390] taskworkrun+0x64/0xa0 [14696.698587] exittousermodeprepare+0x1b7/0x1c0 [14696.700053] syscallexittousermode+0x27/0x50 [14696.701418] dosyscall64+0x48/0xc0 [14696.702630] entrySYSCALL64afterhwframe+0x44/0xae

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

scsi: hisisas: Free irq vectors in order for v3 HW

If the driver probe fails to request the channel IRQ or fatal IRQ, the driver will free the IRQ vectors before freeing the IRQs in freeirq(), and this will cause a kernel BUG like this:

------------[ cut here ]------------ kernel BUG at drivers/pci/msi.c:369! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Call trace: freemsiirqs+0x118/0x13c pcidisablemsi+0xfc/0x120 pcifreeirqvectors+0x24/0x3c hisisasv3probe+0x360/0x9d0 [hisisasv3hw] localpciprobe+0x44/0xb0 workforcpufn+0x20/0x34 processonework+0x1d0/0x340 workerthread+0x2e0/0x460 kthread+0x180/0x190 retfromfork+0x10/0x20 ---[ end trace b88990335b610c11 ]---

So we use devmaddaction() to control the order in which we free the vectors.

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

scsi: mpi3mr: Fix memory leaks

Fix memory leaks related to operational reply queue's memory segments which are not getting freed while unloading the driver.

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

ath11k: mhi: use mhisyncpowerup()

If amss.bin was missing ath11k would crash during 'rmmod ath11kpci'. The reason for that was that we were using mhiasyncpowerup() which does not check any errors. But mhisyncpowerup() on the other hand does check for errors so let's use that to fix the crash.

I was not able to find a reason why an async version was used. ath11kmhistart() (which enables state ATH11KMHIPOWERON) is called from ath11khifpowerup(), which can sleep. So sync version should be safe to use here.

[ 145.569731] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP DEBUGPAGEALLOC KASAN PTI [ 145.569789] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 145.569843] CPU: 2 PID: 1628 Comm: rmmod Kdump: loaded Tainted: G W 5.16.0-wt-ath+ #567 [ 145.569898] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 [ 145.569956] RIP: 0010:ath11khalsrngaccessbegin+0xb5/0x2b0 [ath11k] [ 145.570028] Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 ec 01 00 00 48 8b ab a8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea 03 <0f> b6 14 02 48 89 e8 83 e0 07 83 c0 03 45 85 ed 75 48 38 d0 7c 08 [ 145.570089] RSP: 0018:ffffc900025d7ac0 EFLAGS: 00010246 [ 145.570144] RAX: dffffc0000000000 RBX: ffff88814fca2dd8 RCX: 1ffffffff50cb455 [ 145.570196] RDX: 0000000000000000 RSI: ffff88814fca2dd8 RDI: ffff88814fca2e80 [ 145.570252] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffa8659497 [ 145.570329] R10: fffffbfff50cb292 R11: 0000000000000001 R12: ffff88814fca0000 [ 145.570410] R13: 0000000000000000 R14: ffff88814fca2798 R15: ffff88814fca2dd8 [ 145.570465] FS: 00007fa399988540(0000) GS:ffff888233e00000(0000) knlGS:0000000000000000 [ 145.570519] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 145.570571] CR2: 00007fa399b51421 CR3: 0000000137898002 CR4: 00000000003706e0 [ 145.570623] Call Trace: [ 145.570675] <TASK> [ 145.570727] ? ath11kcetxprocesscb+0x34b/0x860 [ath11k] [ 145.570797] ath11kcetxprocesscb+0x356/0x860 [ath11k] [ 145.570864] ? taskletinit+0x150/0x150 [ 145.570919] ? ath11kceallocpipes+0x280/0x280 [ath11k] [ 145.570986] ? taskletclearsched+0x42/0xe0 [ 145.571042] ? taskletkill+0xe9/0x1b0 [ 145.571095] ? taskletclearsched+0xe0/0xe0 [ 145.571148] ? irqhasaction+0x120/0x120 [ 145.571202] ath11kcecleanuppipes+0x45a/0x580 [ath11k] [ 145.571270] ? ath11kpcistop+0x10e/0x170 [ath11kpci] [ 145.571345] ath11kcorestop+0x8a/0xc0 [ath11k] [ 145.571434] ath11kcoredeinit+0x9e/0x150 [ath11k] [ 145.571499] ath11kpciremove+0xd2/0x260 [ath11kpci] [ 145.571553] pcideviceremove+0x9a/0x1c0 [ 145.571605] devicereleasedriver+0x332/0x660 [ 145.571659] driverdetach+0x1e7/0x2c0 [ 145.571712] busremovedriver+0xe2/0x2d0 [ 145.571772] pciunregisterdriver+0x21/0x250 [ 145.571826] dosysdeletemodule+0x30a/0x4b0 [ 145.571879] ? freemodule+0xac0/0xac0 [ 145.571933] ? lockdephardirqsonprepare.part.0+0x18c/0x370 [ 145.571986] ? syscallenterfromusermode+0x1d/0x50 [ 145.572039] ? lockdephardirqson+0x79/0x100 [ 145.572097] dosyscall64+0x3b/0x90 [ 145.572153] entrySYSCALL64afterhwframe+0x44/0xae

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPLV1V2SILICONZLITE-2

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

mt76: fix monitor mode crash with sdio driver

mt7921s driver may receive frames with fragment buffers. If there is a CTS packet received in monitor mode, the payload is 10 bytes only and need 6 bytes header padding after RXD buffer. However, only RXD in the first linear buffer, if we pull buffer size RXD-size+6 bytes with skbpull(), that would trigger "BUGON(skb->len < skb->datalen)" in skbpull().

To avoid the nonlinear buffer issue, enlarge the RXD size from 128 to 256 to make sure all MCU operation in linear buffer.

[ 52.007562] kernel BUG at include/linux/skbuff.h:2313! [ 52.007578] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 52.007987] pc : skbpull+0x48/0x4c [ 52.008015] lr : mt7921queuerxskb+0x494/0x890 [mt7921common] [ 52.008361] Call trace: [ 52.008377] skbpull+0x48/0x4c [ 52.008400] mt76snetworker+0x134/0x1b0 [mt76sdio 35339a92c6eb7d4bbcc806a1d22f56365565135c] [ 52.008431] mt76workerfn+0xe8/0x170 [mt76 ef716597d11a77150bc07e3fdd68eeb0f9b56917] [ 52.008449] kthread+0x148/0x3ac [ 52.008466] retfromfork+0x10/0x30

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

ceph: fix inode reference leakage in cephgetsnapdir()

The cephgetinode() will search for or insert a new inode into the hash for the given vino, and return a reference to it. If new is non-NULL, its reference is consumed.

We should release the reference when in error handing cases.

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

staging: vchiqcore: handle NULL result of findservicebyhandle

In case of an invalid handle the function findservivebyhandle returns NULL. So take care of this and avoid a NULL pointer dereference.

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

habanalabs: fix possible memory leak in MMU DR fini

This patch fixes what seems to be copy paste error.

We will have a memory leak if the host-resident shadow is NULL (which will likely happen as the DR and HR are not dependent).

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

ceph: fix memory leak in cephreaddir when notelastdentry returns error

Reset the lastreaddir at the same time, and add a comment explaining why we don't free lastreaddir when diremit returns false.

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

staging: wfx: fix an error handling in wfxinitcommon()

One error handler of wfxinitcommon() return without calling ieee80211freehw(hw), which may result in memory leak. And I add one err label to unify the error handler, which is useful for the subsequent changes.

drm/amd/display: Fix by adding FPU protection for dcn30internalvalidatebw