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

mm/hugememory: fix folio isn't locked in softleaftofolio()

On arm64 server, we found folio that get from migration entry isn't locked in softleaftofolio(). This issue triggers when mTHP splitting and zapnonpresentptes() races, and the root cause is lack of memory barrier in softleaftofolio(). The race is as follows:

CPU0 CPU1

deferredsplitscan() zapnonpresentptes() lock folio splitfolio() unmapfolio() change ptes to migration entries splitfoliotoorder() softleaftofolio() set flags(including PGlocked) for tail pages folio = pfnfolio(softleaftopfn(entry)) smpwmb() VMWARNONONCE(!foliotestlocked(folio)) prepcompoundpage() for tail pages

In splitfoliotoorder(), smpwmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smpwmb() should be paired with smprmb() in softleaftofolio(), which is missed. As a result, if zapnonpresentptes() accesses migration entry that stores tail pfn, softleaftofolio() may see the updated compoundhead of tail page before page->flags.

This issue will trigger VMWARNONONCE() in pfnswapentryfolio() because of the race between folio split and zapnonpresentptes() leading to a folio incorrectly undergoing modification without a folio lock being held.

This is a BUGON() before commit 93976a20345b ("mm: eliminate further swapops predicates"), which in merged in v6.19-rc1.

To fix it, add missing smprmb() if the softleaf entry is migration entry in softleaftofolio() and softleaftopage().

[tujinjiang@huawei.com: update function name and comments]

bpf: Free reuseport cBPF prog after RCU grace period.

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

netfilter: xtables: ensure names are nul-terminated

Reject names that lack a \0 character before feeding them to functions that expect c-strings.

Fixes tag is the most recent commit that needs this change.

dm-verity: disable recursive forward error correction

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

usb: gadget: renesasusb3: validate endpoint index in standard request handlers

The GETSTATUS and SET/CLEARFEATURE handlers extract the endpoint number from the host-supplied wIndex without any sort of validation. Fix this up by validating the number of endpoints actually match up with the number the device has before attempting to dereference a pointer based on this math.

This is just like what was done in commit ee0d382feb44 ("usb: gadget: aspeedudc: validate endpoint index for ast udc") for the aspeed driver.

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

drm/vc4: Fix memory leak of BO array in hang state

The hang state's BO array is allocated separately with kzalloc() in vc4savehangstate() but never freed in vc4freehangstate(). Add the missing kfree() for the BO array before freeing the hang state struct.

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

drm/vc4: Fix a memory leak in hang state error path

When vc4savehangstate() encounters an early return condition, it returns without freeing the previously allocated kernelstate, leaking memory.

Add the missing kfree() calls by consolidating the early return paths into a single place.

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

dm-verity: correctly handle dmbufioclientcreate() failure

If either of the calls to dmbufioclientcreate() in verityfecctr() fails, then dmbufioclientdestroy() is later called with an ERRPTR() argument. That causes a crash. Fix this.

A read-after-free memory flaw was found in the Linux kernel's garbage collection for Unix domain socket file handlers in the way users call close() and fget() simultaneously and can potentially trigger a race condition. This flaw allows a local user to crash the system or escalate their privileges on the system.

A flaw was found in the Linux kernel’s implementation of MIDI, where an attacker with a local account and the permissions to issue ioctl commands to midi devices could trigger a use-after-free issue. A write to this specific memory while freed and before use causes the flow of execution to change and possibly allow for memory corruption or privilege escalation. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.

DISPUTED In drivers/char/virtioconsole.c in the Linux kernel before 5.13.4, data corruption or loss can be triggered by an untrusted device that supplies a buf->len value exceeding the buffer size. NOTE: the vendor indicates that the cited data corruption is not a vulnerability in any existing use case; the length validation was added solely for robustness in the face of anomalous host OS behavior.

A flaw was found in the Linux kernels eBPF implementation. By default, accessing the eBPF verifier is only accessible to privileged users with CAPSYSADMIN. A local user with the ability to insert eBPF instructions can abuse a flaw in eBPF to corrupt memory. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.

