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, 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
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:
media: staging: media: zoran: calculate the right buffer number for zoranreapstatcom
On the case tmpdcim=1, the index of buffer is miscalculated. This generate a NULL pointer dereference later.
So let's fix the calcul and add a check to prevent this to reappear.
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.
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).
In the Linux kernel, the following vulnerability has been resolved:
iio: frequency: admv1013: fix NULL pointer dereference on str
When devicepropertyreadstring() fails, str is left uninitialized but the code falls through to strcmp(str, ...), dereferencing a garbage pointer. Replace manual read/strcmp with devicepropertymatchpropertystring() and consolidate the SE mode enums into a single sequential enum, mapping to hardware register values via a switch consistent with other bitfields in the driver.
Several cleanup patches have been applied to this driver recently so this will need a manual backport.
In the Linux kernel, the following vulnerability has been resolved:
can: isotp: sanitize CAN ID checks in isotpbind()
Syzbot created an environment that lead to a state machine status that can not be reached with a compliant CAN ID address configuration. The provided address information consisted of CAN ID 0x6000001 and 0xC28001 which both boil down to 11 bit CAN IDs 0x001 in sending and receiving.
Sanitize the SFF/EFF CAN ID values before performing the address checks.
A flaw was found in the MCTP protocol in the Linux kernel. The function mctpunregister() reclaims the device's relevant resource when a netcard detaches. However, a running routine may be unaware of this and cause the use-after-free of the mdev->addrs object, potentially leading to a denial of service.
A NULL pointer dereference issue was discovered in the Linux kernel in the MPTCP protocol when traversing the subflow list at disconnect time. A local user could use this flaw to potentially crash the system causing a denial of service.
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Fix NULL pointer dereference in acpievaddressspacedispatch()
Cover a missed execution path with a new check.