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

crypto: caam - use printhexdumpdevel to guard key hex dumps

Use printhexdumpdevel() for dumping sensitive key material in setkey() to avoid leaking secrets at runtime when CONFIGDYNAMICDEBUG is enabled.

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.

Last updated 25 April 2025

An out-of-bounds (OOB) memory access flaw was found in fs/f2fs/node.c in the f2fs module in the Linux kernel in versions before 5.12.0-rc4. A bounds check failure allows a local attacker to gain access to out-of-bounds memory leading to a system crash or a leak of internal kernel information. The highest threat from this vulnerability is to system availability.

A NULL pointer dereference flaw was found in btrfsrmdevice function in fs/btrfs/volumes.c in Linux Kernel, where triggering the bug requires ‘CAPSYSADMIN’. This could allow a local attacker to crash the system or leak kernel internal information.

References: https://lore.kernel.org/linux-btrfs/CAFcO6XO5TC5sEo-C9JGC75JkNAzkOSSLA3a=bwQqXFFbRTZ7Gw@mail.gmail.com/T/#md4b850f33616b7364f86e6fed144abc925f3669c https://lore.kernel.org/linux-btrfs/20210806102415.304717-1-wqu@suse.com/T/#u

An out of bounds (OOB) memory access flaw was found in the Linux kernel in relayfilereadstartpos in kernel/relay.c in the relayfs. This flaw could allow a local attacker to crash the system or leak kernel internal information.

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

netfilter: ipset: fix race between dump and ipsetlist resize

The release path of ipsetdumpdo() and ipsetdumpdone() read inst->ipsetlist via ipsetrefnetlink(), a plain rcudereferenceraw() of the array pointer. These run from netlinkrecvmsg() without the nfnl mutex and without an RCU read-side critical section.

A concurrent ipsetcreate() can grow the array: it publishes the new array, calls synchronizenet() and then kvfree()s the old one. Since the dump paths read the array outside any RCU reader, synchronizenet() does not wait for them and the old array can be freed while they still index into it, causing a use-after-free.

The dumped set itself stays pinned via set->refnetlink, so only the array load needs protecting. Take rcureadlock() around it, matching ipsetgetbyname() and ipsetputbyindex().

BUG: KASAN: slab-use-after-free in ipsetdumpdo (net/netfilter/ipset/ipsetcore.c:1697) Read of size 8 at addr ffff88800b5c4018 by task exploit/150 Call Trace: ... kasanreport (mm/kasan/report.c:595) ipsetdumpdo (net/netfilter/ipset/ipsetcore.c:1697) netlinkdump (net/netlink/afnetlink.c:2325) netlinkrecvmsg (net/netlink/afnetlink.c:1976) sockrecvmsg (net/socket.c:1159) sysrecvfrom (net/socket.c:2315) ... Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI KASAN: maybe wild-memory-access in range [0x02d6...d0-0x02d6...d7] RIP: 0010:ipsetdumpdo (net/netfilter/ipset/ipsetcore.c:1698) Kernel panic - not syncing: Fatal exception

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

KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0

Don't BUG/WARN on interrupt injection due to GIF being cleared, since it's trivial for userspace to force the situation via KVMSETVCPUEVENTS (even if having at least a WARN there would be correct for KVM internally generated injections).

