OESA-2025-1821

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

tty: ngsm: add sanity check for gsm->receive in gsmreceive_buf()

A null pointer dereference can happen when attempting to access the "gsm->receive()" function in gsmldreceivebuf(). Currently, the code assumes that gsm->recieve is only called after MUX activation. Since the gsmldreceivebuf() function can be accessed without the need to initialize the MUX, the gsm->receive() function will not be set and a NULL pointer dereference will occur.

Fix this by avoiding the call to "gsm->receive()" in case the function is not initialized by adding a sanity check.

Call Trace: <TASK> gsmldreceivebuf+0x1c2/0x2f0 drivers/tty/ngsm.c:2861 tiocsti drivers/tty/ttyio.c:2293 [inline] ttyioctl+0xa75/0x15d0 drivers/tty/ttyio.c:2692 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:870 [inline] _sesysioctl fs/ioctl.c:856 [inline] _x64sysioctl+0x193/0x200 fs/ioctl.c:856 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd(CVE-2022-49940)

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

iio: light: opt3001: fix deadlock due to concurrent flag access

The threaded IRQ function in this driver is reading the flag twice: once to lock a mutex and once to unlock it. Even though the code setting the flag is designed to prevent it, there are subtle cases where the flag could be true at the mutexlock stage and false at the mutexunlock stage. This results in the mutex not being unlocked, resulting in a deadlock.

Fix it by making the opt3001_irq() code generally more robust, reading the flag into a variable and using the variable value at both stages.(CVE-2025-37968)

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

nfs: handle failure of nfsgetlock_context in unlock path

When memory is insufficient, the allocation of nfslockcontext in nfsgetlockcontext() fails and returns -ENOMEM. If we mistakenly treat an nfs4unlockdata structure (whose lctx member has been set to -ENOMEM) as valid and proceed to execute rpcruntask(), this will trigger a NULL pointer dereference in nfs4locku_prepare. For example:

BUG: kernel NULL pointer dereference, address: 000000000000000c PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 Workqueue: rpciod rpcasyncschedule RIP: 0010:nfs4lockuprepare+0x35/0xc2 Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3 RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246 RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40 RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38 R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030 R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30 FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0 Call Trace: <TASK> _rpcexecute+0xbc/0x480 rpcasyncschedule+0x2f/0x40 processonework+0x232/0x5d0 workerthread+0x1da/0x3d0 ? _pfxworkerthread+0x10/0x10 kthread+0x10d/0x240 ? _pfxkthread+0x10/0x10 retfromfork+0x34/0x50 ? _pfxkthread+0x10/0x10 retfromfork_asm+0x1a/0x30 </TASK> Modules linked in: CR2: 000000000000000c ---[ end trace 0000000000000000 ]---

Free the allocated nfs4unlockdata when nfsgetlockcontext() fails and return NULL to terminate subsequent rpcruntask, preventing NULL pointer dereference.(CVE-2025-38023)

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

libnvdimm/labels: Fix divide error in ndlabeldata_init()

If a faulty CXL memory device returns a broken zero LSA size in its memory device information (Identify Memory Device (Opcode 4000h), CXL spec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm driver:

Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ndlabeldata_init+0x10e/0x800 [libnvdimm]

Code and flow:

1) CXL Command 4000h returns LSA size = 0 2) config_size is assigned to zero LSA size (CXL pmem driver):

drivers/cxl/pmem.c: .configsize = mds->lsasize,

3) max_xfer is set to zero (nvdimm driver):

drivers/nvdimm/label.c: maxxfer = mint(sizet, ndd->nsarea.maxxfer, config_size);

4) A subsequent DIVROUNDUP() causes a division by zero:

drivers/nvdimm/label.c: /* Make our initial read size a multiple of maxxfer size */ drivers/nvdimm/label.c: readsize = min(DIVROUNDUP(readsize, maxxfer) * maxxfer, drivers/nvdimm/label.c- configsize);

Fix this by checking the config size parameter by extending an existing check.(CVE-2025-38072)

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