A flaw was found in the "Routing decision" classifier in the Linux kernel's Traffic Control networking subsystem in the way it handled changing of classification filters, leading to a use-after-free condition. This flaw allows unprivileged local users to escalate their privileges on the system. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.

Last updated 25 April 2025

A use-after-free flaw was found in hcisendacl in the bluetooth host controller interface (HCI) in Linux kernel, where a local attacker with an access rights could cause a denial of service problem on the system The issue results from the object hchan, freed in hcidisconnloglinkcompleteevt, yet still used in other places. The highest threat from this vulnerability is to data integrity, confidentiality and system availability.

A flaw was discovered in processing setsockopt IPTSOSETREPLACE (or IP6TSOSETREPLACE) for 32 bit processes on 64 bit systems. This flaw will allow local user to gain privileges or cause a DoS through user name space. This action is usually restricted to root-privileged users but can also be leveraged if the kernel is compiled with CONFIGUSERNS and CONFIGNETNS and the user is granted elevated privileges.

.A flaw was found in the CAN BCM networking protocol in the Linux kernel, where a local attacker can abuse a flaw in the CAN subsystem to corrupt memory, crash the system or escalate privileges. This race condition in net/can/bcm.c in the Linux kernel allows for local privilege escalation to root.

In llcpsockbind/connect of llcpsock.c, there is a possible memory corruption due to a use after free. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

A flaw was found in Linux Kernel because access to the global variable fgconsole is not properly synchronized leading to a use after free in confontop.

A race condition was discovered in ext4writeinlinedataend in fs/ext4/inline.c in the ext4 subsystem in the Linux kernel through 5.13.13.

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

net/sched: teql: fix NULL pointer dereference in iptunnelxmit on TEQL slave xmit

teqlmasterxmit() calls netdevstartxmit(skb, slave) to transmit through slave devices, but does not update skb->dev to the slave device beforehand.

When a gretap tunnel is a TEQL slave, the transmit path reaches iptunnelxmit() which saves dev = skb->dev (still pointing to teql0 master) and later calls iptunnelxmitstats(dev, pktlen). This function does:

getcpuptr(dev->tstats)

Since teqlmastersetup() does not set dev->pcpustattype to NETDEVPCPUSTATTSTATS, the core network stack never allocates tstats for teql0, so dev->tstats is NULL. getcpuptr(NULL) computes NULL + percpuoffset[cpu], resulting in a page fault.

BUG: unable to handle page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI RIP: 0010:iptunnelxmit (./include/net/iptunnels.h:664 net/ipv4/iptunnelcore.c:89) Call Trace: <TASK> iptunnelxmit (net/ipv4/iptunnel.c:847) grexmit (net/ipv4/ipgre.c:478) gretapxmit (net/ipv4/ipgre.c:779) teqlmasterxmit (net/sched/schteql.c:319) devhardstartxmit (net/core/dev.c:3887) schdirectxmit (net/sched/schgeneric.c:347) devqueuexmit (net/core/dev.c:4802) neighdirectoutput (net/core/neighbour.c:1660) ipfinishoutput2 (net/ipv4/ipoutput.c:237) ipfinishoutput.part.0 (net/ipv4/ipoutput.c:315) ipmcoutput (net/ipv4/ipoutput.c:369) ipsendskb (net/ipv4/ipoutput.c:1508) udpsendskb (net/ipv4/udp.c:1195) udpsendmsg (net/ipv4/udp.c:1485) inetsendmsg (net/ipv4/afinet.c:859) syssendto (net/socket.c:2206)

Fix this by setting skb->dev = slave before calling netdevstartxmit(), so that tunnel xmit functions see the correct slave device with properly allocated tstats.

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

writeback: fix race between cgroupwritebackumount() and inodeswitchwbs()

When a container exits, the following BUGON() is occasionally triggered:

================================================================== VFS: Busy inodes after unmount of sdb (ext4) ------------[ cut here ]------------ kernel BUG at fs/super.c:695! CPU: 3 PID: 6 Comm: containerd-shim Tainted: G OE K 6.6 #1 pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : genericshutdownsuper+0xf0/0x100 lr : genericshutdownsuper+0xf0/0x100 Call trace: genericshutdownsuper+0xf0/0x100 killblocksuper+0x20/0x48 ext4killsb+0x28/0x60 deactivatelockedsuper+0x54/0x130 deactivatesuper+0x84/0xa0 cleanupmnt+0xa4/0x140 cleanupmnt+0x18/0x28 taskworkrun+0x78/0xe0 donotifyresume+0x204/0x240 ==================================================================

The root cause is a race between cgroupwritebackumount() and inodeswitchwbs()/cleanupofflinecgwb(). There is a window between inodepreparewbsswitch() returning true and the subsequent wbqueueisw() call. Following is the process that triggers the issue:

CPU A (umount) | CPU B (writeback) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ inodeswitchwbs/cleanupofflinecgwb atomicinc(&iswnrinflight) inodepreparewbsswitch -> passes SBACTIVE check iget(inode) genericshutdownsuper sb->sflags &= ~SBACTIVE cgroupwritebackumount(sb) smpmb() atomicread(&iswnrinflight) rcubarrier() -> no pending RCU callbacks flushworkqueue(iswwq) -> nothing queued, returns evictinodes(sb) -> Inode skipped as isw still holds a ref. sop->putsuper(sb) / destroys percpu counters / -> VFS: Busy inodes after unmount! wbqueueisw() queuework(iswwq, ...) / later in work function / inodeswitchwbsworkfn processinodeswitchwbs iput() -> evict percpucounterdec() // UAF!

Fix this by extending the RCU read-side critical section in inodeswitchwbs() and cleanupofflinecgwb() to cover from inodepreparewbsswitch() through wbqueueisw(). Since there is no sleep in this window, rcureadlock() can be used. Then add a synchronizercu() in cgroupwritebackumount() before the existing rcubarrier(), so that all in-flight switchers that have passed the SBACTIVE check have completed queuework() before flushworkqueue() is called.

The existing rcubarrier() is intentionally retained so this fix can be backported unchanged to stable kernels (5.10.y, 6.6.y, ...) that still queue switches via queuercuwork(). It is a no-op on current mainline (since commit e1b849cfa6b6 ("writeback: Avoid contention on wb->listlock when switching inodes")) and is removed in a follow-up patch.

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

ibmvnic: Use kernel helpers for hex dumps

Previously, when the driver was printing hex dumps, the buffer was cast to an 8 byte long and printed using string formatters. If the buffer size was not a multiple of 8 then a read buffer overflow was possible.

Therefore, create a new ibmvnic function that loops over a buffer and calls hexdumptobuffer instead.

This patch address KASAN reports like the one below: ibmvnic 30000003 env3: Login Buffer: ibmvnic 30000003 env3: 01000000af000000 <...> ibmvnic 30000003 env3: 2e6d62692e736261 ibmvnic 30000003 env3: 65050003006d6f63 ================================================================== BUG: KASAN: slab-out-of-bounds in ibmvniclogin+0xacc/0xffc [ibmvnic] Read of size 8 at addr c0000001331a9aa8 by task ip/17681 <...> Allocated by task 17681: <...> ibmvniclogin+0x2f0/0xffc [ibmvnic] ibmvnicopen+0x148/0x308 [ibmvnic] devopen+0x1ac/0x304 <...> The buggy address is located 168 bytes inside of allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf) <...> ================================================================= ibmvnic 30000003 env3: 000000000033766e

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

net/mlx5: Fix slab-out-of-bounds in mlx5querynicvportmaclist

mlx5querynicvportmaclist() sizes its firmware command buffer using the PF's logmaxcurrentuc/mclist capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer:

