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

ntb: ntbhwswitchtec: Fix array-index-out-of-bounds access

Number of MW LUTs depends on NTB configuration and can be set to MAXMWS, This patch protects against invalid index out of bounds access to mwsizes When invalid access print message to user that configuration is not valid.

drm/amdgpu: prevent immediate PASID reuse case

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

ntb: ntbhwswitchtec: Fix shift-out-of-bounds for 0 mw lut

Number of MW LUTs depends on NTB configuration and can be set to zero, in such scenario rounddownpowoftwo will cause undefined behaviour and should not be performed. This patch ensures that rounddownpowoftwo is called on valid value.

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

netfilter: nfconntrackh323: fix OOB read in decodechoice()

In decodechoice(), the boundary check before getlen() uses the variable len, which is still 0 from its initialization at the top of the function:

unsigned int type, ext, len = 0; ... if (ext || (son->attr & OPEN)) { BYTEALIGN(bs); if (nfh323errorboundary(bs, len, 0)) / len is 0 here / return H323ERRORBOUND; len = getlen(bs); / OOB read /

When the bitstream is exactly consumed (bs->cur == bs->end), the check nfh323errorboundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent getlen() call then dereferences bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, getlen() reads a second byte as well.

This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nfconntrackh323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer.

Fix this by checking for 2 bytes (the maximum that getlen() may read) instead of the uninitialized len. This matches the pattern used at every other getlen() call site in the same file, where the caller checks for 2 bytes of available data before calling getlen().

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

ipv6: Fix soft lockups in fib6selectpath under high next hop churn

Soft lockups have been observed on a cluster of Linux-based edge routers located in a highly dynamic environment. Using the bird service, these routers continuously update BGP-advertised routes due to frequently changing nexthop destinations, while also managing significant IPv6 traffic. The lockups occur during the traversal of the multipath circular linked-list in the fib6selectpath function, particularly while iterating through the siblings in the list. The issue typically arises when the nodes of the linked list are unexpectedly deleted concurrently on a different core—indicated by their 'next' and 'previous' elements pointing back to the node itself and their reference count dropping to zero. This results in an infinite loop, leading to a soft lockup that triggers a system panic via the watchdog timer.

Apply RCU primitives in the problematic code sections to resolve the issue. Where necessary, update the references to fib6siblings to annotate or use the RCU APIs.

Include a test script that reproduces the issue. The script periodically updates the routing table while generating a heavy load of outgoing IPv6 traffic through multiple iperf3 clients. It consistently induces infinite soft lockups within a couple of minutes.

Kernel log:

0 [ffffbd13003e8d30] machinekexec at ffffffff8ceaf3eb 1 [ffffbd13003e8d90] crashkexec at ffffffff8d0120e3 2 [ffffbd13003e8e58] panic at ffffffff8cef65d4 3 [ffffbd13003e8ed8] watchdogtimerfn at ffffffff8d05cb03 4 [ffffbd13003e8f08] hrtimerrunqueues at ffffffff8cfec62f 5 [ffffbd13003e8f70] hrtimerinterrupt at ffffffff8cfed756 6 [ffffbd13003e8fd0] sysvecapictimerinterrupt at ffffffff8cea01af 7 [ffffbd13003e8ff0] sysvecapictimerinterrupt at ffffffff8df1b83d -- <IRQ stack> -- 8 [ffffbd13003d3708] asmsysvecapictimerinterrupt at ffffffff8e000ecb [exception RIP: fib6selectpath+299] RIP: ffffffff8ddafe7b RSP: ffffbd13003d37b8 RFLAGS: 00000287 RAX: ffff975850b43600 RBX: ffff975850b40200 RCX: 0000000000000000 RDX: 000000003fffffff RSI: 0000000051d383e4 RDI: ffff975850b43618 RBP: ffffbd13003d3800 R8: 0000000000000000 R9: ffff975850b40200 R10: 0000000000000000 R11: 0000000000000000 R12: ffffbd13003d3830 R13: ffff975850b436a8 R14: ffff975850b43600 R15: 0000000000000007 ORIGRAX: ffffffffffffffff CS: 0010 SS: 0018 9 [ffffbd13003d3808] ip6polroute at ffffffff8ddb030c 10 [ffffbd13003d3888] ip6polrouteinput at ffffffff8ddb068c 11 [ffffbd13003d3898] fib6rulelookup at ffffffff8ddf02b5 12 [ffffbd13003d3928] ip6routeinput at ffffffff8ddb0f47 13 [ffffbd13003d3a18] ip6rcvfinishcore.constprop.0 at ffffffff8dd950d0 14 [ffffbd13003d3a30] ip6listrcvfinish.constprop.0 at ffffffff8dd96274 15 [ffffbd13003d3a98] ip6sublistrcv at ffffffff8dd96474 16 [ffffbd13003d3af8] ipv6listrcv at ffffffff8dd96615 17 [ffffbd13003d3b60] netifreceiveskblistcore at ffffffff8dc16fec 18 [ffffbd13003d3be0] netifreceiveskblistinternal at ffffffff8dc176b3 19 [ffffbd13003d3c50] napigroreceive at ffffffff8dc565b9 20 [ffffbd13003d3c80] icereceiveskb at ffffffffc087e4f5 [ice] 21 [ffffbd13003d3c90] icecleanrxirq at ffffffffc0881b80 [ice] 22 [ffffbd13003d3d20] icenapipoll at ffffffffc088232f [ice] 23 [ffffbd13003d3d80] napipoll at ffffffff8dc18000 24 [ffffbd13003d3db8] netrxaction at ffffffff8dc18581 25 [ffffbd13003d3e40] dosoftirq at ffffffff8df352e9 26 [ffffbd13003d3eb0] runksoftirqd at ffffffff8ceffe47 27 [ffffbd13003d3ec0] smpbootthreadfn at ffffffff8cf36a30 28 [ffffbd13003d3ee8] kthread at ffffffff8cf2b39f 29 [ffffbd13003d3f28] retfromfork at ffffffff8ce5fa64 30 [ffffbd13003d3f50] retfromforkasm at ffffffff8ce03cbb

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

dmaengine: stm32: dmamux: fix device leak on route allocation

Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation.

Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.

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

f2fs: bound iinlinexattrsize for non-inline-xattr inodes

When the flexibleinlinexattr feature is enabled, doreadinode() loads the on-disk iinlinexattrsize unconditionally:

if (f2fssbhasflexibleinlinexattr(sbi)) fi->iinlinexattrsize = le16tocpu(ri->iinlinexattrsize);

but sanitycheckinode() only range-checks it when the inode also has the FIINLINEXATTR flag set. An inode that carries an inline dentry or inline data but not FIINLINEXATTR -- the normal layout for an inline directory -- therefore keeps a fully attacker-controlled iinlinexattrsize from a crafted image.

getinlinexattraddrs() returns that value with no flag gating, so it feeds the inode geometry:

MAXINLINEDATA() = 4 (CURADDRSPERINODE - iinlinexattrsize - 1) NRINLINEDENTRY() = MAXINLINEDATA() BITSPERBYTE / (...) addrsperpage() = CURADDRSPERINODE - iinlinexattrsize

A large iinlinexattrsize drives MAXINLINEDATA() and NRINLINEDENTRY() negative, so makedentryptrinline() sets d->max (int) to a negative value. The inline directory walk then compares an unsigned long bitpos against that negative d->max, which is promoted to a huge unsigned bound, and reads far past the inline area:

while (bitpos < d->max) / fs/f2fs/dir.c / ... testbitle(bitpos, d->bitmap) / d->dentry[bitpos] ...

Mounting a crafted image and reading such a directory triggers an out-of-bounds read in f2fsfilldentries(); the same underflow also corrupts ADDRSPERINODE for regular files.

Validate iinlinexattrsize against MAXINLINEXATTRSIZE whenever the flexibleinlinexattr feature is enabled -- i.e. whenever the value is loaded from disk and consumed -- and keep the lower MININLINEXATTRSIZE bound gated on inodes that actually carry an inline xattr, so legitimate inodes with iinlinexattrsize == 0 are still accepted.

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

bridge: brndsend: validate ND option lengths

brndsend() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload.

Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.

bridge: brndsend: linearize skb before parsing ND options

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

net/sched: actife: Fix metalist update behavior

Whenever an ife action replace changes the metalist, instead of replacing the old data on the metalist, the current ife code is appending the new metadata. Aside from being innapropriate behavior, this may lead to an unbounded addition of metadata to the metalist which might cause an out of bounds error when running the encode op:

[ 138.423369][ C1] ================================================================== [ 138.424317][ C1] BUG: KASAN: slab-out-of-bounds in ifetlvmetaencode (net/ife/ife.c:168) [ 138.424906][ C1] Write of size 4 at addr ffff8880077f4ffe by task ifeoutoutbou/255 [ 138.425778][ C1] CPU: 1 UID: 0 PID: 255 Comm: ifeoutoutbou Not tainted 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(full) [ 138.425795][ C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 138.425800][ C1] Call Trace: [ 138.425804][ C1] <IRQ> [ 138.425808][ C1] dumpstacklvl (lib/dumpstack.c:122) [ 138.425828][ C1] printreport (mm/kasan/report.c:379 mm/kasan/report.c:482) [ 138.425839][ C1] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 138.425844][ C1] ? virtaddrvalid (./arch/x86/include/asm/preempt.h:95 (discriminator 1) ./include/linux/rcupdate.h:975 (discriminator 1) ./include/linux/mmzone.h:2207 (discriminator 1) arch/x86/mm/physaddr.c:54 (discriminator 1)) [ 138.425853][ C1] ? ifetlvmetaencode (net/ife/ife.c:168) [ 138.425859][ C1] kasanreport (mm/kasan/report.c:221 mm/kasan/report.c:597) [ 138.425868][ C1] ? ifetlvmetaencode (net/ife/ife.c:168) [ 138.425878][ C1] kasancheckrange (mm/kasan/generic.c:186 (discriminator 1) mm/kasan/generic.c:200 (discriminator 1)) [ 138.425884][ C1] asanmemset (mm/kasan/shadow.c:84 (discriminator 2)) [ 138.425889][ C1] ifetlvmetaencode (net/ife/ife.c:168) [ 138.425893][ C1] ? ifetlvmetaencode (net/ife/ife.c:171) [ 138.425898][ C1] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 138.425903][ C1] ifeencodemetau16 (net/sched/actife.c:57) [ 138.425910][ C1] ? pfxdorawspinlock (kernel/locking/spinlockdebug.c:114) [ 138.425916][ C1] ? asanmemcpy (mm/kasan/shadow.c:105 (discriminator 3)) [ 138.425921][ C1] ? pfxifeencodemetau16 (net/sched/actife.c:45) [ 138.425927][ C1] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 138.425931][ C1] tcfifeact (net/sched/actife.c:847 net/sched/actife.c:879)

