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

wifi: cfg80211: enforce HE/EHT cap/oper consistency

Xiang Mei reports that mac80211 could crash if ehtcap is set but ehtoper isn't. Rather than fixing that for the individual user(s), enforce that both HE/EHT have consistent elements.

block: avoid possible overflow for chunksectors check in blkstacklimits()

bpf: Forget ranges when refining tnum after JSET

fs: Prevent file descriptor table allocations exceeding INTMAX

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

net: usb: asixdevices: add phymask for ax88772 mdio bus

Without setting phymask for ax88772 mdio bus, current driver may create at most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f. DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phy device will bind to net phy driver. This is creating issue during system suspend/resume since phypollingmode() in phystatemachine() will directly deference member of phydev->drv for non-main phy devices. Then NULL pointer dereference issue will occur. Due to only external phy or internal phy is necessary, add phymask for ax88772 mdio bus to workarnoud the issue.

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

netlink: avoid infinite retry looping in netlinkunicast()

netlinkattachskb() checks for the socket's read memory allocation constraints. Firstly, it has:

rmem < READONCE(sk->skrcvbuf)

to check if the just increased rmem value fits into the socket's receive buffer. If not, it proceeds and tries to wait for the memory under:

rmem + skb->truesize > READONCE(sk->skrcvbuf)

The checks don't cover the case when skb->truesize + sk->skrmemalloc is equal to sk->skrcvbuf. Thus the function neither successfully accepts these conditions, nor manages to reschedule the task - and is called in retry loop for indefinite time which is caught as:

rcu: INFO: rcusched self-detected stall on CPU rcu: 0-....: (25999 ticks this GP) idle=ef2/1/0x4000000000000000 softirq=262269/262269 fqs=6212 (t=26000 jiffies g=230833 q=259957) NMI backtrace for cpu 0 CPU: 0 PID: 22 Comm: kauditd Not tainted 5.10.240 #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc42 04/01/2014 Call Trace: <IRQ> dumpstack lib/dumpstack.c:120 nmicpubacktrace.cold lib/nmibacktrace.c:105 nmitriggercpumaskbacktrace lib/nmibacktrace.c:62 rcudumpcpustacks kernel/rcu/treestall.h:335 rcuschedclockirq.cold kernel/rcu/tree.c:2590 updateprocesstimes kernel/time/timer.c:1953 tickschedhandle kernel/time/tick-sched.c:227 tickschedtimer kernel/time/tick-sched.c:1399 hrtimerrunqueues kernel/time/hrtimer.c:1652 hrtimerinterrupt kernel/time/hrtimer.c:1717 sysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1113 asmcallirqonstack arch/x86/entry/entry64.S:808 </IRQ>

netlinkattachskb net/netlink/afnetlink.c:1234 netlinkunicast net/netlink/afnetlink.c:1349 kauditdsendqueue kernel/audit.c:776 kauditdthread kernel/audit.c:897 kthread kernel/kthread.c:328 retfromfork arch/x86/entry/entry64.S:304

Restore the original behavior of the check which commit in Fixes accidentally missed when restructuring the code.

Found by Linux Verification Center (linuxtesting.org).

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

netfilter: ctnetlink: fix refcount leak on table dump