BUG: KASAN: slab-out-of-bounds in mlx5querynicvportmaclist+0x453/0x4c0 [mlx5core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385

CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5eswwq eswvportchangehandler [mlx5core] Call Trace: <TASK> dumpstacklvl+0x69/0xa0 printreport+0x176/0x4e4 kasanreport+0xc8/0x100 mlx5querynicvportmaclist+0x453/0x4c0 [mlx5core] eswupdatevportaddrlist+0x2e3/0xda0 [mlx5core] eswvportchangehandlelocked+0xa1f/0x1060 [mlx5core] eswvportchangehandler+0x6a/0x90 [mlx5core] processonework+0x87f/0x15e0 workerthread+0x62b/0x1020 kthread+0x375/0x490 retfromfork+0x4dc/0x810 retfromforkasm+0x11/0x20 </TASK>

Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.

drbd: Balance RCU calls in drbdadmdumpdevices()

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

clk: qcom: gfx3d: add parent to parent request map

After commit d228ece36345 ("clk: divider: remove roundrate() in favor of determinerate()") determining GFX3D clock rate crashes, because the passed parent map doesn't provide the expected bestparenthw clock (with the rounddrate path before the offending commit the bestparenthw was ignored).

Set the field in parentreq in addition to setting it in the req, fixing the crash.

clkhwroundrate (drivers/clk/clk.c:1764) (P) clkdividerbestdiv (drivers/clk/clk-divider.c:336) dividerdeterminerate (drivers/clk/clk-divider.c:358) clkalphapllpostdivdeterminerate (drivers/clk/qcom/clk-alpha-pll.c:1275) clkcoredetermineroundnolock (drivers/clk/clk.c:1606) clkcoreroundratenolock (drivers/clk/clk.c:1701) clkdeterminerate (drivers/clk/clk.c:1741) clkgfx3ddeterminerate (drivers/clk/qcom/clk-rcg2.c:1268) clkcoredetermineroundnolock (drivers/clk/clk.c:1606) clkcoreroundratenolock (drivers/clk/clk.c:1701) clkcoreroundratenolock (drivers/clk/clk.c:1710) clkroundrate (drivers/clk/clk.c:1804) devpmoppsetrate (drivers/opp/core.c:1440 (discriminator 1)) msmdevfreqtarget (drivers/gpu/drm/msm/msmgpudevfreq.c:51) devfreqsettarget (drivers/devfreq/devfreq.c:360) devfrequpdatetarget (drivers/devfreq/devfreq.c:426) devfreqmonitor (drivers/devfreq/devfreq.c:458) processonework (arch/arm64/include/asm/jumplabel.h:36 include/trace/events/workqueue.h:110 kernel/workqueue.c:3284) workerthread (kernel/workqueue.c:3356 (discriminator 2) kernel/workqueue.c:3443 (discriminator 2)) kthread (kernel/kthread.c:467) retfromfork (arch/arm64/kernel/entry.S:861)

crypto: atmel-aes - Fix 3-page memory leak in atmelaesbuffcleanup

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

drbd: add missing krefget in handlewriteconflicts

With two-primaries enabled, DRBD tries to detect "concurrent" writes and handle write conflicts, so that even if you write to the same sector simultaneously on both nodes, they end up with the identical data once the writes are completed.

In handling "superseeded" writes, we forgot a krefget, resulting in a premature drbddestroydevice and use after free, and further to kernel crashes with symptoms.

Relevance: No one should use DRBD as a random data generator, and apparently all users of "two-primaries" handle concurrent writes correctly on layer up. That is cluster file systems use some distributed lock manager, and live migration in virtualization environments stops writes on one node before starting writes on the other node.

Which means that other than for "test cases", this code path is never taken in real life.

FYI, in DRBD 9, things are handled differently nowadays. We still detect "write conflicts", but no longer try to be smart about them. We decided to disconnect hard instead: upper layers must not submit concurrent writes. If they do, that's their fault.

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

RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction

Upon RQ destruction if the firmware command fails which is the last resource to be destroyed some SW resources were already cleaned regardless of the failure.

Now properly rollback the object to its original state upon such failure.

In order to avoid a use-after free in case someone tries to destroy the object again, which results in the following kernel trace: refcountt: underflow; use-after-free. WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcountwarnsaturate+0xf4/0x148 Modules linked in: rdmaucm(OE) rdmacm(OE) iwcm(OE) ibipoib(OE) ibcm(OE) ibumad(OE) mlx5ib(OE) rfkill mlx5core(OE) mlxdevm(OE) ibuverbs(OE) ibcore(OE) psample mlxfw(OE) mlxcompat(OE) macsec tls pcihypervintf sunrpc vfat fat virtionet netfailover failover fuse loop nfnetlink vsockloopback vmwvsockvirtiotransportcommon vmwvsockvmcitransport vmwvmci vsock xfs crct10difce ghashce sha2ce sha256arm64 sha1ce virtioconsole virtiogpu virtioblk virtiodmabuf virtiommio dmmirror dmregionhash dmlog dmmod xpmem(OE) CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G OE ------- --- 6.12.0-54.el10.aarch64 #1 Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : refcountwarnsaturate+0xf4/0x148 lr : refcountwarnsaturate+0xf4/0x148 sp : ffff80008b81b7e0 x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001 x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00 x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000 x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006 x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37f x14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78 x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90 x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fff x5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600 Call trace: refcountwarnsaturate+0xf4/0x148 mlx5coreputrsc+0x88/0xa0 [mlx5ib] mlx5coredestroyrqtracked+0x64/0x98 [mlx5ib] mlx5ibdestroywq+0x34/0x80 [mlx5ib] ibdestroywquser+0x30/0xc0 [ibcore] uverbsfreewq+0x28/0x58 [ibuverbs] destroyhwidruobject+0x34/0x78 [ibuverbs] uverbsdestroyuobject+0x48/0x240 [ibuverbs] uverbscleanupufile+0xd4/0x1a8 [ibuverbs] uverbsdestroyufilehw+0x48/0x120 [ibuverbs] ibuverbsclose+0x2c/0x100 [ibuverbs] fput+0xd8/0x2f0 fputsync+0x50/0x70 arm64sysclose+0x40/0x90 invokesyscall.constprop.0+0x74/0xd0 doel0svc+0x48/0xe8 el0svc+0x44/0x1d0 el0t64synchandler+0x120/0x130 el0t64sync+0x1a4/0x1a8

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

net: stmmac: make sure that ptprate is not 0 before configuring timestamping

The stmmac platform drivers that do not open-code the clkptprate value after having retrieved the default one from the device-tree can end up with 0 in clkptprate (as clkgetrate can return 0). It will eventually propagate up to PTP initialization when bringing up the interface, leading to a divide by 0:

Division by zero in kernel. CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.30-00001-g48313bd5768a #22 Hardware name: STM32 (Device Tree Support) Call trace: unwindbacktrace from showstack+0x18/0x1c showstack from dumpstacklvl+0x6c/0x8c dumpstacklvl from Ldiv064+0x8/0x18 Ldiv064 from stmmacinittstampcounter+0x190/0x1a4 stmmacinittstampcounter from stmmachwsetup+0xc1c/0x111c stmmachwsetup from stmmacopen+0x18c/0x434 stmmacopen from stmmacopen+0x3c/0xbc stmmacopen from devopen+0xf4/0x1ac devopen from devchangeflags+0x1cc/0x224 devchangeflags from devchangeflags+0x24/0x60 devchangeflags from ipautoconfig+0x2e8/0x11a0 ipautoconfig from dooneinitcall+0x84/0x33c dooneinitcall from kernelinitfreeable+0x1b8/0x214 kernelinitfreeable from kernelinit+0x24/0x140 kernelinit from retfromfork+0x14/0x28 Exception stack(0xe0815fb0 to 0xe0815ff8)

Prevent this division by 0 by adding an explicit check and error log about the actual issue. While at it, remove the same check from stmmacptpregister, which then becomes duplicate