To solve this issue, fix the replace behavior by adding the metalist to the ife rcu data structure.

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

net/sched: clsflow: fix NULL pointer dereference on shared blocks

flowchange() calls tcfblockq() and dereferences q->handle to derive a default baseclass. Shared blocks leave block->q NULL, causing a NULL deref when a flow filter without a fully qualified baseclass is created on a shared block.

Check tcfblockshared() before accessing block->q and return -EINVAL for shared blocks. This avoids the null-deref shown below:

======================================================================= KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:flowchange (net/sched/clsflow.c:508) Call Trace: tcnewtfilter (net/sched/clsapi.c:2432) rtnetlinkrcvmsg (net/core/rtnetlink.c:6980) [...] =======================================================================

HID: alps: fix NULL pointer dereference in alpsrawevent()

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

xfrm: hold dev ref until after transportfinish NFHOOK

After async crypto completes, xfrminputresume() calls devput() immediately on re-entry before the skb reaches transportfinish. The skb->dev pointer is then used inside NFHOOK and its okfn, which can race with device teardown.

Remove the devput from the async resumption entry and instead drop the reference after the NFHOOK call in transportfinish, using a saved device pointer since NFHOOK may consume the skb. This covers NFDROP, NFQUEUE and NFSTOLEN paths that skip the okfn.