There is a reference count leak in ctnetlinkdumptable(): if (res < 0) { nfconntrackget(&ct->ctgeneral); // HERE cb->args[1] = (unsigned long)ct; ...

While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone.

This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0.

This will then block the netns dismantle (or conntrack rmmod) as nfconntrackcleanupnetlist() will wait forever.

This can be reproduced by running conntrackresize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nfconntrackcleanupnetlist.

One fix would to change this to: if (res < 0) { if (ct != last) nfconntrackget(&ct->ctgeneral);

But this reference counting isn't needed in the first place. We can just store a cookie value instead.

A followup patch will do the same for ctnetlinkexpdumptable, it looks to me as if this has the same problem and like ctnetlinkdumptable, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.

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

mm/ptdump: take the memory hotplug lock inside ptdumpwalkpgd()

Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful.

But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems.

To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernelpagetables.

Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernelpagetables/checkwxpages which in turn calls ptdumpcheckwx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdumpcheckwx() which will benefit both the scenarios.

Drop getonlinemems() and putonlinemems() combination from all existing platform ptdump code paths.

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

md/raid10: fix deadlock with check operation and nowait requests

When an array check is running it will raise the barrier at which point normal requests will become blocked and increment the nrpending value to signal there is work pending inside of waitbarrier(). NOWAIT requests do not block and so will return immediately with an error, and additionally do not increment nrpending in waitbarrier(). Upstream change commit 43806c3d5b9b ("raid10: cleanup memleak at raid10makerequest") added a call to raidendbioio() to fix a memory leak when NOWAIT requests hit this condition. raidendbioio() eventually calls allowbarrier() and it will unconditionally do an atomicdecandtest(&conf->nrpending) even though the corresponding increment on nrpending didn't happen in the NOWAIT case.

This can be easily seen by starting a check operation while an application is doing nowait IO on the same array. This results in a deadlocked state due to nrpending value underflowing and so the md resync thread gets stuck waiting for nrpending to == 0.

Output of r10conf state of the array when we hit this condition:

crash> struct r10conf barrier = 1, nrpending = { counter = -41 }, nrwaiting = 15, nrqueued = 0,

Example of mdsync thread stuck waiting on raisebarrier() and other requests stuck in waitbarrier():

md1resync [<0>] raisebarrier+0xce/0x1c0 [<0>] raid10syncrequest+0x1ca/0x1ed0 [<0>] mddosync+0x779/0x1110 [<0>] mdthread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] retfromfork+0x34/0x50 [<0>] retfromforkasm+0x1a/0x30

kworker/u1040:2+flush-253:4 [<0>] waitbarrier+0x1de/0x220 [<0>] regularrequestwait+0x30/0x180 [<0>] raid10makerequest+0x261/0x1000 [<0>] mdhandlerequest+0x13b/0x230 [<0>] submitbio+0x107/0x1f0 [<0>] submitbionoacctnocheck+0x16f/0x390 [<0>] ext4iosubmit+0x24/0x40 [<0>] ext4dowritepages+0x254/0xc80 [<0>] ext4writepages+0x84/0x120 [<0>] dowritepages+0x7a/0x260 [<0>] writebacksingleinode+0x3d/0x300 [<0>] writebacksbinodes+0x1dd/0x470 [<0>] writebackinodeswb+0x4c/0xe0 [<0>] wbwriteback+0x18b/0x2d0 [<0>] wbworkfn+0x2a1/0x400 [<0>] processonework+0x149/0x330 [<0>] workerthread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] retfromfork+0x34/0x50 [<0>] retfromforkasm+0x1a/0x30

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

pNFS: Fix uninited ptr deref in block/scsi layout

The error occurs on the third attempt to encode extents. When function exttreepreparecommit() reallocates a larger buffer to retry encoding extents, the "layoutupdatepages" page array is initialized only after the retry loop. But exttreefreecommitdata() is called on every iteration and tries to put pages in the array, thus dereferencing uninitialized pointers.

An additional problem is that there is no limit on the maximum possible buffersize. When there are too many extents, the client may create a layoutcommit that is larger than the maximum possible RPC size accepted by the server.

During testing, we observed two typical scenarios. First, one memory page for extents is enough when we work with small files, append data to the end of the file, or preallocate extents before writing. But when we fill a new large file without preallocating, the number of extents can be huge, and counting the number of written extents in exttreeencodecommit() does not help much. Since this number increases even more between unlocking and locking of exttree, the reallocated buffer may not be large enough again and again.

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

misc: tifpc202: fix a potential memory leak in probe function

Use foreachchildofnodescoped() to simplify the code and ensure the device node reference is automatically released when the loop scope ends.

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

drm/tests: shmem: Hold reservation lock around vmap/vunmap

Acquire and release the GEM object's reservation lock around vmap and vunmap operations. The tests use vmaplocked, which led to errors such as show below.

[ 122.292030] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drmgemshmemhelper.c:390 drmgemshmemvmaplocked+0x3a3/0x6f0

[ 122.468066] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drmgemshmemhelper.c:293 drmgemshmempinlocked+0x1fe/0x350

[ 122.563504] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drmgemshmemhelper.c:234 drmgemshmemgetpageslocked+0x23c/0x370

[ 122.662248] WARNING: CPU: 2 PID: 1413 at drivers/gpu/drm/drmgemshmemhelper.c:452 drmgemshmemvunmaplocked+0x101/0x330

Only export the new vmap/vunmap helpers for Kunit tests. These are not interfaces for regular drivers.

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

drm/tests: shmem: Hold reservation lock around purge

Acquire and release the GEM object's reservation lock around calls to the object's purge operation. The tests use drmgemshmempurgelocked(), which led to errors such as show below.