kernel BUG at arch/x86/kvm/svm/svm.c:3386! invalid opcode: 0000 [#1] SMP CPU: 15 PID: 926 Comm: smmtest Not tainted 5.17.0-rc3+ #264 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svminjectirq+0xab/0xb0 [kvmamd] Code: <0f> 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53 RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006 RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0 RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000 FS: 0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0 Call Trace: <TASK> injectpendingevent+0x2f7/0x4c0 [kvm] kvmarchvcpuioctlrun+0x791/0x17a0 [kvm] kvmvcpuioctl+0x26d/0x650 [kvm] x64sysioctl+0x82/0xb0 dosyscall64+0x3b/0xc0 entrySYSCALL64afterhwframe+0x44/0xae </TASK>

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

wifi: mwifiex: Fix OOB and integer underflow when rx packets

Make sure mwifiexprocessmgmtpacket, mwifiexprocessstarxpacket and mwifiexprocessuaprxpacket, mwifiexuapqueuebridgedpkt and mwifiexprocessrxpacket not out-of-bounds access the skb->data buffer.

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

Bluetooth: L2CAP: fix "bad unlock balance" in l2capdisconnectrsp

conn->chanlock isn't acquired before l2capgetchanbyscid, if l2capgetchanbyscid returns NULL, then 'bad unlock balance' is triggered.

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

Bluetooth: L2CAP: Fix use-after-free

Fix potential use-after-free in l2caplecommandrej.

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

fs: fix UAF/GPF bug in nilfsmdtdestroy

In allocinode, inodeinitalways() could return -ENOMEM if securityinodealloc() fails, which causes inode->iprivate uninitialized. Then nilfsismetadatafileinode() returns true and nilfsfreeinode() wrongly calls nilfsmdtdestroy(), which frees the uninitialized inode->iprivate and leads to crashes(e.g., UAF/GPF).

Fix this by moving securityinodealloc just prior to thiscpuinc(nrinodes)

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

crypto: seqiv - Handle EBUSY correctly

As it is seqiv only handles the special return value of EINPROGERSS, which means that in all other cases it will free data related to the request.

However, as the caller of seqiv may specify MAYBACKLOG, we also need to expect EBUSY and treat it in the same way. Otherwise backlogged requests will trigger a use-after-free.

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

Bluetooth: L2CAP: Fix user-after-free

This uses l2capchanholdunlesszero() after calling l2capgetchanblah() to prevent the following trace:

Bluetooth: l2capcore.c:static void l2capchandestroy(struct kref kref) Bluetooth: chan 0000000023c4974d Bluetooth: parent 00000000ae861c08 ================================================================== BUG: KASAN: use-after-free in mutexwaiterisfirst kernel/locking/mutex.c:191 [inline] BUG: KASAN: use-after-free in mutexlockcommon kernel/locking/mutex.c:671 [inline] BUG: KASAN: use-after-free in mutexlock+0x278/0x400 kernel/locking/mutex.c:729 Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389

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

netfilter: nftables: don't skip expired elements during walk

There is an asymmetry between commit/abort and preparation phase if the following conditions are met:

1. set is a verdict map ("1.2.3.4 : jump foo") 2. timeouts are enabled

In this case, following sequence is problematic:

1. element E in set S refers to chain C 2. userspace requests removal of set S 3. kernel does a set walk to decrement chain->use count for all elements from preparation phase 4. kernel does another set walk to remove elements from the commit phase (or another walk to do a chain->use increment for all elements from abort phase)

If E has already expired in 1), it will be ignored during list walk, so its use count won't have been changed.

Then, when set is culled, ->destroy callback will zap the element via nftablessetelemdestroy(), but this function is only safe for elements that have been deactivated earlier from the preparation phase: lack of earlier deactivate removes the element but leaks the chain use count, which results in a WARN splat when the chain gets removed later, plus a leak of the nftchain structure.

Update pipapoget() not to skip expired elements, otherwise flush command reports bogus ENOENT errors.

HID: core: zero-initialize the report buffer

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

ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices

A bogus device can provide a bNumConfigurations value that exceeds the initial value used in usbgetconfiguration for allocating dev->config.

This can lead to out-of-bounds accesses later, e.g. in usbdestroyconfiguration.

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

media: uvcvideo: Skip parsing frames of type UVCVSUNDEFINED in uvcparseformat

This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvcparsestreaming.

Android contains an unspecified vulnerability in the kernel that allows for remote code execution. This vulnerability resides in Linux Kernel and could impact other products, including but not limited to Android OS.

An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in saa7134finidev in drivers/media/pci/saa7134/saa7134-core.c.

