OESA-2025-1728

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

fs/ntfs3: Fix NULL deref in ntfsupdatemftmirr

If ntfsfillsuper() wasn't called then sbi->sb will be equal to NULL. Code should check this ptr before dereferencing. Syzbot hit this issue via passing wrong mount param as can be seen from log below

Fail log: ntfs3: Unknown parameter 'iochvrset' general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 1 PID: 3589 Comm: syz-executor210 Not tainted 5.18.0-rc3-syzkaller-00016-gb253435746d9 #0 ... Call Trace: <TASK> putntfs+0x1ed/0x2a0 fs/ntfs3/super.c:463 ntfsfsfree+0x6a/0xe0 fs/ntfs3/super.c:1363 putfscontext+0x119/0x7a0 fs/fscontext.c:469 donewmount+0x2b4/0xad0 fs/namespace.c:3044 domount fs/namespace.c:3383 [inline] _dosysmount fs/namespace.c:3591 inline

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

bpf: fix potential 32-bit overflow when accessing ARRAY map element

If BPF array map is bigger than 4GB, element pointer calculation can overflow because both index and elem_size are u32. Fix this everywhere by forcing 64-bit multiplication. Extract this formula into separate small helper and use it consistently in various places.

Speculative-preventing formula utilizing index_mask trick is left as is, but explicit u64 casts are added in both places.(CVE-2022-50167)

Linux kernel is the kernel used by Linux, the open source operating system of the Linux Foundation in the United States. There is a security vulnerability in Linux kernel. This vulnerability originates from arm64 not setting UXN in swapper page table, which may cause access to be denied.(CVE-2022-50230)

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

fbcon: always restore the old font data in fbcondoset_font()

Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when vcresize() failed) started restoring old font data upon failure (of vcresize()). But it performs so only for user fonts. It means that the "system"/internal fonts are not restored at all. So in result, the very first call to fbcondosetfont() performs no restore at all upon failing vcresize().

This can be reproduced by Syzkaller to crash the system on the next invocation of fontget(). It's rather hard to hit the allocation failure in vcresize() on the first fontset(), but not impossible. Esp. if fault injection is used to aid the execution/failure. It was demonstrated by Sirius: BUG: unable to handle page fault for address: fffffffffffffff8 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:fbcongetfont+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286 Call Trace: <TASK> confontget drivers/tty/vt/vt.c:4558 [inline] confontop+0x1fc/0xf20 drivers/tty/vt/vt.c:4673 vtkioctl drivers/tty/vt/vtioctl.c:474 [inline] vtioctl+0x632/0x2ec0 drivers/tty/vt/vtioctl.c:752 ttyioctl+0x6f8/0x1570 drivers/tty/ttyio.c:2803 vfsioctl fs/ioctl.c:51 [inline] ...

So restore the font data in any case, not only for user fonts. Note the later 'if' is now protected by 'olduserfont' and not 'olddata' as the latter is always set now. (And it is supposed to be non-NULL. Otherwise we would see the bug above again.)(CVE-2024-26798)

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

nvme-tcp: fix potential memory corruption in nvmetcprecv_pdu()

nvmetcprecvpdu() doesn't check the validity of the header length. When header digests are enabled, a target might send a packet with an invalid header length (e.g. 255), causing nvmetcpverifyhdgst() to access memory outside the allocated area and cause memory corruptions by overwriting it with the calculated digest.

Fix this by rejecting packets with an unexpected header length.(CVE-2025-21927)

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

nfsd: don't ignore the return code of svcprocregister()

Currently, nfsdprocstatinit() ignores the return value of svcproc_register(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later.

Fix nfsdprocstatinit() to return the same type of pointer as svcprocregister(), and fix up nfsdnetinit() to check that and fail the nfsdnet construction if it occurs.

svcprocregister() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsd_net construction codepath, so if this happens, return -ENOMEM.(CVE-2025-22026)

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

padata: do not leak refcount in reorder_work

A recent patch that addressed a UAF introduced a reference count leak: the paralleldata refcount is incremented unconditionally, regardless of the return value of queuework(). If the work item is already queued, the incremented refcount is never decremented.

Fix this by checking the return value of queue_work() and decrementing the refcount when necessary.

Resolves:

Unreferenced object 0xffff9d9f421e3d80 (size 192): comm "cryptomgrprobe", pid 157, jiffies 4294694003 hex dump (first 32 bytes): 80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............ d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#. backtrace (crc 838fb36): _kmalloccachenoprof+0x284/0x320 padataallocpd+0x20/0x1e0 padataallocshell+0x3b/0xa0 0xffffffffc040a54d cryptomgrprobe+0x43/0xc0 kthread+0xf6/0x1f0 retfromfork+0x2f/0x50 retfromforkasm+0x1a/0x30(CVE-2025-38031)

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

ALSA: pcm: Fix race of buffer access at PCM OSS layer

The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of sndpcmformatsetsilence() with runtime->dmaarea. But this may lead to a UAF because the accessed runtime->dmaarea might be freed concurrently, as it's performed outside the PCM ops.

For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation.(CVE-2025-38078)