[ 58.709128] WARNING: CPU: 1 PID: 1354 at drivers/gpu/drm/drmgemshmemhelper.c:515 drmgemshmempurgelocked+0x51c/0x740

Only export the new helper drmgemshmempurge() for Kunit tests. This is not an interface for regular drivers.

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

drm/tests: shmem: Hold reservation lock around madvise

Acquire and release the GEM object's reservation lock around calls to the object's madvide operation. The tests use drmgemshmemmadviselocked(), which led to errors such as show below.

[ 58.339389] WARNING: CPU: 1 PID: 1352 at drivers/gpu/drm/drmgemshmemhelper.c:499 drmgemshmemmadviselocked+0xde/0x140

Only export the new helper drmgemshmemmadvise() for Kunit tests. This is not an interface for regular drivers.

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

gpio: aggregator: remove the software node when deactivating the aggregator

The dynamic software node we create for the aggregator platform device when using configfs is leaked when the device is deactivated. Destroy it as the last step in the tear-down path.

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

ovpn: fix race between deleting interface and adding new peer

While deleting an existing ovpn interface, there is a very narrow window where adding a new peer via netlink may cause the netdevice to hang and prevent its unregistration.

It may happen during ovpndellink(), when all existing peers are freed and the device is queued for deregistration, but a CMDPEERNEW message comes in adding a new peer that takes again a reference to the netdev.

At this point there is no way to release the device because we are under the assumption that all peers were already released.

Fix the race condition by releasing all peers in ndouninit(), when the netdevice has already been removed from the netdev list.

Also ovpnpeeradd() has now an extra check that forces the function to bail out if the device regstate is not REGISTERED. This way any incoming CMDPEERNEW racing with the interface deletion routine will simply stop before adding the peer.

Note that the above check happens while holding the netdevlock to prevent racing netdev state changes.

ovpndellink() is now empty and can be removed.

drm/msm: Add error handling for krealloc in metadata setup

drm/amd/display: add null check

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

mm/smaps: fix race between smapshugetlbrange and migration

smapshugetlbrange() handles the pte without holdling ptl, and may be concurrenct with migration, leaing to BUGON in pfnswapentrytopage(). The race is as follows.

smapshugetlbrange migratepages hugeptepget removemigrationptes foliounlock pfnswapentryfolio BUGON

To fix it, hold ptl lock in smapshugetlbrange().

drm/amd/pm: fix null pointer access

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

crypto: ccp - Do not initialize SNP for ioctl(SNPCONFIG)

Sashiko notes:

if SEV initialization fails and KVM is actively running normal VMs, could a userspace process trigger this code path via /dev/sev ioctls (e.g., SEVPDHGEN) and zero out MSRVMHSAVEPA globally? Would the next VMRUN execution for an active VM trigger a general protection fault and crash the host?

Refuse to re-try initialization if SNP is not already initialized for SNPCONFIG.

This is technically an ABI break: before if SNP initialization failed it could be transparently retriggered by this ioctl, and if no VMs were running, everything worked fine. Hopefully this is enough of a corner case that nobody will notice, but someone does, there are a few options:

do something like symbolget() for kvm and refuse to initialize if KVM is loaded check each cpu's HSAVEPA for non-zero data before re-initializing once initialization has failed, continue to refuse to initialize until the ccp module is unloaded

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

crypto: ccp - Do not initialize SNP for ioctl(SNPVLEKLOAD)

Sashiko notes:

if SEV initialization fails and KVM is actively running normal VMs, could a userspace process trigger this code path via /dev/sev ioctls (e.g., SEVPDHGEN) and zero out MSRVMHSAVEPA globally? Would the next VMRUN execution for an active VM trigger a general protection fault and crash the host?

The SEV firmware docs for SNPVLEKLOAD note:

On SNPSHUTDOWN, the VLEK is deleted.

That is, the initialization/shutdown wrapper here is pointless, because the firmware immediately throws away the key anyway. Instead, refuse to do anything if SNP has not been previously initialized.

This is an ABI break: before, this was a no-op and almost certainly a mistake by userspace, and now it returns -ENODEV. ABI compatibility could be maintained here by simply returning 0 in the check instead.

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

crypto: ccp - Do not initialize SNP for ioctl(SNPCOMMIT)

Sashiko notes:

if SEV initialization fails and KVM is actively running normal VMs, could a userspace process trigger this code path via /dev/sev ioctls (e.g., SEVPDHGEN) and zero out MSRVMHSAVEPA globally? Would the next VMRUN execution for an active VM trigger a general protection fault and crash the host?

