OESA-2025-2349

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

tracing: Fix reading strings from synthetic events

The follow commands caused a crash:

# cd /sys/kernel/tracing # echo 's:open char file[]' > dynamicevents # echo 'hist:keys=commonpid:file=filename:onchange($file).trace(open,$file)' > events/syscalls/sysenteropenat/trigger' # echo 1 > events/synthetic/open/enable

BOOM!

The problem is that the synthetic event field "char file[]" will read the value given to it as a string without any memory checks to make sure the address is valid. The above example will pass in the user space address and the sythetic event code will happily call strlen() on it and then strscpy() where either one will cause an oops when accessing user space addresses.

Use the helper functions from tracekprobe and traceeprobe that can read strings safely (and actually succeed when the address is from user space and the memory is mapped in).

Now the above can show:

 packagekitd-1721    [000] ...2.   104.597170: open: file=/usr/lib/rpm/fileattrs/cmake.attr
in:imjournal-978     [006] ...2.   104.599642: open: file=/var/lib/rsyslog/imjournal.state.tmp
 packagekitd-1721    [000] ...2.   104.626308: open: file=/usr/lib/rpm/fileattrs/debuginfo.attr(CVE-2022-50255)

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

kprobes: Fix check for probe enabled in kill_kprobe()

In killkprobe(), the check whether disarmkprobeftrace() needs to be called always fails. This is because before that we set the KPROBEFLAGGONE flag for kprobe so that "!kprobedisabled(p)" is always false.

The disarmkprobeftrace() call introduced by commit:

0cb2f1372baa ("kprobes: Fix NULL pointer dereference at kprobeftracehandler")

to fix the NULL pointer reference problem. When the probe is enabled, if we do not disarm it, this problem still exists.

Fix it by putting the probe enabled check before setting the KPROBEFLAGGONE flag.(CVE-2022-50266)

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

erofs: fix order >= MAXORDER warning due to crafted negative isize

As syzbot reported [1], the root cause is that isize field is a signed type, and negative isize is also less than EROFS_BLKSIZ. As a consequence, it's handled as fast symlink unexpectedly.

Let's fall back to the generic path to deal with such unusual i_size.

[1] https://lore.kernel.org/r/(CVE-2022-50313)

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

ext4: avoid deadlock in fs reclaim with page writeback

Ext4 has a filesystem wide lock protecting ext4_writepages() calls to avoid races with switching of journalled data flag or inode format. This lock can however cause a deadlock like:

CPU0 CPU1

ext4writepages() percpudownread(sbi->swritepagesrwsem); ext4changeinodejournalflag() percpudownwrite(sbi->swritepagesrwsem); - blocks, all readers block from now on ext4dowritepages() ext4initioend() kmemcachezalloc(ioendcachep, GFPKERNEL) fsreclaim frees dentry... dentryunlinkinode() iput() - last ref => iputfinal() - inode dirty => writeinodenow()... ext4writepages() tries to acquire sbi->swritepagesrwsem and blocks forever

Make sure we cannot recurse into filesystem reclaim from writeback code to avoid the deadlock.(CVE-2023-53149)

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

md/raid10: prevent soft lockup while flush writes

Currently, there is no limit for raid1/raid10 plugged bio. While flushing writes, raid1 has cond_resched() while raid10 doesn't, and too many writes can cause soft lockup.

Follow up soft lockup can be triggered easily with writeback test for raid10 with ramdisks:

watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0raid10:1293] Call Trace: <TASK> callrcu+0x16/0x20 putobject+0x41/0x80 _deleteobject+0x50/0x90 deleteobjectfull+0x2b/0x40 kmemleakfree+0x46/0xa0 slabfreefreelisthook.constprop.0+0xed/0x1a0 kmemcachefree+0xfd/0x300 mempoolfreeslab+0x1f/0x30 mempoolfree+0x3a/0x100 biofree+0x59/0x80 bioput+0xcf/0x2c0 freer10bio+0xbf/0xf0 raidendbioio+0x78/0xb0 onewritedone+0x8a/0xa0 raid10endwriterequest+0x1b4/0x430 bioendio+0x175/0x320 brdsubmitbio+0x3b9/0x9b7 [brd] _submitbio+0x69/0xe0 submitbionoacctnocheck+0x1e6/0x5a0 submitbionoacct+0x38c/0x7e0 flushpending_writes+0xf0/0x240 raid10d+0xac/0x1ed0

Fix the problem by adding cond_resched() to raid10 like what raid1 did.

Note that unlimited plugged bio still need to be optimized, for example, in the case of lots of dirty pages writeback, this will take lots of memory and io will spend a long time in plug, hence io latency is bad.(CVE-2023-53151)

In the Linux kernel, a memory leak vulnerability exists in the SCSI core component. When deviceadd() fails, the memory allocated by devsetname() for the device name is not properly freed. As per the deviceadd() comment documentation, put_device() should be used to decrease the reference count in the error path, but the current implementation fails to handle this correctly, resulting in a memory leak.(CVE-2023-53174)

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

bpf: Fix memleak due to fentry attach failure

If it fails to attach fentry, the allocated bpf trampoline image will be left in the system. That can be verified by checking /proc/kallsyms.

This meamleak can be verified by a simple bpf program as follows:

SEC("fentry/trapinit") int fentryrun() { return 0; }

It will fail to attach trap_init because this function is freed after kernel init, and then we can find the trampoline image is left in the system by checking /proc/kallsyms.

$ tail /proc/kallsyms ffffffffc0613000 t bpftrampoline64424534661 [bpf] ffffffffc06c3000 t bpftrampoline64424534661 [bpf]

