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

dm-integrity: fix NULL pointer dereference when the 'R' flag is used

If the dm-integrity device has the SBFLAGDIRTYBITMAP flag set and the user activates the device in the 'R' mode, a crash in dmintegrityresume happens because the function attempts to read the journal containing the bitmap.

This patch makes dm-integrity skip any writes to the device in dmintegrityresume if the device is activated in the 'R' mode.

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

dm-integrity: validate the superblock on resume

dmintegrityresume() re-reads the superblock from the device so that it picks up the flags and the recalculate position. It performs no validation on the result, while the constructor validates the superblock it reads and sizes all the in-memory structures according to it. The user may modify the superblock on the underlying device while the dm-integrity device is suspended, so that the two no longer agree.

In particular, accessjournaldata() shifts the journal entry index by ic->sb->log2sectorsperblock, while ic->journalsectionsectors and the journal page list were computed with the value that was present at constructor time. Increasing log2sectorsperblock makes the index run past the end of the journal, and dm-integrity then writes 512 bytes through lowmempageaddress(NULL).

Snapshot the validated superblock in the constructor and refuse to resume if any of the fields that describe the on-disk geometry changed.

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

schedext: Fix CPU hotplug hang when a dying CPU's tasks sit in the BPF scheduler

A CPU going down has to empty its own rq. Its hotplug thread waits in schedcpuwaitempty() until nothing else is left, and the only thing that wakes it is balancepush(), which runs from schedule() on the dying CPU and pushes off the migratable tasks the CPU picks.

schedext breaks this. A task sitting on a user DSQ or held by the BPF scheduler is still counted on its rq, but an inactive CPU no longer calls ops.dispatch() and can't pull the task back. The dying CPU goes idle with the task still counted, and one of two things happens:

- Another CPU consumes the task. The rq empties without a schedule() on the dying CPU, so the hotplug thread is never woken and cpudown() hangs holding cpuhotpluglock. - The task is affine only to the dying CPU. Nothing can move it, and the offline stalls until the watchdog ejects the BPF scheduler.

When the rq goes offline, re-enqueue every task on it that isn't already on the local DSQ. An enqueue on an offline rq lands on the local DSQ, so the dying CPU itself picks the tasks and balancepush() pushes them off, the same as for the other sched classes. From then on no schedext path on another CPU can pull a task off the rq.

ops.dispatch() currently stops as soon as the CPU goes inactive, and CPU hotplug then waits for an RCU grace period before taking the rq offline. A BPF-held task affine only to the dying CPU and preempted inside an RCU read-side critical section would block that grace period, and the rq would never go offline. Test SCXRQONLINE directly so that ops.dispatch() keeps running until the rq goes offline. Only the dying CPU's own hotplug thread clears the flag during teardown, and taskcanrunonremoterq() still keeps other rqs' tasks off the CPU.

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

readdir: take no inode lock on an immutable directory

iteratedir() takes the directory's irwsem shared and holds it across ->iterateshared(). For a directory that never has an entry and is never removed the lock keeps nothing still, it only orders every reader and every writer of that inode behind each other.

For the directory of a nullfs instance that matters. The instance of the initial mount namespace is the root of every empty mount namespace and the private instance is the root of every kernel thread, so one inode is shared across users who have nothing else in common. And a reader can hold the lock for as long as it likes: back the getdents() buffer with a mapping of a file on a FUSE mount of your own, let the copy of "." and ".." fault and let the server wait. Queue an exclusive taker behind it, a mkdir() in that directory goes through startdirop() before the read-only mount is reported, and from then on every lookup that misses the dcache in that directory, every create and every mount on it waits until the server answers. One user of an empty mount namespace stalls all the others.

Add FOPIMMUTABLE for the file operations of a directory that never changes and is never removed and let iteratedir() skip the lock for it. The flag never changes for a file, ->fpos is protected by fposlock since directories are FMODEATOMICPOS, ISDEADDIR can't be set on such a directory and neither touchatime() nor fsnotify take irwsem. Set it on the nullfs directory. The placeholder directories of libfs never have an entry either but their owners remove them, so they keep the lock.

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

ksmbd: fix heap out-of-bounds write in krb5authenticate()

