iavf: fix out-of-bounds writes in iavfgetethtoolstats()

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

scsi: mpi3mr: Add NULL checks when resetting request and reply queues

The driver encountered a crash during resource cleanup when the reply and request queues were NULL due to freed memory. This issue occurred when the creation of reply or request queues failed, and the driver freed the memory first, but attempted to mem set the content of the freed memory, leading to a system crash.

Add NULL pointer checks for reply and request queues before accessing the reply/request memory during cleanup

HID: magicmouse: avoid memory leak in magicmousereportfixup()

exit: prevent preemption of oopsing TASKDEAD task

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: 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).

fscache: delete fscachecookielrutimer when fscache exits to avoid UAF

HID: apple: avoid memory leak in applereportfixup()

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

Bluetooth: hcievent: fix potential UAF in hcileremoteconnparamreqevt

hciconn lookup and field access must be covered by hdev lock in hcileremoteconnparamreqevt, otherwise it's possible it is freed concurrently.

Extend the hcidevlock critical section to cover all conn usage.

A remote stack overflow in the TIPC networking module. With FORTIFYSOURCE's stricter memcpy() bounds checking, this can be exploited to cause remote DOS via kernel panic on systems using TIPC. Prior to these bounds checks, and with a canary leak (or no CONFIGSTACKPROTECTOR), this can be exploited for RCE.

Reference: https://www.openwall.com/lists/oss-security/2022/02/10/1

A flaw in the Linux Kernel found. If unprivileged users can mount FUSE filesystems, then can trigger use after free (UAF) that reads of write() buffers, allowing theft of (partial) /etc/shadow hashes or any other data from filesystem.

FUSE allows the userspace filesystem to specify on FUSEOPEN whether the file should use the normal kernel pagecache for handling read()/write() or just send FUSEREAD/FUSEWRITE requests directly to the userspace filesystem (using the flag FOPENDIRECTIO in fuseopenout::openflags).

In FOPENDIRECTIO mode, fusefilewriteiter() calls fusedirectwriteiter(), which normally calls fusedirectio(), which then imports the write buffer with fusegetuserpages(), which uses iovitergetpages() to grab references to userspace pages instead of actually copying memory.

On the filesystem device side, these pages can then either be read to userspace (via fusedevread()), or splice()d over into a pipe using fusedevspliceread() as pipe buffers with &nostealpipebufops.

This is wrong because after fusedevdoread() unlocks the FUSE request, the userspace filesystem can mark the request as completed, causing write() to return. At that point, the write buffer may be reused for other purposes, and the userspace filesystem should no longer have access to it.

An out-of-bounds (OOB) memory read flaw was found in the Qualcomm IPC router protocol in the Linux kernel. A missing sanity check allows a local attacker to gain access to out-of-bounds memory, leading to a system crash or a leak of internal kernel information. The highest threat from this vulnerability is to system availability.

A heap buffer overflow flaw was found in IPsec ESP transformation code in net/ipv4/esp4.c and net/ipv6/esp6.c. This flaw allows a local attacker with a normal user privilege to overwrite kernel heap objects and may cause a local privilege escalation threat.

A flaw was found in the Linux kernel. The PTRACESEIZE code path allows attackers to bypass intended restrictions on setting the PTSUSPENDSECCOMP flag, possibly disabling seccomp.

A use-after-free exists in the Linux Kernel in tcnewtfilter that could allow a local attacker to gain privilege escalation. The exploit requires unprivileged user namespaces. We recommend upgrading past commit 04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5

A NULL pointer dereference flaw was found in the Linux kernel’s Amateur Radio AX.25 protocol functionality in the way a user connects with the protocol. This flaw allows a local user to crash the system.

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

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:

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

scsi: megaraidsas: Fix invalid node index

On a system with DRAM interleave enabled, out-of-bound access is detected:

megaraidsas 0000:3f:00.0: requested/available msix 128/128 pollqueue 0 ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask [1024]' dumpstacklvl+0x5d/0x80 ubsanepilogue+0x5/0x2b ubsanhandleoutofbounds.cold+0x46/0x4b megasasallocirqvectors+0x149/0x190 [megaraidsas] megasasprobeone.cold+0xa4d/0x189c [megaraidsas] localpciprobe+0x42/0x90 pcideviceprobe+0xdc/0x290 reallyprobe+0xdb/0x340 driverprobedevice+0x78/0x110 driverprobedevice+0x1f/0xa0 driverattach+0xba/0x1c0 busforeachdev+0x8b/0xe0 busadddriver+0x142/0x220 driverregister+0x72/0xd0 megasasinit+0xdf/0xff0 [megaraidsas] dooneinitcall+0x57/0x310 doinitmodule+0x90/0x250 initmodulefromfile+0x85/0xc0 idempotentinitmodule+0x114/0x310 x64sysfinitmodule+0x65/0xc0 dosyscall64+0x82/0x170 entrySYSCALL64afterhwframe+0x76/0x7e

Fix it accordingly.

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:

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.

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

wifi: iwlwifi: mei: pass correct argument to function

The first argument to iwlmeiwritecyclicbuf() should be the cldev but the qhead pointer is passed instead. Fix it.

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

KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying

When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN.