dma-buf: insert memory barrier before updating num_fences

smpstoremb() inserts memory barrier after storing operation. It is different with what the comment is originally aiming so Null pointer dereference can be happened if memory update is reordered.(CVE-2025-38095)

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

net: openvswitch: Fix the dead loop of MPLS parse

The unexpected MPLS packet may not end with the bottom label stack. When there are many stacks, The label count value has wrapped around. A dead loop occurs, soft lockup/CPU stuck finally.

stack backtrace: UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26 index -1 is out of range for type '_be32 [3]' CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G OE 5.15.0-121-generic #131-Ubuntu Hardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021 Call Trace: <IRQ> showstack+0x52/0x5c dumpstacklvl+0x4a/0x63 dumpstack+0x10/0x16 ubsanepilogue+0x9/0x36 _ubsanhandleoutofbounds.cold+0x44/0x49 keyextractl3l4+0x82a/0x840 [openvswitch] ? kfreeskbmem+0x52/0xa0 keyextract+0x9c/0x2b0 [openvswitch] ovsflowkeyextract+0x124/0x350 [openvswitch] ovsvportreceive+0x61/0xd0 [openvswitch] ? kernelinitfreepages.part.0+0x4a/0x70 ? getpagefromfreelist+0x353/0x540 netdevportreceive+0xc4/0x180 [openvswitch] ? netdevportreceive+0x180/0x180 [openvswitch] netdevframehook+0x1f/0x40 [openvswitch] _netifreceiveskbcore.constprop.0+0x23a/0xf00 _netifreceiveskblistcore+0xfa/0x240 netifreceiveskblistinternal+0x18e/0x2a0 napicompletedone+0x7a/0x1c0 bnxtpoll+0x155/0x1c0 [bnxten] _napipoll+0x30/0x180 netrxaction+0x126/0x280 ? bnxtmsix+0x67/0x80 [bnxten] handlesoftirqs+0xda/0x2d0 irqexitrcu+0x96/0xc0 common_interrupt+0x8e/0xa0 </IRQ>(CVE-2025-38146)

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

arm64/fpsimd: Discard stale CPU state when handling SME traps

The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state incorrectly, and a race with preemption can result in a task having TIFSME set and TIFFOREIGNFPSTATE clear even though the live CPU state is stale (e.g. with SME traps enabled). This can result in warnings from dosmeacc() where SME traps are not expected while TIFSME is set:

| /* With TIFSME userspace shouldn't generate any traps */ | if (testandsetthreadflag(TIFSME)) | WARN_ON(1);

This is very similar to the SVE issue we fixed in commit:

751ecf6afd6568ad ("arm64/sve: Discard stale CPU state when handling SVE traps")

The race can occur when the SME trap handler is preempted before and after manipulating the saved FPSIMD/SVE/SME state, starting and ending on the same CPU, e.g.

| void dosmeacc(unsigned long esr, struct ptregs *regs) | { | // Trap on CPU 0 with TIFSME clear, SME traps enabled | // task->fpsimdcpu is 0. | // percpuptr(&fpsimdlaststate, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIFFOREIGNFPSTATE is set. | | getcpufpsimdcontext(); | | /* With TIFSME userspace shouldn't generate any traps */ | if (testandsetthreadflag(TIFSME)) | WARNON(1); | | if (!testthreadflag(TIFFOREIGNFPSTATE)) { | unsigned long vqminusone = | svevqfromvl(taskgetsmevl(current)) - 1; | smesetvq(vqminusone); | | fpsimdbindtasktocpu(); | } | | putcpufpsimdcontext(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimdcpu is still 0 | // If percpuptr(&fpsimdlaststate, 0) is still task then: | // - Stale HW state is reused (with SME traps enabled) | // - TIFFOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | }

Fix the case where the state is not live and TIFFOREIGNFPSTATE is set by calling fpsimdflushtaskstate() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIFFOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace.

Note: this was originallly posted as [1].

Rutland: rewrite commit message