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
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.
Bluetooth: btmtksdio: fix infinite loop in btmtksdiotxrxwork()
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 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.
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.
A random memory access flaw was found in the Linux kernel's GPU i915 kernel driver functionality in the way a user may run malicious code on the GPU. This flaw allows a local user to crash the system or escalate their privileges on the system.
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:
net: bonding: fix use-after-free in bondxmitbroadcast()
bondxmitbroadcast() reuses the original skb for the last slave (determined by bondislastslave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is "last" mid-loop. This causes the original skb to be double-consumed (double-freed).
Replace the racy bondislastslave() check with a simple index comparison (i + 1 == slavescount) against the pre-snapshot slave count taken via READONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the "last" determination stable against concurrent list mutations.
The UAF can trigger the following crash:
================================================================== BUG: KASAN: slab-use-after-free in skbclone Read of size 8 at addr ffff888100ef8d40 by task exploit/147
CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:123) printreport (mm/kasan/report.c:379 mm/kasan/report.c:482) kasanreport (mm/kasan/report.c:597) skbclone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bondxmitbroadcast (drivers/net/bonding/bondmain.c:5334) bondstartxmit (drivers/net/bonding/bondmain.c:5567 drivers/net/bonding/bondmain.c:5593) devhardstartxmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) devqueuexmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6finishoutput2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6output.c:136) ip6finishoutput (net/ipv6/ip6output.c:208 net/ipv6/ip6output.c:219) ip6output (net/ipv6/ip6output.c:250) ip6sendskb (net/ipv6/ip6output.c:1985) udpv6sendskb (net/ipv6/udp.c:1442) udpv6sendmsg (net/ipv6/udp.c:1733) syssendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) x64syssendto (net/socket.c:2209) dosyscall64 (arch/x86/entry/syscall64.c:63 arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) </TASK>
Allocated by task 147:
Freed by task 147:
The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuffheadcache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60)
Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================
In the Linux kernel, the following vulnerability has been resolved:
erofs: fix metabuf leak in inode xattr initialization
commit bb88e8da0025 ("erofs: use meta buffers for xattr operations") converted xattr operations to use on-stack erofsbuf instances. erofsinitinodexattrs() uses such a metabuf while reading the inline xattr header and shared xattr id array.
Some error paths after erofsreadmetabuf() leave through outunlock without dropping the metabuf, so the folio reference can leak.
Consolidate the cleanup at outunlock. erofsputmetabuf() is a no-op if no folio has been acquired, and this keeps all paths after taking EROFSIBLXATTRBIT covered by a single cleanup site.
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 before 5.17.3, fs/iouring.c has a use-after-free due to a race condition in iouring timeouts. This can be triggered by a local user who has no access to any user namespace; however, the race condition perhaps can only be exploited infrequently.
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
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.
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:
bfq: fix use-after-free in bfqdispatchrequest
KASAN reports a use-after-free report when doing normal scsi-mq test
[69832.239032] ================================================================== [69832.241810] BUG: KASAN: use-after-free in bfqdispatchrequest+0x1045/0x44b0 [69832.243267] Read of size 8 at addr ffff88802622ba88 by task kworker/3:1H/155 [69832.244656] [69832.245007] CPU: 3 PID: 155 Comm: kworker/3:1H Not tainted 5.10.0-10295-g576c6382529e #8 [69832.246626] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [69832.249069] Workqueue: kblockd blkmqrunworkfn [69832.250022] Call Trace: [69832.250541] dumpstack+0x9b/0xce [69832.251232] ? bfqdispatchrequest+0x1045/0x44b0 [69832.252243] printaddressdescription.constprop.6+0x3e/0x60 [69832.253381] ? cpuidletextend+0x5/0x5 [69832.254211] ? vprintkfunc+0x6b/0x120 [69832.254994] ? bfqdispatchrequest+0x1045/0x44b0 [69832.255952] ? bfqdispatchrequest+0x1045/0x44b0 [69832.256914] kasanreport.cold.9+0x22/0x3a [69832.257753] ? bfqdispatchrequest+0x1045/0x44b0 [69832.258755] checkmemoryregion+0x1c1/0x1e0 [69832.260248] bfqdispatchrequest+0x1045/0x44b0 [69832.261181] ? bfqbfqqexpire+0x2440/0x2440 [69832.262032] ? blkmqdelayrunhwqueues+0xf9/0x170 [69832.263022] blkmqdodispatchsched+0x52f/0x830 [69832.264011] ? blkmqschedrequestinserted+0x100/0x100 [69832.265101] blkmqscheddispatchrequests+0x398/0x4f0 [69832.266206] ? blkmqdodispatchctx+0x570/0x570 [69832.267147] ? switchto+0x5f4/0xee0 [69832.267898] blkmqscheddispatchrequests+0xdf/0x140 [69832.268946] blkmqrunhwqueue+0xc0/0x270 [69832.269840] blkmqrunworkfn+0x51/0x60 [69832.278170] processonework+0x6d4/0xfe0 [69832.278984] workerthread+0x91/0xc80 [69832.279726] ? kthreadparkme+0xb0/0x110 [69832.280554] ? processonework+0xfe0/0xfe0 [69832.281414] kthread+0x32d/0x3f0 [69832.282082] ? kthreadpark+0x170/0x170 [69832.282849] retfromfork+0x1f/0x30 [69832.283573] [69832.283886] Allocated by task 7725: [69832.284599] kasansavestack+0x19/0x40 [69832.285385] kasankmalloc.constprop.2+0xc1/0xd0 [69832.286350] kmemcacheallocnode+0x13f/0x460 [69832.287237] bfqgetqueue+0x3d4/0x1140 [69832.287993] bfqgetbfqqhandlesplit+0x103/0x510 [69832.289015] bfqinitrq+0x337/0x2d50 [69832.289749] bfqinsertrequests+0x304/0x4e10 [69832.290634] blkmqschedinsertrequests+0x13e/0x390 [69832.291629] blkmqflushpluglist+0x4b4/0x760 [69832.292538] blkflushpluglist+0x2c5/0x480 [69832.293392] ioscheduleprepare+0xb2/0xd0 [69832.294209] ioscheduletimeout+0x13/0x80 [69832.295014] waitforcommonio.constprop.1+0x13c/0x270 [69832.296137] submitbiowait+0x103/0x1a0 [69832.296932] blkdevissuediscard+0xe6/0x160 [69832.297794] blkioctldiscard+0x219/0x290 [69832.298614] blkdevcommonioctl+0x50a/0x1750 [69832.304715] blkdevioctl+0x470/0x600 [69832.305474] blockioctl+0xde/0x120 [69832.306232] vfsioctl+0x6c/0xc0 [69832.306877] sesysioctl+0x90/0xa0 [69832.307629] dosyscall64+0x2d/0x40 [69832.308362] entrySYSCALL64afterhwframe+0x44/0xa9 [69832.309382] [69832.309701] Freed by task 155: [69832.310328] kasansavestack+0x19/0x40 [69832.311121] kasansettrack+0x1c/0x30 [69832.311868] kasansetfreeinfo+0x1b/0x30 [69832.312699] kasanslabfree+0x111/0x160 [69832.313524] kmemcachefree+0x94/0x460 [69832.314367] bfqputqueue+0x582/0x940 [69832.315112] bfqbfqdresetinservice+0x166/0x1d0 [69832.317275] bfqbfqqexpire+0xb27/0x2440 [69832.318084] bfqdispatchrequest+0x697/0x44b0 [69832.318991] blkmqdodispatchsched+0x52f/0x830 [69832.319984] blkmqscheddispatchrequests+0x398/0x4f0 [69832.321087] blkmqscheddispatchrequests+0xdf/0x140 [69832.322225] blkmqrunhwqueue+0xc0/0x270 [69832.323114] blkmqrunworkfn+0x51/0x6 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on curseg->alloctype
As Wenqing Liu reported in bugzilla:
https://bugzilla.kernel.org/showbug.cgi?id=215657
- Overview UBSAN: array-index-out-of-bounds in fs/f2fs/segment.c:3460:2 when mount and operate a corrupted image
- Reproduce tested on kernel 5.17-rc4, 5.17-rc6
1. mkdir testcrash 2. cd testcrash 3. unzip tmp2.zip 4. mkdir mnt 5. ./singletest.sh f2fs 2
- Kernel dump [ 46.434454] loop0: detected capacity change from 0 to 131072 [ 46.529839] F2FS-fs (loop0): Mounted with checkpoint version = 7548c2d9 [ 46.738319] ================================================================================ [ 46.738412] UBSAN: array-index-out-of-bounds in fs/f2fs/segment.c:3460:2 [ 46.738475] index 231 is out of range for type 'unsigned int [2]' [ 46.738539] CPU: 2 PID: 939 Comm: umount Not tainted 5.17.0-rc6 #1 [ 46.738547] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 46.738551] Call Trace: [ 46.738556] <TASK> [ 46.738563] dumpstacklvl+0x47/0x5c [ 46.738581] ubsanepilogue+0x5/0x50 [ 46.738592] ubsanhandleoutofbounds+0x68/0x80 [ 46.738604] f2fsallocatedatablock+0xdff/0xe60 [f2fs] [ 46.738819] dowritepage+0xef/0x210 [f2fs] [ 46.738934] f2fsdowritenodepage+0x3f/0x80 [f2fs] [ 46.739038] writenodepage+0x2b7/0x920 [f2fs] [ 46.739162] f2fssyncnodepages+0x943/0xb00 [f2fs] [ 46.739293] f2fswritecheckpoint+0x7bb/0x1030 [f2fs] [ 46.739405] killf2fssuper+0x125/0x150 [f2fs] [ 46.739507] deactivatelockedsuper+0x60/0xc0 [ 46.739517] deactivatesuper+0x70/0xb0 [ 46.739524] cleanupmnt+0x11a/0x200 [ 46.739532] cleanupmnt+0x16/0x20 [ 46.739538] taskworkrun+0x67/0xa0 [ 46.739547] exittousermodeprepare+0x18c/0x1a0 [ 46.739559] syscallexittousermode+0x26/0x40 [ 46.739568] dosyscall64+0x46/0xb0 [ 46.739584] entrySYSCALL64afterhwframe+0x44/0xae
The root cause is we missed to do sanity check on curseg->alloctype, result in out-of-bound accessing on sbi->blockcount[] array, fix it.
In the Linux kernel, the following vulnerability has been resolved:
block, bfq: don't move oombfqq
Our test report a UAF:
[ 2073.019181] ================================================================== [ 2073.019188] BUG: KASAN: use-after-free in bfqputasyncbfqq+0xa0/0x168 [ 2073.019191] Write of size 8 at addr ffff8000ccf64128 by task rmmod/72584 [ 2073.019192] [ 2073.019196] CPU: 0 PID: 72584 Comm: rmmod Kdump: loaded Not tainted 4.19.90-yk #5 [ 2073.019198] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 2073.019200] Call trace: [ 2073.019203] dumpbacktrace+0x0/0x310 [ 2073.019206] showstack+0x28/0x38 [ 2073.019210] dumpstack+0xec/0x15c [ 2073.019216] printaddressdescription+0x68/0x2d0 [ 2073.019220] kasanreport+0x238/0x2f0 [ 2073.019224] asanstore8+0x88/0xb0 [ 2073.019229] bfqputasyncbfqq+0xa0/0x168 [ 2073.019233] bfqputasyncqueues+0xbc/0x208 [ 2073.019236] bfqpdoffline+0x178/0x238 [ 2073.019240] blkcgdeactivatepolicy+0x1f0/0x420 [ 2073.019244] bfqexitqueue+0x128/0x178 [ 2073.019249] blkmqexitsched+0x12c/0x160 [ 2073.019252] elevatorexit+0xc8/0xd0 [ 2073.019256] blkexitqueue+0x50/0x88 [ 2073.019259] blkcleanupqueue+0x228/0x3d8 [ 2073.019267] nulldeldev+0xfc/0x1e0 [nullblk] [ 2073.019274] nullexit+0x90/0x114 [nullblk] [ 2073.019278] arm64sysdeletemodule+0x358/0x5a0 [ 2073.019282] el0svccommon+0xc8/0x320 [ 2073.019287] el0svchandler+0xf8/0x160 [ 2073.019290] el0svc+0x10/0x218 [ 2073.019291] [ 2073.019294] Allocated by task 14163: [ 2073.019301] kasankmalloc+0xe0/0x190 [ 2073.019305] kmemcacheallocnodetrace+0x1cc/0x418 [ 2073.019308] bfqpdalloc+0x54/0x118 [ 2073.019313] blkcgactivatepolicy+0x250/0x460 [ 2073.019317] bfqcreategrouphierarchy+0x38/0x110 [ 2073.019321] bfqinitqueue+0x6d0/0x948 [ 2073.019325] blkmqinitsched+0x1d8/0x390 [ 2073.019330] elevatorswitchmq+0x88/0x170 [ 2073.019334] elevatorswitch+0x140/0x270 [ 2073.019338] elvioschedstore+0x1a4/0x2a0 [ 2073.019342] queueattrstore+0x90/0xe0 [ 2073.019348] sysfskfwrite+0xa8/0xe8 [ 2073.019351] kernfsfopwrite+0x1f8/0x378 [ 2073.019359] vfswrite+0xe0/0x360 [ 2073.019363] vfswrite+0xf0/0x270 [ 2073.019367] ksyswrite+0xdc/0x1b8 [ 2073.019371] arm64syswrite+0x50/0x60 [ 2073.019375] el0svccommon+0xc8/0x320 [ 2073.019380] el0svchandler+0xf8/0x160 [ 2073.019383] el0svc+0x10/0x218 [ 2073.019385] [ 2073.019387] Freed by task 72584: [ 2073.019391] kasanslabfree+0x120/0x228 [ 2073.019394] kasanslabfree+0x10/0x18 [ 2073.019397] kfree+0x94/0x368 [ 2073.019400] bfqgput+0x64/0xb0 [ 2073.019404] bfqgandblkgput+0x90/0xb0 [ 2073.019408] bfqputqueue+0x220/0x228 [ 2073.019413] bfqputasyncbfqq+0x98/0x168 [ 2073.019416] bfqputasyncqueues+0xbc/0x208 [ 2073.019420] bfqpdoffline+0x178/0x238 [ 2073.019424] blkcgdeactivatepolicy+0x1f0/0x420 [ 2073.019429] bfqexitqueue+0x128/0x178 [ 2073.019433] blkmqexitsched+0x12c/0x160 [ 2073.019437] elevatorexit+0xc8/0xd0 [ 2073.019440] blkexitqueue+0x50/0x88 [ 2073.019443] blkcleanupqueue+0x228/0x3d8 [ 2073.019451] nulldeldev+0xfc/0x1e0 [nullblk] [ 2073.019459] nullexit+0x90/0x114 [nullblk] [ 2073.019462] arm64sysdeletemodule+0x358/0x5a0 [ 2073.019467] el0svccommon+0xc8/0x320 [ 2073.019471] el0svchandler+0xf8/0x160 [ 2073.019474] el0svc+0x10/0x218 [ 2073.019475] [ 2073.019479] The buggy address belongs to the object at ffff8000ccf63f00 which belongs to the cache kmalloc-1024 of size 1024 [ 2073.019484] The buggy address is located 552 bytes inside of 1024-byte region [ffff8000ccf63f00, ffff8000ccf64300) [ 2073.019486] The buggy address belongs to the page: [ 2073.019492] page:ffff7e000333d800 count:1 mapcount:0 mapping:ffff8000c0003a00 index:0x0 compoundmapcount: 0 [ 2073.020123] flags: 0x7ffff0000008100(slab|head) [ 2073.020403] raw: 07ffff0000008100 ffff7e0003334c08 ffff7e00001f5a08 ffff8000c0003a00 [ 2073.020409] ra ---truncated---
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:
scsi: qla2xxx: Implement ref count for SRB
The timeout handler and the done function are racing. When qla2x00asynciocbtimeout() starts to run it can be preempted by the normal response path (via the firmware?). qla24xxasyncgpscspdone() releases the SRB unconditionally. When scheduling back to qla2x00asynciocbtimeout() qla24xxasyncabortcmd() will access an freed sp->qpair pointer:
qla2xxx [0000:83:00.0]-2871:0: Async-gpsc timeout - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21. qla2xxx [0000:83:00.0]-2853:0: Async done-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21 qla2xxx [0000:83:00.0]-2854:0: Async-gpsc OUT WWPN 20:45:00:27:f8:75:33:00 speeds=2c00 speed=0400. qla2xxx [0000:83:00.0]-28d8:0: qla24xxhandlegpscevent 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: qla24xxasyncabortcmd+0x1b/0x1c0 [qla2xxx]
Obvious solution to this is to introduce a reference counter. One reference is taken for the normal code path (the 'good' case) and one for the timeout path. As we always race between the normal good case and the timeout/abort handler we need to serialize it. Also we cannot assume any order between the handlers. Since this is slow path we can use proper synchronization via locks.
When we are able to cancel a timer (deltimer returns 1) we know there can't be any error handling in progress because the timeout handler hasn't expired yet, thus we can safely decrement the refcounter by one.
If we are not able to cancel the timer, we know an abort handler is running. We have to make sure we call sp->done() in the abort handlers before calling krefput().
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.