$ bpftool btf dump file /sys/kernel/btf/vmlinux | grep "FUNC 'trapinit'" [2522] FUNC 'trapinit' type_id=119 linkage=static

$ echo $((6442453466 & 0x7fffffff)) 2522

Note that there are two left bpf trampoline images, that is because the libbpf will fallback to raw tracepoint if -EINVAL is returned.(CVE-2023-53221)

In the Linux kernel, a NULL pointer dereference vulnerability has been resolved. If ipisendmask() or ipisendsingle() is called with an invalid interrupt number, all the local variables there will be NULL. ipisendverify() which is invoked from these functions does not verify its 'data' parameter, resulting in a kernel oops in irqdatagetaffinitymask() as the passed NULL pointer gets dereferenced. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.(CVE-2023-53332)

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

md/raid10: check slab-out-of-bounds in mdbitmapget_counter

If we write a large number to md/bitmapsetbits, mdbitmapcheckpage() will return -EINVAL because 'page >= bitmap->pages', but the return value was not checked immediately in mdbitmapget_counter() in order to set *blocks value and slab-out-of-bounds occurs.

Move check of 'page >= bitmap->pages' to mdbitmapget_counter() and return directly if true.(CVE-2023-53357)

In the Linux kernel Bluetooth component, a potential use-after-free vulnerability exists when clearing keys. Similar to commit c5d2b6fa26b5 ("Bluetooth: Fix use-after-free in hciremoveltk/hciremoveirk"), the code cannot access k after kfree_rcu() call.(CVE-2023-53386)

In the Linux kernel, a slab-out-of-bounds vulnerability exists in the ntfslistxattr() function of the NTFS filesystem. When ea->namelen is 0, the iteration logic error causes Add2Ptr() to access invalid memory, resulting in a kernel panic. This vulnerability can be exploited by attackers to cause system crashes.(CVE-2023-53420)

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

scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structure

If a call to lpfcsli4readrev() from lpfcsli4hbasetup() fails, the resultant cleanup routine lpfcsli4vportdeletefcpxriaborted() may occur before sli4hba.hdwqs are allocated. This may result in a null pointer dereference when attempting to take the abtsiobuflistlock for the first hardware queue. Fix by adding a null ptr check on phba->sli4hba.hdwq and early return because this situation means there must have been an error during port initialization.(CVE-2025-38695)

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

net: bridge: fix soft lockup in brmulticastquery_expired()

When set multicastqueryinterval to a large value, the local variable 'time' in brmulticastsendquery() may overflow. If the time is smaller than jiffies, the timer will expire immediately, and then call modtimer() again, which creates a loop and may trigger the following soft lockup issue.

watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rbconsumer:66] CPU: 1 UID: 0 PID: 66 Comm: rbconsumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: <IRQ> _netdevallocskb+0x2e/0x3a0 brip6multicastallocquery+0x212/0x1b70 _brmulticastsendquery+0x376/0xac0 brmulticastsendquery+0x299/0x510 brmulticastqueryexpired.constprop.0+0x16d/0x1b0 calltimerfn+0x3b/0x2a0 _runtimers+0x619/0x950 runtimersoftirq+0x11c/0x220 handlesoftirqs+0x18e/0x560 _irqexitrcu+0x158/0x1a0 sysvecapictimerinterrupt+0x76/0x90 </IRQ>

This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicastquerier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicastquery_interval ip link set dev br0 up

The multicaststartupquery_interval can also cause this issue. Similar to the commit 99b40610956a ("net: bridge: mcast: add and enforce query interval minimum"), add check for the query interval maximum to fix this issue.(CVE-2025-39773)

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

ftrace: Fix potential warning in traceprintkseq during ftrace_dump

When calling ftracedumpone() concurrently with reading tracepipe, a WARNONONCE() in traceprintk_seq() can be triggered due to a race condition.

The issue occurs because:

CPU0 (ftrace_dump) CPU1 (reader) echo z > /proc/sysrq-trigger

!traceempty(&iter) traceiteratorreset(&iter) <- len = size = 0 cat /sys/kernel/tracing/tracepipe tracefindnextentryinc(&iter) _findnextentry ringbufferemptycpu <- all empty return NULL

traceprintkseq(&iter.seq) WARNONONCE(s->seq.len >= s->seq.size)

In the context between traceempty() and tracefindnextentryinc() during ftracedump, the ring buffer data was consumed by other readers. This caused tracefindnextentryinc to return NULL, failing to populate iter.seq. At this point, due to the prior traceiteratorreset, both iter.seq.len and iter.seq.size were set to 0. Since they are equal, the WARNONONCE condition is triggered.

Move the traceprintkseq() into the if block that checks to make sure the return value of tracefindnextentryinc() is non-NULL in ftracedumpone(), ensuring the 'iter.seq' is properly populated before subsequent operations.(CVE-2025-39813)

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

trace/fgraph: Fix the warning caused by missing unregister notifier

This warning was triggered during testing on v6.16:

notifier callback ftracesuspendnotifiercall already registered WARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifierchainregister+0x44/0xb0 ... Call Trace: <TASK> blockingnotifierchainregister+0x34/0x60 registerftracegraph+0x330/0x410 ftraceprofilewrite+0x1e9/0x340 vfswrite+0xf8/0x420 ? filpflush+0x8a/0xa0 ? filpclose+0x1f/0x30 ? dodup2+0xaf/0x160 ksyswrite+0x65/0xe0 dosyscall64+0xa4/0x260 entrySYSCALL64after_hwframe+0x77/0x7f

When writing to the functionprofileenabled interface, the notifier was not unregistered after startgraphtracing failed, causing a warning the next time functionprofileenabled was written.

Fixed by adding unregisterpmnotifier in the exception path.(CVE-2025-39829)