The SNPCOMMIT command does not require the firmware to be in any particular state. Skip initializing it if it was previously uninitialized.

The SEV-SNP firmware specification doc 56860 does not mention SNPCOMMIT in Table 5 as a command that is allowed in the UNINIT state, but it is in fact allowed and a future documentation update will reflect that.

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

crypto: ccp - Do not initialize SNP for SEV ioctls

Sashiko notes:

if SEV initialization fails and KVM is actively running normal VMs, could a userspace process trigger this code path via /dev/sev ioctls (e.g., SEVPDHGEN) and zero out MSRVMHSAVEPA globally? Would the next VMRUN execution for an active VM trigger a general protection fault and crash the host?

sevmovetoinitstate() is called for ioctls requiring only SEV firmware: SEVPEKGEN, SEVPDHGEN, SEVPEKCSR, SEVPEKCERTIMPORT, and SEVPDHCERTEXPORT. After the firmware command, it does SEVSHUTDOWN on the SEV firmware. Since these commands do not require SNP to be initialized, skip it by calling sevplatforminitlocked() which only initializes the SEV firmware. This way SNP is not Initialized at all, and HSAVEPA is not cleared.

The previous code saved any SEV initialization firmware error to initargs.error and then threw it away and hardcoded the return value of INVALIDPLATFORMSTATE regardless of the real firmware error. This patch changes it to surface the underlying error, which is hopefully both more useful and doesn't cause any problems.

Note that it is still safe to call sevfirmwareshutdown() directly: it calls sevsnpshutdownlocked(), which skips SNP shutdown if SNP was not initialized.

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

crypto: chacha20poly1305 - validate poly1305 template argument

chachapolycreate() still accepts the compatibility poly1305 parameter in the template name, but it assumes the second template argument is always present and immediately passes it to strcmp().

When the argument is missing, cryptoattralgname() returns an error pointer. Check for that before comparing the name so malformed template instantiations fail with an error instead of dereferencing the error pointer in strcmp().

This matches the surrounding Crypto API template pattern where cryptoattralgname() results are validated before string-specific use.

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

KVM: arm64: nv: Avoid dereferencing NULL VNCR pseudo-TLB

VNCR TLB invalidation occurs from MMU notifiers or TLBI instructions, and either can race against a vcpu not being onlined yet (no pseudo-TLB allocated). Similarly, the TLB might be invalid, and the invalidation should be skipped in this case.

Both kvminvalidatevncripa() and kvminvalidatevncrva() are expected to perform the same checks, except that the latter doesn't check for the allocation and blindly dereferences the pointer.

Solve this by introducing a new iterator built on top of the usual kvmforeachvcpu() that checks for both of the above conditions, and convert the two users to it.

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

KVM: arm64: Don't leak PFN when kvmtranslatevncr() races MMU notifier

In the case that kvmtranslatevncr() races with an MMU notifier the early return does not release a reference on the faulted in PFN. Add the necessary call to kvmreleasefaultinpage() for the unused PFN.

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

fuse-uring: fix moving cancelled entry to entinuserspace list

fuseuringcancel() moves entries that are available (these have no reqs attached) to the entinuserspace list. entlistrequestexpired() checks the first entry on entinuserspace and dereferences ent->fusereq unconditionally, which will crash on a cancelled entry that was moved to this list.

Fix this by freeing the entry and dropping queuerefs directly in fuseuringcancel(). This is safe because cancel is the cancel handler itself - after iouringcmddone(), no more cancels will be dispatched for this command, and teardown serializes with cancel via queue->lock.

Since cancel now decrements queuerefs, fuseuringabort() must no longer gate fuseuringabortendrequests() on queuerefs > 0, as cancelled entries may have already dropped queuerefs while requests are still queued. Remove the gate so abort always flushes requests and stops queues.

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

fuse-uring: remove request-less entries from entwreqqueue to fix NULL deref

If a copy into the userspace ring buffer fails, a request will be terminated and fuseuringreqend() will set ent->fusereq to NULL but it will leave the entry on entwreqqueue in FRRSFUSEREQ state. This can lead to a NULL deref if the request expiration logic scans entwreqqueue in the window before the entry is moved off it.

Fix this by taking the entry off entwreqqueue and changing its state from FRRSFUSEREQ to FRRSINVALID before terminating the request.

ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered