OESA-2025-1570

The Linux Kernel, the operating system core itself.

Security Fix(es):

A double-free flaw was found in the Linux kernel’s NTFS3 subsystem in how a user triggers remount and umount simultaneously. This flaw allows a local user to crash or potentially escalate their privileges on the system.(CVE-2022-3238)

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

perf/x86/amd: Fix crash due to race between amdpmuenable_all, perf NMI and throttling

amdpmuenable_all() does:

  if (!test_bit(idx, cpuc->active_mask))
          continue;

  amd_pmu_enable_event(cpuc->events[idx]);

A perf NMI of another event can come between these two steps. Perf NMI handler internally disables and enables all events, including the one which nmi-intercepted amdpmuenableall() was in process of enabling. If that unintentionally enabled event has very low sampling period and causes immediate successive NMI, causing the event to be throttled, cpuc->events[idx] and cpuc->activemask gets cleared by x86pmustop(). This will result in amdpmuenableevent() getting called with event=NULL when amdpmuenableall() resumes after handling the NMIs. This causes a kernel crash:

BUG: kernel NULL pointer dereference, address: 0000000000000198 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page [...] Call Trace: <TASK> amdpmuenableall+0x68/0xb0 ctxresched+0xd9/0x150 eventfunction+0xb8/0x130 ? hrtimerstartrangens+0x141/0x4a0 ? perfdurationwarn+0x30/0x30 remotefunction+0x4d/0x60 _flushsmpcallfunctionqueue+0xc4/0x500 flushsmpcallfunctionqueue+0x11d/0x1b0 doidle+0x18f/0x2d0 cpustartupentry+0x19/0x20 startsecondary+0x121/0x160 secondarystartup64no_verify+0xe5/0xeb </TASK>

amdpmudisableall()/amdpmuenableall() calls inside perf NMI handler were recently added as part of BRS enablement but I'm not sure whether we really need them. We can just disable BRS in the beginning and enable it back while returning from NMI. This will solve the issue by not enabling those events whose active_masks are set but are not yet enabled in hw pmu.(CVE-2022-49781)

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

perf/x86/amd/uncore: Fix memory leak for events array

When a CPU comes online, the per-CPU NB and LLC uncore contexts are freed but not the events array within the context structure. This causes a memory leak as identified by the kmemleak detector.

[...] unreferenced object 0xffff8c5944b8e320 (size 32): comm "swapper/0", pid 1, jiffies 4294670387 (age 151.072s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000000759fb79>] amduncorecpuupprepare+0xaf/0x230 [<00000000ddc9e126>] cpuhpinvokecallback+0x2cf/0x470 [<0000000093e727d4>] cpuhpissuecall+0x14d/0x170 [<0000000045464d54>] _cpuhpsetupstatecpuslocked+0x11e/0x330 [<0000000069f67cbd>] _cpuhpsetupstate+0x6b/0x110 [<0000000015365e0f>] amduncoreinit+0x260/0x321 [<00000000089152d2>] dooneinitcall+0x3f/0x1f0 [<000000002d0bd18d>] kernelinitfreeable+0x1ca/0x212 [<0000000030be8dde>] kernelinit+0x11/0x120 [<0000000059709e59>] retfromfork+0x22/0x30 unreferenced object 0xffff8c5944b8dd40 (size 64): comm "swapper/0", pid 1, jiffies 4294670387 (age 151.072s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000306efe8b>] amduncorecpuupprepare+0x183/0x230 [<00000000ddc9e126>] cpuhpinvokecallback+0x2cf/0x470 [<0000000093e727d4>] cpuhpissuecall+0x14d/0x170 [<0000000045464d54>] _cpuhpsetupstatecpuslocked+0x11e/0x330 [<0000000069f67cbd>] _cpuhpsetupstate+0x6b/0x110 [<0000000015365e0f>] amduncoreinit+0x260/0x321 [<00000000089152d2>] dooneinitcall+0x3f/0x1f0 [<000000002d0bd18d>] kernelinitfreeable+0x1ca/0x212 [<0000000030be8dde>] kernelinit+0x11/0x120 [<0000000059709e59>] retfromfork+0x22/0x30 [...]

Fix the problem by freeing the events array before freeing the uncore context.(CVE-2022-49784)

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

ksmbd: fix possible refcount leak in smb2_open()

Reference count of acls will leak when memory allocation fails. Fix this by adding the missing posixaclrelease().(CVE-2023-53061)

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

perf/x86/amd/core: Always clear status for idx

The variable 'status' (which contains the unhandled overflow bits) is not being properly masked in some cases, displaying the following warning:

WARNING: CPU: 156 PID: 475601 at arch/x86/events/amd/core.c:972 amdpmuv2handleirq+0x216/0x270

This seems to be happening because the loop is being continued before the status bit being unset, in case x86perfeventsetperiod() returns 0. This is also causing an inconsistency because the "handled" counter is incremented, but the status bit is not cleaned.

Move the bit cleaning together above, together when the "handled" counter is incremented.(CVE-2023-53073)

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

media: dw2102: Fix null-ptr-deref in dw2102i2ctransfer()

In dw2102i2ctransfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach dw2102i2ctransfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash.

Similar commit: commit 950e252cb469 ("[media] dw2102: limit messages to buffer size")(CVE-2023-53146)

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

drm/dp_mst: Fix resetting msg rx state after topology removal

If the MST topology is removed during the reception of an MST down reply or MST up request sideband message, the drmdpmsttopologymgr::upreqrecv/downreprecv states could be reset from one thread via drmdpmsttopologymgrsetmst(false), racing with the reading/parsing of the message from another thread via drmdpmsthandledownrep() or drmdpmsthandleupreq(). The race is possible since the reader/parser doesn't hold any lock while accessing the reception state. This in turn can lead to a memory corruption in the reader/parser as described by commit bd2fccac61b4 ("drm/dp_mst: Fix MST sideband message body length check").

Fix the above by resetting the message reception state if needed before reading/parsing a message. Another solution would be to hold the drmdpmsttopologymgr::lock for the whole duration of the message reception/parsing in drmdpmsthandledownrep() and drmdpmsthandleupreq(), however this would require a bigger change. Since the fix is also needed for stable, opting for the simpler solution in this patch.(CVE-2024-57876)

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

wifi: ath11k: fix RCU stall while reaping monitor destination ring

While processing the monitor destination ring, MSDUs are reaped from the link descriptor based on the corresponding buf_id.

However, sometimes the driver cannot obtain a valid buffer corresponding to the buf_id received from the hardware. This causes an infinite loop in the destination processing, resulting in a kernel crash.

kernel log: ath11kpci 0000:58:00.0: data msdupop: invalid bufid 309 ath11kpci 0000:58:00.0: data dprxmonitorlinkdescreturn failed ath11kpci 0000:58:00.0: data msdupop: invalid bufid 309 ath11kpci 0000:58:00.0: data dprxmonitorlinkdescreturn failed

Fix this by skipping the problematic buf_id and reaping the next entry, replacing the break with the next MSDU processing.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPLV1V2SILICONZLITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1(CVE-2024-58097)

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

virtiofs: add filesystem context source name check

In certain scenarios, for example, during fuzz testing, the source name may be NULL, which could lead to a kernel panic. Therefore, an extra check for the source name should be added.(CVE-2025-37773)

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

hfs/hfsplus: fix slab-out-of-bounds in hfsbnoderead_key

Syzbot reported an issue in hfs subsystem:

BUG: KASAN: slab-out-of-bounds in memcpyfrompage include/linux/highmem.h:423 [inline] BUG: KASAN: slab-out-of-bounds in hfsbnoderead fs/hfs/bnode.c:35 [inline] BUG: KASAN: slab-out-of-bounds in hfsbnoderead_key+0x314/0x450 fs/hfs/bnode.c:70 Write of size 94 at addr ffff8880123cd100 by task syz-executor237/5102

Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 kasancheckrange+0x282/0x290 mm/kasan/generic.c:189 _asanmemcpy+0x40/0x70 mm/kasan/shadow.c:106 memcpyfrompage include/linux/highmem.h:423 [inline] hfsbnoderead fs/hfs/bnode.c:35 [inline] hfsbnodereadkey+0x314/0x450 fs/hfs/bnode.c:70 hfsbrecinsert+0x7f3/0xbd0 fs/hfs/brec.c:159 hfscatcreate+0x41d/0xa50 fs/hfs/catalog.c:118 hfsmkdir+0x6c/0xe0 fs/hfs/dir.c:232 vfsmkdir+0x2f9/0x4f0 fs/namei.c:4257 domkdirat+0x264/0x3a0 fs/namei.c:4280 _dosysmkdir fs/namei.c:4300 [inline] _sesysmkdir fs/namei.c:4298 [inline] _x64sysmkdir+0x6c/0x80 fs/namei.c:4298 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f RIP: 0033:0x7fbdd6057a99

Add a check for key length in hfsbnoderead_key to prevent out-of-bounds memory access. If the key length is invalid, the key buffer is cleared, improving stability and reliability.(CVE-2025-37782)

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

jfs: reject on-disk inodes of an unsupported type

Syzbot has reported the following BUG:

kernel BUG at fs/inode.c:668! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 RIP: 0010:clearinode+0x168/0x190 Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f RSP: 0018:ffffc900027dfae8 EFLAGS: 00010093 RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38 R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000 R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80 FS: 0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0 Call Trace: <TASK> ? _diebody+0x5f/0xb0 ? die+0x9e/0xc0 ? dotrap+0x15a/0x3a0 ? clearinode+0x168/0x190 ? doerrortrap+0x1dc/0x2c0 ? clearinode+0x168/0x190 ? _pfxdoerrortrap+0x10/0x10 ? reportbug+0x3cd/0x500 ? handleinvalidop+0x34/0x40 ? clearinode+0x168/0x190 ? excinvalidop+0x38/0x50 ? asmexcinvalidop+0x1a/0x20 ? clearinode+0x57/0x190 ? clearinode+0x167/0x190 ? clearinode+0x168/0x190 ? clearinode+0x167/0x190 jfsevictinode+0xb5/0x440 ? _pfxjfsevictinode+0x10/0x10 evict+0x4ea/0x9b0 ? _pfxevict+0x10/0x10 ? iput+0x713/0xa50 txUpdateMap+0x931/0xb10 ? _pfxtxUpdateMap+0x10/0x10 jfslazycommit+0x49a/0xb80 ? rawspinunlockirqrestore+0x8f/0x140 ? lockdephardirqson+0x99/0x150 ? _pfxjfslazycommit+0x10/0x10 ? _pfxdefaultwakefunction+0x10/0x10 ? _kthreadparkme+0x169/0x1d0 ? _pfxjfslazycommit+0x10/0x10 kthread+0x2f2/0x390 ? _pfxjfslazycommit+0x10/0x10 ? _pfxkthread+0x10/0x10 retfromfork+0x4d/0x80 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

This happens when 'clearinode()' makes an attempt to finalize an underlying JFS inode of unknown type. According to JFS layout description from https://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to 15 are reserved for future extensions and should not be encountered on a valid filesystem. So add an extra check for valid inode type in 'copyfrom_dinode()'.(CVE-2025-37925)

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

ftrace: Add condresched() to ftracegraphsethash()

When the kernel contains a large number of functions that can be traced, the loop in ftracegraphset_hash() may take a lot of time to execute. This may trigger the softlockup watchdog.

Add cond_resched() within the loop to allow the kernel to remain responsive even when processing a large number of functions.

This matches the cond_resched() that is used in other locations of the code that iterates over all functions that can be traced.(CVE-2025-37940)

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

block: fix resource leak in blkregisterqueue() error path

When registering a queue fails after blkmqsysfsregister() is successful but the function later encounters an error, we need to clean up the blkmq_sysfs resources.

Add the missing blkmqsysfs_unregister() call in the error path to properly clean up these resources and prevent a memory leak.(CVE-2025-37980)