OESA-2025-2348

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel's JSM serial driver, a resource leak vulnerability exists in the probe function. The error path needs to properly unwind instead of just returning directly, which may lead to resource leakage issues.(CVE-2022-50312)

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

rapidio: fix possible name leaks when rioadddevice() fails

Patch series "rapidio: fix three possible memory leaks".

This patchset fixes three name leaks in error handling. - patch #1 fixes two name leaks while rioadddevice() fails. - patch #2 fixes a name leak while rioregistermport() fails.

This patch (of 2):

If rioadddevice() returns error, the name allocated by devsetname() need be freed. It should use putdevice() to give up the reference in the error path, so that the name can be freed in kobjectcleanup(), and the 'rdev' can be freed in rioreleasedev().(CVE-2022-50343)

In the Linux kernel, there is a memory leak vulnerability in the tpmcrb driver. In the crbacpi_add() function, after obtaining the TPM2 table to retrieve information such as startup methods and assigning them to private data, the TPM2 table is no longer used after initialization is completed, but is not released correctly, resulting in memory leaks.(CVE-2022-50389)

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, 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:

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)