In krb5authenticate(), outlen is calculated to determine available headroom in responsebuf for the incoming Kerberos AP-REP token. However, when SMB2SESSIONSETUP is processed as a non-first element of a compounded SMB2 request, the calculation omits work->nextsmb2rsphdroff.

This causes outlen to overstate remaining buffer headroom by the cumulative size of prior responses in the compound chain. Consequently, the length check in ksmbdkrb5authenticate() (outlen <= resp->spnegobloblen) passes erroneously, allowing memcpy() to write the AP-REP blob past the end of responsebuf into adjacent kernel heap memory.

Fix this by subtracting work->nextsmb2rsphdroff when computing outlen, ensuring it accurately reflects physical remaining buffer space.

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

KVM: x86: Use active memslots for the per-vCPU MMIO cache

KVM tags the per-vCPU MMIO cache with a memslot generation so that a memslot update invalidates cached MMIO information. Both the fill and validation paths use kvmmemslots(), which unconditionally selects address space 0, even when the vCPU is running in SMM and using address space 1.

Commit 56f17dd3fbc4 ("kvm: x86: fix stale mmio cache bug") added the memslot generation to the cache key so that a memslot update could not leave a stale entry valid. When commit 699023e23965 ("KVM: x86: add SMM to the MMU role, support SMRAM address space") added the SMM address space, these helpers were not converted to use the active memslots.

Consequently, an update to the SMM memslots can leave an entry from the old SMM address space apparently valid after the vCPU returns to the normal address space. A guest can then cause an access to valid RAM at the same GFN to be returned to userspace as KVMEXITMMIO.

Completing that exit through the VMM's RAM address space writes the backing page without going through KVM's write-tracking path. If the page backs a nested EPT table, KVM can continue using shadow translations derived from the old contents. The WARNONONCE() in kvmmmuwriteprotectfault() catches this invalid cache and memslot combination.

Use the vCPU's active memslots when caching and validating the entry. Memslot generations are unique across address spaces, so the generation also distinguishes the normal and SMM views. This matches the MMIO SPTE cache, which already uses kvmvcpumemslots().

On an unpatched current-mainline kernel, a regression test that fills the cache in SMM and updates only the SMM memslots fails the intended RAM write and triggers the kvmmmuwriteprotectfault() warning. With this change, the same test completes the RAM write without a warning. The x86/smmtest, setmemoryregiontest, and memslotmodificationstresstest selftests also pass.

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

bnxten: fix DMA mapping length for padded small packets

Stefan Fleischmann reported Intel IOMMU DMA Read faults on BCM57412 NetXtreme-E NICs when transmitting packets on VLAN/macvlan interfaces:

DMAR: [DMA Read NOPASID] Request device [18:00.0] fault addr 0xfc499000 [fault reason 0x06] PTE Read access is not set bnxten 0000:18:00.0 eno1np0: Abandoning msg {0xb4 0x41a} len: 0 due to firmware status: 0x2000001 ... NETDEV WATCHDOG: eno1np0 (bnxten): transmit queue 0 timed out

The fault address (0xfc499000) is on an exact 4KB page boundary, pointing to a DMA read buffer overrun.

In bnxtstartxmit(), packets smaller than BNXTMINPKTSIZE (52 bytes), such as 42-byte untagged ARP frames, are padded:

if (length < BNXTMINPKTSIZE) { pad = BNXTMINPKTSIZE - length; if (skbpad(skb, pad)) goto txkickpending; length = BNXTMINPKTSIZE; }

mapping = dmamapsingle(&pdev->dev, skb->data, len, DMATODEVICE); ... dmaunmaplenset(txbuf, len, len);

However, 'len' was initialized earlier to skbheadlen(skb) (e.g. 42 bytes) and is left unadjusted after padding. Consequently, dmamapsingle() and dmaunmaplenset() map and track only 42 bytes.

Later, the hardware TX buffer descriptor is programmed with the padded length:

txbd->txbdlenflagstype = cputole32(((len + pad) << TXBDLENSHIFT) | flags | TXBDFLAGSPACKETEND);

The NIC DMA engine is thus instructed to read 52 bytes from a region where only 42 bytes were DMA-mapped. If skb->data ends near the boundary of a 4KB page (within 'pad' bytes of the next page), the hardware DMA read overruns into the unmapped adjacent page, triggering an IOMMU fault.

This issue was exposed after commit 447cbe95ebb9 ("vlan: fix skbunderpanic and races when toggling HW VLAN offload") because reserving extra VLAN headroom rounded LLRESERVEDSPACE from 48 up to 64 bytes, shifting skb->data offsets and potentially causing small frames to land right against page boundaries.

Fix this by using skbputpadto(skb, BNXTMINPKTSIZE) in bnxtstartxmit(), before skbshinfo(skb)->nrfrags is sampled, because padding might linearize the skb. This ensures skb->len and skbheadlen(skb) reflect the padded size so that dmamapsingle() maps the full buffer and the descriptor length is consistent. This also removes the temporary 'pad' variable and masking logic.

The padding is done after the SW USO branch, otherwise bnxtswudpgsoxmit() would account the padding as UDP payload and send it in extra segments.

Note that SW USO segments are still not padded: with IPv4, a segment carrying less than 10 bytes of UDP payload (small gsosize, or a short last segment) is sent as a frame shorter than BNXTMINPKTSIZE. This is a separate issue, left for a followup patch.

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

fs: Free any excess xarray nodes in clearinode()

For many years we've had a hard to hit leak of xarray nodes. Hugh documented it well in commit 786b31121a2c. Recently people and syzbot have found ways to force it to happen with madvise. Rather than fix the leaks where they happen, just call xadestroy() which has the side-effect of cycling the ipages lock.

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

net/mlx5e: Prevent stale XSK buffer release on refill retry

When an XDP redirect to an AFXDP socket fails because its RX ring is full, the XSK core frees the buffer. During the subsequent batched refill of a legacy cyclic RQ, mlx5e also releases the WQE's XSK buffer before allocating a replacement. If that refill succeeds only partially, a WQE left without a replacement retains its old buffer pointer.

The buffer can meanwhile be allocated to another WQE. A later refill retry can then free the live buffer through the stale pointer and publish the same UMEM frame twice.

Mark the WQE as released immediately after the driver-side free. The flag is already cleared when a replacement buffer is assigned, so refill retries no longer release stale pointers.

The failure is silent and produces no kernel warning or splat. A standalone legacy cyclic-RQ zero-copy libxsk reproducer, using 64-byte UDP traffic offered at 12 Mpps, detected it: stock stopped after 2,854,914 packets in 4.094 seconds, with 4,542 xdprxringfull events and 64 ownership/double-publication errors. With this change it processed 356,904,225 packets in 30 seconds despite 571,405 xdprxringfull events, with no ownership or data errors.

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

net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry

With AFXDP on a striding RQ, mlx5e defers releasing XSK buffers until an MPWQE is refilled. If XSK allocation then returns -ENOMEM, actualwqhead is not advanced and a later NAPI poll retries the same WQE.

mlx5efreerxmpwqe() leaves each released slot marked as releasable. On retry it can therefore call xskbufffree() again through stale pointers after the frames have returned to the XSK pool and been reallocated.

Set all skipreleasebitmap bits in the common error path of mlx5exskallocrxmpwqe(). This matches mlx5eallocrxmpwqe(). A successful allocation already clears the bitmap after replacing every buffer, so retries become idempotent without changing the success path.

Fault injection forced three consecutive failures for one selected MPWQE. Both an early allocation failure and a partial 8-of-16-buffer unwind released the original 16 XSK buffers only once. Each error left a full bitmap, the following NAPI retry skipped the release, and a later successful allocation cleared it. A 20-second AFXDP zero-copy pressure run exercised 1,575,262 buffer allocation failures without invalid descriptors, WQE errors, or kernel warnings.

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

ipv4: udp: Create exceptions before socket matching

Currently, when ICMP Fragmentation Needed and Redirect Message packets are locally delivered and quote a UDP packet, a FIB nexthop exception (FNHE) is only created if the kernel can match the UDP packet to an existing socket.

This behavior allows off-path attackers to conduct a side-channel attack on the FNHE cache in order to discover the ephemeral port used by a connected UDP socket.

Commit 6457378fe796 ("ipv4: use siphash instead of Jenkins in fnhehashfun()") and commit 67d6d681e15b ("ipv4: make exception cache less predictible") tried to mitigate such attacks by making it harder for attackers to discover hash collisions in the FNHE cache and by randomizing the number of exceptions a hash bucket can hold, respectively. Unfortunately, both of the mitigations can be bypassed.

Instead, mitigate such attacks by always creating a FNHE, even before trying to find a matching socket. Do that by calling ipv4updatepmtu() and ipv4redirect(), the helpers used when the quoted packet did not originate from a socket.

This means that guesses (right or wrong) from an off-path attacker will always result in a FNHE being created or updated in the cache that the attacker can observe.

Pass an oif of 0, in a similar fashion to icmperr(). This is also the oif used by the socket path for sockets that are not bound to a device.

Note that this does not allow attackers to create FNHEs that they could not create before, as both helpers can already be reached with little to no validation. For example, by sending an ICMP error that quotes an ICMP Echo Reply or one that quotes a UDP source port that matches a wildcard socket.

Also note that in the good case (matched socket) the above scheme comes at the cost of an extra route lookup, as the no socket helpers perform their own lookup before the one performed by ipv4skupdatepmtu() / ipv4skredirect(). When the two resolve to different nexthops, it also results in two exceptions being created for the same destination IP. One in the FNHE cache of the nexthop resolved by the no socket helpers and another in the FNHE cache of the nexthop used by the socket.

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

ipv6: udp: Create exceptions before socket matching

Currently, when ICMPv6 Packet Too Big and Redirect Message packets are locally delivered and quote a UDP packet, an exception is only created in the IPv6 exception cache if the kernel can match the UDP packet to an existing socket.

This behavior allows off-path attackers to conduct a side-channel attack on the exception cache in order to discover the ephemeral port used by a connected UDP socket.

Commit 4785305c05b2 ("ipv6: use siphash in rt6exceptionhash()") and commit a00df2caffed ("ipv6: make exception cache less predictible") tried to mitigate such attacks by making it harder for attackers to discover hash collisions in the exception cache and by randomizing the number of exceptions a hash bucket can hold, respectively. Unfortunately, both of the mitigations can be bypassed.

Instead, mitigate such attacks by always creating an exception, even before trying to find a matching socket. Do that by calling ip6updatepmtu() and ip6redirect(), the helpers used when the quoted packet did not originate from a socket.

This means that guesses (right or wrong) from an off-path attacker will always result in an exception being created or updated in the cache that the attacker can observe.

Pass the ifindex of the ingress device and the default uid, in a similar fashion to icmpv6err(). Unlike IPv4, an oif of 0 would not match any nexthop in ip6redirectnhmatch() and no exception would be created in response to a Redirect Message.

Note that this does not allow attackers to create exceptions that they could not create before, as both helpers can already be reached with little to no validation. For example, by sending an ICMPv6 error that quotes an ICMPv6 Echo Reply or one that quotes a UDP source port that matches a wildcard socket.

Also note that in the good case (matched socket) the above scheme comes at the cost of an extra route lookup, as the no socket helpers perform their own lookup before the one performed by ip6skupdatepmtu() / ip6skredirect(). When the two resolve to different nexthops, it also results in two exceptions being created for the same destination IP. One in the exception cache of the nexthop resolved by the no socket helpers and another in the exception cache of the nexthop used by the socket.

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

rustbinder: reschedule node refcount update on thread exit

When a thread exits via BINDERTHREADEXIT, its pending work items are cancelled. If a thread exits while holding a pending node refcount increment (e.g. pushed as deferred work to that thread), the refcount increment was previously dropped because Node::cancel() and NodeWrapper::cancel() were no-ops.

Dropping the refcount update leaves the node's delivery state and count state desynchronized, and userspace will not receive the notification, which can cause the node to never be freed from the process's nodes tree when all external references are dropped.

Fix this by implementing DeliverToRead::cancel() for Node and NodeWrapper to move the pending refcount update to the process's work queue on thread exit so another thread can deliver it to userspace.

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

ipv4: stop PMTU walk when nexthop group shrinks

Commit 7d3f3b4367f3 ("net: ipv4: Cache pmtu for all packet paths if multipath enabled") made iprtupdatepmtu() update every path.

For nexthop objects, fibinfonumpath() and fibinfonhc() independently load nh->nhgrp. RCU protects each group's lifetime but does not make the loads observe the same group. If replacement shrinks the group after the loop accepts an index, fibinfonhc() returns NULL and updateorcreatefnhe() dereferences it.

A deterministic probe only widened the existing window between the real operations. On v7.2, an RTMNEWNEXTHOP replacement published a one-member group after the PMTU reader accepted index 1 from a two-member group, producing:

KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: updateorcreatefnhe+0x45/0x15b0

Stop when the indexed path is absent. Groups are dense, so no later index exists in that snapshot. The same real-writer window completed 114,423 PMTU iterations without an oops with this check. A reproducer is available on request.

Replacement requires CAPNETADMIN in the network namespace. Where unprivileged user namespaces are permitted, a local user can obtain it in a new user and network namespace.

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

ipv4: stop exception dump when nexthop group shrinks

Commit 4ce5dc9316de ("inet: switch inetdumpfib() to RCU protection") allowed IPv4 FIB dumps to run concurrently with nexthop replacement.

fibdumpinfofnhe() uses fibinfonumpath() as the loop bound, then fibinfonhc() independently reloads nh->nhgrp. If RTMNEWNEXTHOP replaces a group with fewer paths between those loads, fibinfonhc() returns NULL and the dump dereferences it through nhcflags.

Stop the walk when the indexed path is absent. Nexthop groups are dense, so the current snapshot has no later path.

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

ipv4: stop route notification sizing when nexthop group shrinks

Commit 680aea08e78c ("net: ipv4: Emit notification when fib hardware flags are changed") added an RCU-only fibnlmsgsize() call for asynchronous hardware flag notifications.

fibnlmsgsize() checks fibinfonumpath() before each iteration, then fibinfonhc() independently reloads nh->nhgrp. If RTMNEWNEXTHOP replaces a group with fewer paths between those loads, fibinfonhc() returns NULL and fibnexthopnlmsgsize() dereferences it.

Stop sizing when the indexed path is absent. Nexthop groups are dense, so the current snapshot has no later path.

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

ipv4: do not warn on route notification size race

Commit 680aea08e78c ("net: ipv4: Emit notification when fib hardware flags are changed") added asynchronous route notifications for hardware flag changes.

fibaliashwflagsset() sizes the skb with fibnlmsgsize() and later fills it with fibdumpinfo() while holding only RCU. With nexthop compatibility mode enabled, a concurrent replacement can grow the group between these independent snapshots. fibdumpinfo() can then legitimately return -EMSGSIZE, so the warning does not prove a sizing bug.

Remove the warning. The existing error path still frees the skb and reports the error to listeners.

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

ipv6: do not warn on route notification size race

fib6infohwflagsset() sizes the skb with rt6nlmsgsize() and later fills it with rt6fillnode(). With nexthop compatibility mode enabled, a concurrent replacement can grow the group between these independent snapshots. rt6fillnode() can then legitimately return -EMSGSIZE, so the warning does not prove a sizing bug.

Remove the warning. The existing error path still frees the skb and reports the error to listeners.

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

Input: atiremote2 - fix type confusion in device attribute handlers

Previously, the channelmask and modemask attributes were registered on the parent usbdevice via sysfscreategroup(). When commit b20d6bf8014b ("Input: ati-remote2 - use driver core to instantiate device attributes") converted the driver to let the driver core manage them via devgroups in struct usbdriver, the attributes moved to the bound usbinterface devices, but the show and store callbacks were not updated accordingly.

As a result, the callbacks still invoked tousbdevice() on a device pointer belonging to a struct usbinterface, producing an invalid usbdevice pointer.

Use tousbinterface() directly in the attribute handlers to obtain the interface and its driver data.

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

ALSA: ctxfi: Fix memory leakage when clearing DAO input mappers

Commit e576e7843c0d ("ALSA: ctxfi: Simplify daoclear{left,right}input() functions") centralized the DAO input mapper clearing logic in daoclearinput(), but omitted the kfree() calls.

It removes the mapper entries from the list and sets their pointers to NULL without freeing the allocated array. This leaks memory each time daoclearinput() is called.

Store the base pointer of the allocation before clearing the mapper entries and free the array after removing entries from the list.

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

btrfs: scrub: fix localroot reference leak in scrubprintwarninginode()

When pathsfrominode() fails, scrubprintwarninginode() jumps to err without dropping the reference taken by btrfsgetfsroot(), leaking a reference to the root every time path resolution fails while printing scrub warnings. Every other error and success path of the function drops the reference.

Drop the reference on the pathsfrominode() failure path too.

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

can: dev: initcanskb(): restore skb header initialization

Commit 9f10374bb024 ("can: remove private CAN skb headroom infrastructure") removed the skbresetmacheader()/skbresetnetworkheader()/ skbresettransportheader() calls from initcanskb(). As a result, RX skbs from alloccanskb() and friends again carry macheader = 0xFFFF. When such an skb reaches packetrcvspkt() (SOCKPACKET), the push length calculation overflows and triggers skbunderpanic -> kernel BUG -> full machine panic.

The same issue was originally reported in 2014 on linux-can and fixed by commit 969439016d2c ("can: add missing initialisations in CAN related skbuffs"). packetrcvspkt() itself has never been hardened: only packetrcv() and tpacketrcv() gained devhasheader() checks in commit d549699048b4 ("net/packet: fix packet receive on L3 devices without visible hard header").

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

cgroup/cpuset: Handle cpu hotplug race in guaranteeactivecpus()

With commit 2125c0034c5d ("cgroup/cpuset: Make cpuset hotplug processing synchronous"), the cpuset hotplug operation becomes synchronous. That commit also removes the code that handles race between cpusethotplugwork and cpu hotplug notifier with the assumption that race is now gone. Later commit 7a0aabd9ce69 ("cgroup/cpuset: Always use cpuactivemask") updates the cpuset code to always use cpuactivemask instead of cpuonlinemask in some places including guaranteeonlinecpus() which is renamed to guaranteeactivecpus() in that commit.

In the case of CPU offline operation, cpuactivemask is updated first in schedcpudeactivate() to remove the offline CPU before cpusethandlehotplug() is called to update the effectivecpus of the affected cpusets. The cpuonlinemask is updated after that near the end of the offline operation to remove the offline CPU. As a result, the race comes back and the top cpuset may not have any active CPU leading to NULL pointer dereference during the race window when guaranteeactivecpus() is called after cpuactivemask is updated to remove the CPU to be torn down but before cpusethandlehotplug() is able to properly update the effectivecpus of the top cpuset.

Fix this by adding back the NULL cs check to avoid this problem.

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

cipso: adjust cached option offsets when removing CIPSO

cipsov4skbuffdelattr() removes the CIPSO bytes but does not adjust cached offsets for options that follow them.

For example, with a valid 10-byte CIPSO option followed by a seven-byte RR option, parsing records rr at offset 30. Removing CIPSO moves RR to offset 20, while the cached offset remains 30. Consumers such as ipforwardoptions() and ipoptionsecho() then access the wrong bytes; the latter may interpret packet data as the option length and copy it into fixed-size option storage.

Mirror cipsov4delopt() and subtract cipsolen from the srr, rr, ts and routeralert offsets when they follow CIPSO. cipsolen is the distance the first memmove() shifts those options. The later header move and network-header reset relocate the bytes and their offset base together.

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

dm ioctl: don't let datastart run past the buffer

struct dmioctl has seven bytes of trailing padding, so the smallest buffer userspace is allowed to ask for, offsetof(struct dmioctl, data), is seven bytes shorter than sizeof(struct dmioctl).

getresultbuffer() sets datastart to sizeof(struct dmioctl) without looking at how big the buffer actually is. Ask for the minimum and datastart ends up seven bytes past the end. Callers add it to datasize, and ctlioctl() copies that much back to userspace:

BUG: KASAN: slab-out-of-bounds in copytouser+0xad/0xd0 Read of size 312 at addr ffff8880169e4c00 by task repro-dm/140 ctlioctl+0x5e3/0xcb0 dmctlioctl+0x25/0x40 allocated 305-byte region [ffff8880169e4c00, ffff8880169e4d31)