A vulnerability was found in the tcp subsystem in the Linux Kernel, due to a data race around icsk->icskafops. This issue could allow an attacker to leak internal kernel information.

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 flaw in Linux Kernel found in nfcmrvlnciunregisterdev() in drivers/nfc/nfcmrvl/main.c can lead to use after free both read or write when non synchronized between cleanup routine and firmware download routine.

An issue was discovered in the Linux kernel through 5.18.3 on powerpc 32-bit platforms. There is a buffer overflow in ptrace PEEKUSER and POKEUSER (aka PEEKUSR and POKEUSR) when accessing floating point registers.

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

PCI/PM: Drain runtime-idle callbacks before driver removal

A race condition between the .runtimeidle() callback and the .remove() callback in the rtsxpcr PCI driver leads to a kernel crash due to an unhandled page fault [1].

The problem is that rtsxpciruntimeidle() is not expected to be running after pmruntimegetsync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns.

However, if a .runtimeidle() callback is already running when pmruntimegetsync() is called, the latter will notice that the runtime PM status of the device is RPMACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtimeidle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited).

Thus in general, whoever is providing a .runtimeidle() callback needs to protect it from running in parallel with whatever code runs after pmruntimegetsync(). [Note that .runtimeidle() will not start after pmruntimegetsync() has returned, but it may continue running then if it has started earlier.]

One way to address that race condition is to call pmruntimebarrier() after pmruntimegetsync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtimeidle() callback to complete should it be running at that point. A suitable place for doing that is in pcideviceremove() which calls pmruntimegetsync() before removing the driver, so it may as well call pmruntimebarrier() subsequently, which will prevent the race in question from occurring, not just in the rtsxpcr driver, but in any PCI drivers providing .runtimeidle() callbacks.

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

ext4: fix corruption during on-line resize

The Linux kernel CVE team has assigned CVE-2024-35807 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2024-35807-2a9e@gregkh/T

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

aio: fix use-after-free due to missing POLLFREE handling

signalfdpoll() and binderpoll() are special in that they use a waitqueue whose lifetime is the current task, rather than the struct file as is normally the case. This is okay for blocking polls, since a blocking poll occurs within one task; however, non-blocking polls require another solution. This solution is for the queue to be cleared before it is freed, by sending a POLLFREE notification to all waiters.

Unfortunately, only eventpoll handles POLLFREE. A second type of non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't handle POLLFREE. This allows a use-after-free to occur if a signalfd or binder fd is polled with aio poll, and the waitqueue gets freed.

Fix this by making aio poll handle POLLFREE.

A patch by Ramji Jiyani <ramjiyani@google.com> (https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com) tried to do this by making aiopollwake() always complete the request inline if POLLFREE is seen. However, that solution had two bugs. First, it introduced a deadlock, as it unconditionally locked the aio context while holding the waitqueue lock, which inverts the normal locking order. Second, it didn't consider that POLLFREE notifications are missed while the request has been temporarily de-queued.

The second problem was solved by my previous patch. This patch then properly fixes the use-after-free by handling POLLFREE in a deadlock-free way. It does this by taking advantage of the fact that freeing of the waitqueue is RCU-delayed, similar to what eventpoll does.

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

net/mlx5e: fix a double-free in arfscreategroups

The Linux kernel CVE team has assigned CVE-2024-35835 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051730-CVE-2024-35835-d75f@gregkh/T

A flaw in the Linux Kernel found. A use-after-free vulnerability in the Linux kernel's net/sched: schqfq component can be exploited to achieve local privilege escalation. When the plug qdisc is used as a class of the qfq qdisc, sending network packets triggers use-after-free in qfqdequeue() due to the incorrect .peek handler of schplug and lack of error checking in aggdequeue().

References: https://github.com/torvalds/linux/commit/8fc134fee27f2263988ae38920bc03da416b03d8

A race condition in perfeventopen() which can be exploited by an unprivileged user to gain root privileges. The bug allows to build several exploit primitives such as kernel address information leak, arbitrary execution, etc.