For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVMRUN. But if userspace never calls KVMRUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU.

Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nestedvmxfreevcpu() (but for completely unrelated reasons; suppressing WARN from nestedputvmcs12pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless.

The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be any userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically "misses" a push to the dirty ring is irrelevant.

Bluetooth: btmtksdio: fix infinite loop in btmtksdiotxrxwork()

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

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

scsi: mpt3sas: Fix use after free in scsihexpandernoderemove()

The function mpt3sastransportportremove() called in scsihexpandernoderemove() frees the port field of the sasexpander structure, leading to the following use-after-free splat from KASAN when the iocinfo() call following that function is executed (e.g. when doing rmmod of the driver module):

[ 3479.371167] ================================================================== [ 3479.378496] BUG: KASAN: use-after-free in scsihexpandernoderemove+0x710/0x750 [mpt3sas] [ 3479.386936] Read of size 1 at addr ffff8881c037691c by task rmmod/1531 [ 3479.393524] [ 3479.395035] CPU: 18 PID: 1531 Comm: rmmod Not tainted 5.17.0-rc8+ #1436 [ 3479.401712] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.1 06/02/2021 [ 3479.409263] Call Trace: [ 3479.411743] <TASK> [ 3479.413875] dumpstacklvl+0x45/0x59 [ 3479.417582] printaddressdescription.constprop.0+0x1f/0x120 [ 3479.423389] ? scsihexpandernoderemove+0x710/0x750 [mpt3sas] [ 3479.429469] kasanreport.cold+0x83/0xdf [ 3479.433438] ? scsihexpandernoderemove+0x710/0x750 [mpt3sas] [ 3479.439514] scsihexpandernoderemove+0x710/0x750 [mpt3sas] [ 3479.445411] ? rawspinunlockirqrestore+0x2d/0x40 [ 3479.452032] scsihremove+0x525/0xc90 [mpt3sas] [ 3479.458212] ? mpt3sasexpanderremove+0x1d0/0x1d0 [mpt3sas] [ 3479.465529] ? downwrite+0xde/0x150 [ 3479.470746] ? upwrite+0x14d/0x460 [ 3479.475840] ? kernfsfindns+0x137/0x310 [ 3479.481438] pcideviceremove+0x65/0x110 [ 3479.487013] devicereleasedriver+0x316/0x680 [ 3479.493180] driverdetach+0x1ec/0x2d0 [ 3479.498499] busremovedriver+0xe7/0x2d0 [ 3479.504081] pciunregisterdriver+0x26/0x250 [ 3479.510033] mpt3sasexit+0x2b/0x6cf [mpt3sas] [ 3479.516144] x64sysdeletemodule+0x2fd/0x510 [ 3479.522315] ? freemodule+0xaa0/0xaa0 [ 3479.527593] ? condresched+0x1c/0x90 [ 3479.532951] ? lockdephardirqsonprepare+0x273/0x3e0 [ 3479.539607] ? syscallenterfromusermode+0x21/0x70 [ 3479.546161] ? tracehardirqson+0x1c/0x110 [ 3479.551828] dosyscall64+0x35/0x80 [ 3479.556884] entrySYSCALL64afterhwframe+0x44/0xae [ 3479.563402] RIP: 0033:0x7f1fc482483b ... [ 3479.943087] ==================================================================

Fix this by introducing the local variable portid to store the port ID value before executing mpt3sastransportportremove(). This local variable is then used in the call to iocinfo() instead of dereferencing the freed port structure.

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

HID: letsketch: fix UAF on inrangetimer at driver unbind

letsketchdriver does not provide a .remove callback, but letsketchprobe() arms a per-device timer:

timersetup(&data->inrangetimer, letsketchinrangetimeout, 0);

The timer is re-armed from letsketchrawevent() with a 100 ms timeout on every pen-in-range report, and its callback dereferences data->inputtablet to deliver a synthetic BTNTOOLPEN release.

letsketchdata is allocated with devmkzalloc(), and its inputdev fields are devm-allocated via letsketchsetupinputtablet(). On device unbind (USB unplug or rmmod), the HID core runs its default teardown and devm cleanup frees both letsketchdata and the input devices. Because no .remove callback exists, nothing drains the timer first: if rawevent armed it within ~100 ms of the unbind, the pending timer fires on freed memory. This is a UAF read of data and of data->inputtablet, followed by inputreportkey() / inputsync() into the freed inputdev.

The same problem can occur on the probe error path: if hidhwstart() enabled I/O on an always-poll-quirk device and then failed, rawevent may have armed the timer before devm releases data.

Fix by adding a .remove callback that calls hidhwstop() first. hidhwstop() synchronously kills the URBs that deliver rawevent(), so once it returns no path can re-arm the timer. timershutdownsync() then drains any in-flight callback and permanently disables further modtimer() calls. Apply the same timershutdownsync() in the probe error path so the timer is guaranteed not to outlive data.

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

net: ifb: report ethtool stats over numtxqueues

ifbdevinit() allocates dp->txprivate to dev->numtxqueues entries via kzallocobjs(txp, dev->numtxqueues). Both IFB per-queue RX and TX stats live in those entries: ifbxmit() updates txp->rxstats using the skb queue mapping, ifbritasklet() updates txp->txstats, and ifbstats64() aggregates both over dev->numtxqueues.

The ethtool stats callbacks instead size and walk the per-queue stats with dev->realnumrxqueues and dev->realnumtxqueues. With an asymmetric device where the RX queue count exceeds the TX queue count, for example:

ip link add name ifb10 numtxqueues 1 numrxqueues 8 type ifb ethtool -S ifb10

ifbgetethtoolstats() indexes past the txprivate allocation and copies adjacent slab data through ETHTOOLGSTATS.

Use dev->numtxqueues consistently for the stats strings, the stats count, and the stats data walks. This reports one RX stats group and one TX stats group for each backing ifbqprivate entry, which is the queue set IFB can actually populate.

Reproduced under UML+KASAN at v7.1-rc2:

BUG: KASAN: slab-out-of-bounds in ifbfillstatsdata+0x3c/0xae Read of size 8 at addr 0000000062dbd228 by task ethtool/36 ifbfillstatsdata+0x3c/0xae ifbgetethtoolstats+0xc0/0x129 devethtool+0x1ca5/0x363c devethtool+0x123/0x1b3 devioctl+0x56c/0x744 sockdoioctl+0x15f/0x1b2 sockioctl+0x4d5/0x50a sysioctl+0xd8b/0xde9

With the patch applied, the same UML+KASAN repro is silent and ethtool -S ifb10 reports only the stats backed by the single allocated txprivate entry.

erofs: fix metabuf leak in inode xattr initialization