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

md raid: fix hang when stopping arrays with metadata through dm-raid

When using device-mapper's dm-raid target, stopping a RAID array can cause the system to hang under specific conditions.

This occurs when:

- A dm-raid managed device tree is suspended from top to bottom (the top-level RAID device is suspended first, followed by its underlying metadata and data devices)

- The top-level RAID device is then removed

Removing the top-level device triggers a hang in the following sequence: the dm-raid destructor calls mdstop(), which tries to flush the write-intent bitmap by writing to the metadata sub-devices. However, these devices are already suspended, making them unable to complete the write-intent operations and causing an indefinite block.

Fix:

- Prevent bitmap flushing when mdstop() is called from dm-raid destructor context and avoid a quiescing/unquescing cycle which could also cause I/O

- Still allow write-intent bitmap flushing when called from dm-raid suspend context

This ensures that RAID array teardown can complete successfully even when the underlying devices are in a suspended state.

This second patch uses mdisrdwr() to distinguish between suspend and destructor paths as elaborated on above.

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

x86/kexec: add a sanity check on previous kernel's ima kexec buffer

When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic.

BUG: unable to handle page fault for address: ffff97793ff47000 RIP: imarestoremeasurementlist+0xdc/0x45a #PF: errorcode(0x0000) – not-present page

Other architectures already validate the range with pageisram(), as done in commit cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86.

Without carrying the measurement list across kexec, the attestation would fail.

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

net/mlx5: Fix deadlock between devlink lock and esw->wq

esw->workqueue executes eswfunctionschangedeventhandler -> eswvfschangedeventhandler and acquires the devlink lock.

.eswitchmodeset (acquires devlink lock in devlinknlpredoit) -> mlx5devlinkeswitchmodeset -> mlx5eswitchdisablelocked -> mlx5eswitcheventhandlerunregister -> flushworkqueue deadlocks when eswvfschangedeventhandler executes.

Fix that by no longer flushing the work to avoid the deadlock, and using a generation counter to keep track of work relevance. This avoids an old handler manipulating an esw that has undergone one or more mode changes: - the counter is incremented in mlx5eswitcheventhandlerunregister. - the counter is read and passed to the ephemeral mlx5hostwork struct. - the work handler takes the devlink lock and bails out if the current generation is different than the one it was scheduled to operate on. - mlx5eswitchcleanup does the final draining before destroying the wq.

No longer flushing the workqueue has the side effect of maybe no longer cancelling pending vportchangehandler work items, but that's ok since those are disabled elsewhere: - mlx5eswitchdisablelocked disables the vport eq notifier. - mlx5eswvportdisable disarms the HW EQ notification and marks vport->enabled under statelock to false to prevent pending vport handler from doing anything. - mlx5eswitchcleanup destroys the workqueue and makes sure all events are disabled/finished.

drm/amdgpu: Fix fence put before wait in amdgpuamdkfdsubmitib

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

PCI: endpoint: pci-epf-vntb: Stop cmdhandler work in epfntbepccleanup

Disable the delayed work before clearing BAR mappings and doorbells to avoid running the handler after resources have been torn down.