For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.

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

tipc: fix bcackers underflow on duplicate GRPACKMSG

The GRPACKMSG handler in tipcgroupprotorcv() currently decrements bcackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round.

Because bcackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipcgroupbccong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated.

Fix this by ignoring duplicate or stale ACKs before touching bcacked or bcackers. This makes repeated GRPACKMSG handling idempotent and prevents the underflow path.

A use-after-free exists in drivers/tee/teeshm.c in the TEE subsystem in the Linux kernel through 5.15.11. This occurs because of a race condition in teeshmgetfromid during an attempt to free a shared memory object.

A remote stack overflow in the TIPC networking module. With FORTIFYSOURCE's stricter memcpy() bounds checking, this can be exploited to cause remote DOS via kernel panic on systems using TIPC. Prior to these bounds checks, and with a canary leak (or no CONFIGSTACKPROTECTOR), this can be exploited for RCE.

Reference: https://www.openwall.com/lists/oss-security/2022/02/10/1

A vulnerability was found in cgroupreleaseagentwrite in kernel/cgroup/cgroup-v1.c in the Linux kernel. In this flaw, under certain circumstances, the cgroups v1 releaseagent feature can be used to escalate privilege and bypass namespace isolation unexpectedly.

Upstream Commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=24f6008564183aa120d07c03d9289519c2fe02af