A DMLISTDEVICES with datasize set to 305 is enough to hit it, and the seven bytes that leak are whatever sat next to the allocation.

Clamp datastart to the buffer size.

Note that this is not a security bug because the out-of-bounds read can only be triggered by root.

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

vsock/virtio: account only unread bytes in readskb()

After a partial stream receive, rxbytes tracks the unread suffix while bufused and peer credit still cover the whole packet. virtiotransportreadskb() dequeues that packet but passes pktlen for both counters, underflowing rxbytes.

On a connected CIDLOCAL stream with an SKSKB verdict, a 40-byte read from a 100-byte packet made SIOCINQ report -40, an empty recv return ELOOP, and poll report the empty socket readable. After verdict detach, receiving 40 bytes wrapped the counter to zero and hid those queued bytes until one more byte arrived. The fixed run kept the counter balanced and exposed all queued data immediately.

This was found during an LLM-assisted manual source audit of VSOCK receive accounting while re-evaluating virtiotransportreadskb() after CVE-2024-50169.

Subtract only skb->len minus the VSOCK offset from rxbytes. Retain the full packet length for bufused and peer credit.

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

wifi: brcmfmac: fix P2P device removal race in brcmfdetach()

When the driver is removed while the user space process that created the P2P device (e.g. wpasupplicant) is still exiting, the P2P device interface is removed twice and the kernel crashes.

The two paths are:

- wpasupplicant, on exit, sends NL80211CMDDELINTERFACE for the P2P device. nl80211delinterface() holds RTNL and the wiphy mutex and calls brcmfp2pdelvif(), which disables discovery and waits up to 1.5 s for BRCMFEIFDEL. Then it calls brcmfremoveinterface(), which unregisters the wdev and frees the vif and the ifp.

- brcmfdetach() sets the bus down, so BRCMFEIFDEL never arrives, and calls brcmfremoveinterface(ifp, false) for the same ifp. brcmfp2pifpremoved() reads ifp->vif and then blocks on rtnllock(). When brcmfp2pdelvif() releases RTNL, it calls cfg80211unregisterwdev() on the wdev that was already unregistered and freed.

The second listdelrcu() of wdev->list faults on LISTPOISON2:

brcmfmac: brcmfp2pdelvif delete P2P vif brcmfmac: brcmfp2pdeinitdiscovery enter brcmfmac: brcmfp2pdelvif P2P: GONEGPHASE status cleared brcmfmac: brcmfdetach Enter brcmfmac: brcmfbuschangestate 1 -> 0 brcmfmac: brcmfremoveinterface Enter, bsscfgidx=1, ifidx=0 brcmfmac: brcmfdelif Enter, bsscfgidx=1, ifidx=0 brcmfmac: brcmfp2pifpremoved P2P: device interface removed [1.5 s later, brcmfp2pdelvif() timed out] brcmfmac: brcmfremoveinterface Enter, bsscfgidx=1, ifidx=0 brcmfmac: brcmfdelif Enter, bsscfgidx=1, ifidx=0 brcmfmac: brcmfp2pifpremoved P2P: device interface removed Unable to handle kernel paging request at virtual address dead000000000122 Internal error: Oops: 96000044 [#1] PREEMPTRT SMP pc : cfg80211unregisterwdev+0x6c/0x264 [cfg80211] Call trace: cfg80211unregisterwdev+0x6c/0x264 [cfg80211] cfg80211unregisterwdev+0x10/0x1c [cfg80211] brcmfp2pifpremoved+0x84/0xb0 [brcmfmac] brcmfremoveinterface+0x1f4/0x254 [brcmfmac] brcmfdetach+0x88/0x180 [brcmfmac] brcmfsdioremove+0x90/0x7b0 [brcmfmac] brcmfsdiodremove+0x20/0xa0 [brcmfmac] brcmfopssdioremove+0xbc/0x12c [brcmfmac] sdiobusremove+0x38/0x144 devicereleasedriverinternal+0x1e8/0x2c0 devicereleasedriver+0x14/0x20 brcmfsdiobusremove+0x2c/0x40 [brcmfmac] brcmffwvidunregistervendor+0xd8/0x170 [brcmfmac] exitcompat+0x18/0x418 [brcmfmaccyw] arm64sysdeletemodule+0x1ac/0x244

The log was taken with debug=0x406 on an i.MX 8M Plus board with a CYW55513 (Sona IF513) on SDIO. The driver is the Ezurio backport of brcmfmac from v6.18.22 on a 5.4-rt kernel. The code involved is the same in mainline.

To reproduce:

1. Start wpasupplicant on wlan0 and let it associate. It creates the P2P device (iw dev shows "type P2P-device"). 2. Stop wpasupplicant and remove the driver without waiting for wpasupplicant to exit:

kill $(pidof wpasupplicant) rmmod brcmfmaccyw brcmfmac

The crash is reproducible on that board.

For the interface without a netdev (the P2P device), take RTNL and the wiphy mutex in brcmfdetach() before reading iflist, and remove it with locked=true. If brcmfp2pdelvif() runs first, brcmfdetach() finds the slot empty. If brcmfdetach() runs first, nl80211 does not find the wdev any more. The interfaces with a netdev are removed as before, because brcmfdelif() takes RTNL on its own for the primary interface.

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

wifi: mt76: mt7603: initialize global station WCID

mt7603 uses a driver-private global station WCID for frames that have neither a station nor a vif, including frames injected through a monitor interface. Unlike the core global WCID initialized by mt76registerdevice(), this WCID is published without ever being passed to mt76wcidinit().

Since commit 0335c034e726 ("wifi: mt76: fix race condition related to checking tx queue fill status"), mt76tx() queues every such frame on the WCID's txpending or txoffchannel queue and links its txlist. The first injected frame therefore reaches skbqueuetail() with an uninitialized skbuffhead and dereferences a NULL prev pointer.

Initialize the WCID before publishing it.

The fix was tested on an MT7603 PCIe device. Three wildcard probe requests were injected through a monitor interface. The hardware queue head and tail advanced from 0 to 3 and a second radio captured the third request over the air. No oops or reset occurred. After restoring AP mode, a 150 MB transfer also completed without a reset.

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

wireguard: noise: reject response consumption after intermediate initiation

Two threads begin processing the identical response message, received twice. The first thread, A, runs. While it's running, the second one, B, gets partway through, and during that slow calculation, or even while blocking on downwrite(), A completes and then also a handshake initiation that's already been queued up runs in thread C, which itself takes that same downwrite(). The handshake initiation creation succeeds, and sets the state back to waiting-for-response, and calls upwrite(), at which point thread B resumes, because either its finished its calculations or was finally allowed to acquire downwrite(). Thread B then copies the state back to the peer, and begins a new session, using that state, which is the same session as the one made in thread A.

Thread A Thread B Thread C

downread() sA = handshake->state memcpy(cA, handshake->crypto) upread() if (sA != 1) goto fail slowcrypto(cA) downread() sB = handshake->state memcpy(cB, handshake->crypto) upread() if (sB != 1) goto fail slowcrypto(cB) downwrite() if (sA != handshake->state) goto fail memcpy(handshake->crypto, cA) handshake->state = 2 upwrite() downwrite() if (handshake->state != 2) goto fail derivesession(handshake->crypto) upwrite() downwrite() slowcrypto(handshake->crypto) handshake->state = 1 upwrite() downwrite() if (sB != handshake->state) goto fail memcpy(handshake->crypto, cB) handshake->state = 2 upwrite() downwrite() if (handshake->state != 2) goto fail derivesession(handshake->crypto) upwrite()

This seems basically impossible to hit in a meaningful way in practice, but ensure that it absolutely cannot happen by comparing the ephemeral private key that's on the stack with the latest one that the peer's handshake state has.

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

workqueue: Fix NULL currentpwq deref in chained work check

currentwqworker() only tells us that %current is a kworker. It does not guarantee that the worker is currently executing a work item, as worker->currentpwq is populated only while processonework() is running the work function.

ischainedwork() can be reached while queueing on a draining or destroying workqueue. If a kworker outside work-item execution reaches that path, currentwqworker() returns a worker but worker->currentpwq is NULL, and the chained-work test can fault before it emits the intended warning.

Guard the chained-work test with worker->currentpwq. A kworker without currentpwq is not executing work on the target workqueue, so the helper should return false and let the draining/destroying warning fire.