Unable to handle kernel paging request at virtual address ffff800083f46004 [...] Internal error: Oops: 0000000096000007 [#1] SMP [...] Call trace: epfntbcmdhandler+0x54/0x200 [pciepfvntb] (P) processonework+0x154/0x3b0 workerthread+0x2c8/0x400 kthread+0x148/0x210 retfromfork+0x10/0x20

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

PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown

epfntbepcdestroy() duplicates the teardown that the caller is supposed to perform later. This leads to an oops when .allowlink fails or when .droplink is performed. The following is an example oops of the former case:

Unable to handle kernel paging request at virtual address dead000000000108 [...] [dead000000000108] address between user and kernel address ranges Internal error: Oops: 0000000096000044 [#1] SMP [...] Call trace: pciepcremoveepf+0x78/0xe0 (P) pciprimaryepcepflink+0x88/0xa8 configfssymlink+0x1f4/0x5a0 vfssymlink+0x134/0x1d8 dosymlinkat+0x88/0x138 arm64syssymlinkat+0x74/0xe0 [...]

Remove the helper, and drop pciepcput(). EPC device refcounting is tied to the configfs EPC group lifetime, and pciepcput() in the .droplink path is sufficient.

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

net: ethernet: mtk-star-emac: fix spinlock recursion issues on rx/tx poll

Use spinlockirqsave and spinunlockirqrestore instead of spinlock and spinunlock in mtkstaremac driver to avoid spinlock recursion occurrence that can happen when enabling the DMA interrupts again in rx/tx poll.

BUG: spinlock recursion on CPU#0, swapper/0/0 lock: 0xffff00000db9cf20, .magic: dead4ead, .owner: swapper/0/0, .ownercpu: 0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.15.0-rc2-next-20250417-00001-gf6a27738686c-dirty #28 PREEMPT Hardware name: MediaTek MT8365 Open Platform EVK (DT) Call trace: showstack+0x18/0x24 (C) dumpstacklvl+0x60/0x80 dumpstack+0x18/0x24 spindump+0x78/0x88 dorawspinlock+0x11c/0x120 rawspinlock+0x20/0x2c mtkstarhandleirq+0xc0/0x22c [mtkstaremac] handleirqeventpercpu+0x48/0x140 handleirqevent+0x4c/0xb0 handlefasteoiirq+0xa0/0x1bc handleirqdesc+0x34/0x58 generichandledomainirq+0x1c/0x28 gichandleirq+0x4c/0x120 dointerrupthandler+0x50/0x84 el1interrupt+0x34/0x68 el1h64irqhandler+0x18/0x24 el1h64irq+0x6c/0x70 regmapmmioread32le+0xc/0x20 (P) regmapbusregread+0x6c/0xac regmapread+0x60/0xdc regmapread+0x4c/0x80 mtkstarrxpoll+0x2f4/0x39c [mtkstaremac] napipoll+0x38/0x188 netrxaction+0x164/0x2c0 handlesoftirqs+0x100/0x244 dosoftirq+0x14/0x20 dosoftirq+0x10/0x20 callonirqstack+0x24/0x64 dosoftirqownstack+0x1c/0x40 irqexitrcu+0xd4/0x10c irqexitrcu+0x10/0x1c el1interrupt+0x38/0x68 el1h64irqhandler+0x18/0x24 el1h64irq+0x6c/0x70 cpuidleenterstate+0xac/0x320 (P) cpuidleenter+0x38/0x50 doidle+0x1e4/0x260 cpustartupentry+0x34/0x3c restinit+0xdc/0xe0 consoleonrootfs+0x0/0x6c primaryswitched+0x88/0x90

bpf: Fix a UAF issue in bpftrampolinelinkcgroupshim

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

remoteproc: core: Fix idafree call while not allocated

In the rprocalloc() function, on error, putdevice(&rproc->dev) is called, leading to the call of the rproctyperelease() function. An error can occurs before idaalloc is called.

In such case in rproctyperelease(), the condition (rproc->index >= 0) is true as rproc->index has been initialized to 0. idafree() is called reporting a warning: [ 4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 idafree+0x100/0x164 [ 4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0 [ 4.188854] idafree called for id=0 which is not allocated. [ 4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000 [ 4.203556] Modules linked in: panelorisetechotm8009a dwmipidsistm(+) gpusched dwmipidsi stm32rproc stm32crc32 stm32ipcc(+) optee(+) [ 4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442 [ 4.231481] Hardware name: STM32 (Device Tree Support) [ 4.236627] Workqueue: eventsunbound deferredprobeworkfunc [ 4.242504] Call trace: [ 4.242522] unwindbacktrace from showstack+0x10/0x14 [ 4.250218] showstack from dumpstacklvl+0x50/0x64 [ 4.255274] dumpstacklvl from warn+0x80/0x12c [ 4.260134] warn from warnslowpathfmt+0x114/0x188 [ 4.265199] warnslowpathfmt from idafree+0x100/0x164 [ 4.270565] idafree from rproctyperelease+0x38/0x60 [ 4.275832] rproctyperelease from devicerelease+0x30/0xa0 [ 4.281601] devicerelease from kobjectput+0xc4/0x294 [ 4.286762] kobjectput from rprocalloc.part.0+0x208/0x28c [ 4.292430] rprocalloc.part.0 from devmrprocalloc+0x80/0xc4 [ 4.298393] devmrprocalloc from stm32rprocprobe+0xd0/0x844 [stm32rproc] [ 4.305575] stm32rprocprobe [stm32rproc] from platformprobe+0x5c/0xbc

Calling idaalloc earlier in rprocalloc ensures that the rproc->index is properly set.

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

Input: mtk-pmic-keys - fix possible null pointer dereference

In mtkpmickeysprobe, the regs parameter is only set if the button is parsed in the device tree. However, on hardware where the button is left floating, that node will most likely be removed not to enable that input. In that case the code will try to dereference a null pointer.

Let's use the regs struct instead as it is defined for all supported platforms. Note that it is ok setting the key reg even if that latter is disabled as the interrupt won't be enabled anyway.

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

net: ethernet: mtkethsoc: Reset prog ptr to oldprog in case of error in mtkxdpsetup()

Reset eBPF program pointer to oldprog and do not decrease its ref-count if mtkopen routine in mtkxdpsetup() fails.

flowdissector: do not dissect PPPoE PFC frames

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

net: gro: don't merge zcopy skbs

skbgroreceive() can currently copy frags between the source and GRO skb, without checking the zerocopy status, and in particular the SKBFLMANAGEDFRAGREFS flag.

When SKBFLMANAGEDFRAGREFS is set, the skb doesn't hold a reference on the pages in shinfo->frags. Appending those frags to another skb's frags without fixing up the page refcount can lead to UAF.

When either the last skb in the GRO chain (the one we would append frags to) or the source skb is zerocopy, don't merge the skbs.

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

spi: fix use-after-free on controller registration failure

Make sure to deregister from driver core also in the unlikely event that per-cpu statistics allocation fails during controller registration to avoid use-after-free (of driver resources) and unclocked register accesses.

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

PCI: brcmstb: Fix error path after a call to regulatorbulkget()

If the regulatorbulkget() returns an error and no regulators are created, we need to set their number to zero.

If we don't do this and the PCIe link up fails, a call to the regulatorbulkfree() will result in a kernel panic.

While at it, print the error value, as we cannot return an error upwards as the kernel will WARN() on an error from addbus().

[kwilczynski: commit log, use comma in the message to match style with other similar messages]

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

ima: verify the previous kernel's IMA buffer lies in addressable RAM

Patch series "Address page fault in imarestoremeasurementlist()", v3.

When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>" we observe a pafe fault that happens.

BUG: unable to handle page fault for address: ffff97793ff47000 RIP: imarestoremeasurementlist+0xdc/0x45a #PF: errorcode(0x0000) not-present page

This happens on x8664 only, as this is already fixed in aarch64 in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds")

This patch (of 3):

When the second-stage kernel is booted with a limiting command line (e.g. "mem=<size>"), the IMA measurement buffer handed over from the previous kernel may fall outside the addressable RAM of the new kernel. Accessing such a buffer can fault during early restore.

Introduce a small generic helper, imavalidaterange(), which verifies that a physical [start, end] range for the previous-kernel IMA buffer lies within addressable memory: - On x86, use pfnrangeismapped(). - On OF based architectures, use pageisram().

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

cifs: Fix locking usage for tcon fields

We used to use the cifstcpseslock to protect a lot of objects that are not just the server, ses or tcon lists. We later introduced srvlock, seslock and tclock to protect fields within the corresponding structs. This was done to provide a more granular protection and avoid unnecessary serialization.

There were still a couple of uses of cifstcpseslock to provide tcon fields. In this patch, I've replaced them with tclock.

f2fs: compress: fix UAF of f2fsinodeinfo in f2fsfreedic

cifs: Fix integer overflow while processing closetimeo mount option

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

spi: fix statistics allocation

The controller per-cpu statistics is not allocated until after the controller has been registered with driver core, which leaves a window where accessing the sysfs attributes can trigger a NULL-pointer dereference.

Fix this by moving the statistics allocation to controller allocation while tying its lifetime to that of the controller (rather than using implicit devres).

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

ksmbd: rate limit unmapped SID errors

A client can include many structurally valid but unmapped SIDs in a DACL. Logging every mapping failure lets one request generate hundreds of kernel error messages.

Rate limit the message to prevent an authenticated client from flooding the kernel log.

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

mm: shrinker: fix NULL pointer dereference in debugfs

shrinkerdebugfsadd() creates both "count" and "scan" debugfs files unconditionally.

That assumes every shrinker implements both countobjects() and scanobjects(), which is not guaranteed. For example, the xen-backend shrinker sets countobjects() but leaves scanobjects() NULL, so writing to its scan file calls through a NULL function pointer and panics the kernel:

BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. Call Trace: <TASK> shrinkerdebugfsscanwrite+0x12e/0x270 fullproxywrite+0x5f/0x90 vfswrite+0xde/0x420 ? filpflush+0x75/0x90 ? filpclose+0x1d/0x30 ? dodup2+0xb8/0x120 ksyswrite+0x68/0xf0 ? filpflush+0x75/0x90 dosyscall64+0xb3/0x5b0 entrySYSCALL64afterhwframe+0x76/0x7e

The count path has the same issue in principle if a shrinker omits countobjects().

To fix it, only create "count" and "scan" debugfs files when the corresponding callbacks are present.

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

udp: clear skb->dev before running a sockmap verdict

On the UDP receive path skb->dev is repurposed as devscratch (the truesize/state cache set by udpsetdevscratch()), through the union { struct netdevice dev; unsigned long devscratch; } in skbuff.

When a UDP socket is in a sockmap, skdataready is skpsockverdictdataready(), which calls udpreadskb() -> recvactor() (skpsockverdictrecv) to run the attached SKSKB verdict program in softirq. If that program calls a socket-lookup helper (bpfsklookuptcp/udp, bpfskclookuptcp), bpfskclookup() does:

if (skb->dev) callernet = devnet(skb->dev);

skb->dev still holds the devscratch value (a non-NULL integer), so devnet() dereferences it as a struct netdevice and the kernel takes a general protection fault on a non-canonical address in softirq:

Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpfskclookup net/core/filter.c:7033 [inline] RIP: 0010:bpfsklookup+0x45/0x160 net/core/filter.c:7047 Call Trace: <IRQ> bpfprog4675cb904b7071f8+0x12e/0x14e bpfprogrunpinoncpu+0xc6/0x1f0 skpsockverdictrecv+0x1ba/0x350 udpreadskb+0x31a/0x370 skpsockverdictdataready+0x2e3/0x600 udpenqueuescheduleskb+0x4c8/0x650 udpv6queuercvoneskb+0x3ec/0x740 udp6unicastrcvskb+0x11d/0x140 ip6protocoldeliverrcu+0x61e/0x950 ip6inputfinish+0xa9/0x150 NFHOOK+0x286/0x2f0 ip6input+0x117/0x220 NFHOOK+0x286/0x2f0 netifreceiveskb+0x85/0x200 processbacklog+0x374/0x9a0 napipoll+0x4f/0x1c0 netrxaction+0x3b0/0x770 handlesoftirqs+0x15a/0x460 dosoftirq+0x57/0x80 </IRQ>

The rmem charge that devscratch accounted for is released by skbrecvudp() on dequeue, just above, so the scratch is dead by the time recvactor() runs. Clear skb->dev so bpfskclookup() falls back to socknet(skb->sk), which skbsetownersksafe() set just above.

In ip6appenddata(), when the paged-allocation branch is taken (MSGMORE / NETIFFSG / large fraglen), alloclen and pagedlen are computed as

alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen;

datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skbsharedinfo.

An unprivileged user can trigger this via a UDPv6 socket using MSGMORE together with MSGSPLICEPAGES.

The bad accounting was introduced by commit 773ba4fe9104 ("ipv6: avoid partial copy for zc"). Before commit ce650a166335 ("udp6: Fix ip6appenddata()'s handling of MSGSPLICEPAGES"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSGSPLICEPAGES to proceed in this case, making the corruption triggerable.

The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen.

After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSGSPLICEPAGES case, remove the MSGSPLICEPAGES exception from the negative copy check.

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

mm/shrinker: do not hold RCU lock in shrinkerdebugfscountshow()

Reading the debugfs "count" file of a memcg-aware shrinker can sleep inside an RCU read-side critical section:

BUG: sleeping function called from invalid context at kernel/cgroup/rstat.c:421 RCU nest depth: 1, expected: 0 cssrstatflush memcgroupflushstats zswapshrinkercount shrinkerdebugfscountshow

shrinkerdebugfscountshow() invokes the ->countobjects() callback under rcureadlock(). The zswap callback flushes memcg stats via cssrstatflush(), which may sleep, so it must not run under RCU.

The RCU lock is not needed here. memcgroupiter() takes RCU internally and returns a memcg holding a css reference (dropped on the next iteration or by memcgroupiterbreak()), so the memcg stays alive without it. The shrinker is kept alive by the open debugfs file: shrinkerfree() removes the debugfs entries via debugfsremoverecursive(), which waits for in-flight readers to drain, before callrcu(..., shrinkerfreercucb). The sibling "scan" handler already invokes the sleeping ->scanobjects() callback with no RCU section.

Drop the rcureadlock()/rcureadunlock().

btrfs: do not force reloc root creation during qgroupaccountsnapshot()

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

arm64: io: Extract user memory type in ioremapprot()

The only caller of ioremapprot() outside of the generic ioremap() implementation is genericaccessphys(), which passes a 'pgprott' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprott' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremapprot() which faults when accessed from the kernel on systems with PAN:

| Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | memcpyfromio+0x80/0xf8 | genericaccessphys+0x20c/0x2b8 | accessremotevm+0x46c/0x5b8 | accessremotevm+0x18/0x30 | environread+0x238/0x3e8 | vfsread+0xe4/0x2b0 | ksysread+0xcc/0x178 | arm64sysread+0x4c/0x68

Extract only the memory type from the user 'pgprott' in ioremapprot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps ioremapprot().

9p: avoid putting oldfid in p9clientwalk() error path

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

nvmet-auth: validate reply message payload bounds against transfer length

nvmetauthreply() accesses the variable-length rval[] array using attacker-controlled hl (hash length) and dhvlen (DH value length) fields without verifying they fit within the allocated buffer of tl bytes.

A malicious NVMe-oF initiator can craft a DHCHAPREPLY message with a small transfer length but large hl/dhvlen values, causing out-of-bounds heap reads when the target processes the DH public key (rval + 2hl) or performs the host response memcmp.

With DH authentication configured, the OOB pointer is passed directly to sginitone() and read by cryptokppcomputesharedsecret(), reaching up to 526 bytes past the buffer. This is exploitable pre-authentication.

Add bounds validation ensuring sizeof(data) + 2hl + dhvlen <= tl before any access to the variable-length fields.

Discovered by Atuin - Automated Vulnerability Discovery Engine.

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

ipv6: sr: restore network header before routing and forwarding

ipv6srhrcv() runs with skb->data at the Segment Routing Header (SRH) while skbnetworkheader() points at the IPv6 header.

When segmentsleft > 0, ipv6srhrcv() previously restored the skb->data position by pushing sizeof(struct ipv6hdr), assuming the SRH immediately followed the fixed IPv6 header. If another extension header (such as a Hop-by-Hop options header) precedes the SRH, skbnetworkoffset() remained negative.

This led to two problems: 1. During ip6routeinput(), fib6rulesearlyflowdissect() invokes skbflowdissect() which passes the negative skbnetworkoffset() to flow dissection, breaking BPF and C flow dissector logic. 2. If forwarded via ip6forward() or redirected via actmirred, downstream handlers (like schfragment() or neighbour output) pass the negative offset as an unsigned length, triggering OOB memcpy or buffer overflows.

Fix this by pushing -skbnetworkoffset(skb) before routing, ensuring skbnetworkoffset(skb) is 0 for route lookup / flow dissection as well as downstream forwarding. On the loopback path, pull skbtransportoffset(skb) to restore skb->data to the SRH before looping back.