A flaw in the Linux Kernel found. If unprivileged users can mount FUSE filesystems, then can trigger use after free (UAF) that reads of write() buffers, allowing theft of (partial) /etc/shadow hashes or any other data from filesystem.

FUSE allows the userspace filesystem to specify on FUSEOPEN whether the file should use the normal kernel pagecache for handling read()/write() or just send FUSEREAD/FUSEWRITE requests directly to the userspace filesystem (using the flag FOPENDIRECTIO in fuseopenout::openflags).

In FOPENDIRECTIO mode, fusefilewriteiter() calls fusedirectwriteiter(), which normally calls fusedirectio(), which then imports the write buffer with fusegetuserpages(), which uses iovitergetpages() to grab references to userspace pages instead of actually copying memory.

On the filesystem device side, these pages can then either be read to userspace (via fusedevread()), or splice()d over into a pipe using fusedevspliceread() as pipe buffers with &nostealpipebufops.

This is wrong because after fusedevdoread() unlocks the FUSE request, the userspace filesystem can mark the request as completed, causing write() to return. At that point, the write buffer may be reused for other purposes, and the userspace filesystem should no longer have access to it.

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.

An out-of-bounds (OOB) memory write flaw was found in preallocelemsandfreelist in kernel/bpf/stackmap.c in the bpf iin the Linux kernel. In this flaw, the multiplication to calculate the size could lead to an integer overflow, and this could allow a local attacker, with a special user privilege to gain access to out-of-bounds memory leading to a system crash or a leak of internal kernel information.

Reference and upstream patch: https://github.com/torvalds/linux/commit/30e29a9a2bc6a4888335a6ede968b75cd329657a

A heap buffer overflow flaw was found in IPsec ESP transformation code in net/ipv4/esp4.c and net/ipv6/esp6.c. This flaw allows a local attacker with a normal user privilege to overwrite kernel heap objects and may cause a local privilege escalation threat.

A use-after-free flaw was found in u32change in net/sched/clsu32.c in the network subcomponent of the Linux kernel. This flaw could allow a local attacker to crash the system and cause a privilege escalation, and a kernel information leak problem.

References and upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3db09e762dc79584a69c10d74a6b98f89a9979f8 https://kernel.dance/#3db09e762dc79584a69c10d74a6b98f89a9979f8

A use after free vulnerability exists in the ALSA PCM package in the Linux Kernel. SNDRVCTLIOCTLELEM{READ|WRITE}32 is missing locks that can be used in a use-after-free that can result in a priviledge escalation to gain ring0 access from the system user. We recommend upgrading past commit 56b88b50565cd8b946a2d00b0c83927b7ebb055e

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.