OESA-2025-2408

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net: dsa: Avoid cross-chip syncing of VLAN filtering

Changes to VLAN filtering are not applicable to cross-chip notifications.

On a system like this:

.-----. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-' '-1-2-' '-1-2-'

Before this change, upon sw1p1 leaving a bridge, a call to dsaportvlan_filtering would also be made to sw2p1 and sw3p1.

In this scenario:

.---------. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-3-4-' '-1-2-' '-1-2-'

When sw1p4 would leave a bridge, dsaportvlan_filtering would be called for sw2 and sw3 with a non-existing port - leading to array out-of-bounds accesses and crashes on mv88e6xxx.(CVE-2022-49234)

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

scsi: target: iscsi: Fix a race condition between login_work and the login thread

In case a malicious initiator sends some random data immediately after a login PDU; the iscsitargetskdataready() callback will schedule the loginwork and, at the same time, the negotiation may end without clearing the LOGINFLAGSINITIALPDU flag (because no additional PDU exchanges are required to complete the login).

The login has been completed but the loginwork function will find the LOGINFLAGSINITIALPDU flag set and will never stop from rescheduling itself; at this point, if the initiator drops the connection, the iscsitconn structure will be freed, loginwork will dereference a released socket structure and the kernel crashes.

BUG: kernel NULL pointer dereference, address: 0000000000000230 PF: supervisor write access in kernel mode PF: errorcode(0x0002) - not-present page Workqueue: events iscsitargetdologinrx [iscsitargetmod] RIP: 0010:rawreadlockbh+0x15/0x30 Call trace: iscsitargetdologinrx+0x75/0x3f0 [iscsitargetmod] processone_work+0x1e8/0x3c0

Fix this bug by forcing login_work to stop after the login has been completed and the socket callbacks have been restored.

Add a comment to clearify the return values of iscsitargetdo_login()(CVE-2022-50350)

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

fbdev: fbcon: release buffer when fbcondoset_font() failed

syzbot is reporting memory leak at fbcondosetfont() [1], for commit a5a923038d70 ("fbdev: fbcon: Properly revert changes when vcresize() failed") missed that the buffer might be newly allocated by fbconsetfont().(CVE-2022-50404)

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

nfsd: call oprelease, even when opfunc returns an error

For ops with "trivial" replies, nfsd4encodeoperation will shortcut most of the encoding work and skip to just marshalling up the status. One of the things it skips is calling op_release. This could cause a memory leak in the layoutget codepath if there is an error at an inopportune time.

Have the compound processing engine always call oprelease, even when opfunc sets an error in op->status. With this change, we also need nfsd4blockgetdeviceinfoscsi to set the gddevice pointer to NULL on error to avoid a double free.(CVE-2023-53241)

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

VMCI: check context->notifypage after call to getuserpagesfast() to avoid GPF

The call to getuserpagesfast() in vmcihostsetupnotify() can return NULL context->notifypage causing a GPF. To avoid GPF check if context->notifypage == NULL and return error if so.

general protection fault, probably for non-canonical address 0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0x0005088000000300- 0x0005088000000307] CPU: 2 PID: 26180 Comm: repro34802241 Not tainted 6.1.0-rc4 #1 Hardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014 RIP: 0010:vmcictxchecksignalnotify+0x91/0xe0 Call Trace: <TASK> vmcihostunlockedioctl+0x362/0x1f40 _x64sysioctl+0x1a1/0x230 dosyscall64+0x3a/0x90 entrySYSCALL64after_hwframe+0x63/0xcd(CVE-2023-53259)

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

x86/MCE: Always save CS register on AMD Zen IF Poison errors

The Instruction Fetch (IF) units on current AMD Zen-based systems do not guarantee a synchronous #MC is delivered for poison consumption errors. Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the microarchitecture does guarantee that the exception is delivered within the same context. In other words, the exact rIP is not known, but the context is known to not have changed.

There is no architecturally-defined method to determine this behavior.

The Code Segment (CS) register is always valid on such IF unit poison errors regardless of the value of MCG_STATUS[EIPV|RIPV].

Add a quirk to save the CS register for poison consumption from the IF unit banks.

This is needed to properly determine the context of the error. Otherwise, the severity grading function will assume the context is IN_KERNEL due to the m->cs value being 0 (the initialized value). This leads to unnecessary kernel panics on data poison errors due to the kernel believing the poison consumption occurred in kernel context.(CVE-2023-53438)

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

net: ravb: Fix missing rtnl lock in suspend/resume path

Fix the suspend/resume path by ensuring the rtnl lock is held where required. Calls to ravbopen, ravbclose and wol operations must be performed under the rtnl lock to prevent conflicts with ongoing ndo operations.

Without this fix, the following warning is triggered: [ 39.032969] ============================= [ 39.032983] WARNING: suspicious RCU usage [ 39.033019] ----------------------------- [ 39.033033] drivers/net/phy/phydevice.c:2004 suspicious rcudereferenceprotected() usage! ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] showstack+0x14/0x1c (C) [ 39.033652] dumpstacklvl+0xb4/0xc4 [ 39.033664] dumpstack+0x14/0x1c [ 39.033671] lockdeprcususpicious+0x16c/0x22c [ 39.033682] phydetach+0x160/0x190 [ 39.033694] phydisconnect+0x40/0x54 [ 39.033703] ravbclose+0x6c/0x1cc [ 39.033714] ravbsuspend+0x48/0x120 [ 39.033721] dpmruncallback+0x4c/0x14c [ 39.033731] devicesuspend+0x11c/0x4dc [ 39.033740] dpmsuspend+0xdc/0x214 [ 39.033748] dpmsuspendstart+0x48/0x60 [ 39.033758] suspenddevicesandenter+0x124/0x574 [ 39.033769] pmsuspend+0x1ac/0x274 [ 39.033778] statestore+0x88/0x124 [ 39.033788] kobjattrstore+0x14/0x24 [ 39.033798] sysfskfwrite+0x48/0x6c [ 39.033808] kernfsfopwriteiter+0x118/0x1a8 [ 39.033817] vfswrite+0x27c/0x378 [ 39.033825] ksyswrite+0x64/0xf4 [ 39.033833] _arm64syswrite+0x18/0x20 [ 39.033841] invokesyscall+0x44/0x104 [ 39.033852] el0svccommon.constprop.0+0xb4/0xd4 [ 39.033862] doel0svc+0x18/0x20 [ 39.033870] el0svc+0x3c/0xf0 [ 39.033880] el0t64synchandler+0xc0/0xc4 [ 39.033888] el0t64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down(CVE-2025-21801)

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

spufs: fix a leak on spufsnewfile() failure

It's called from spufsfilldir(), and caller of that will do spufs_rmdir() in case of failure. That does remove everything we'd managed to create, but... the problem dentry is still negative. IOW, it needs to be explicitly dropped.(CVE-2025-22073)

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

net: ch9200: fix uninitialised access during miinwayrestart

In miinwayrestart() the code attempts to call mii->mdioread which is ch9200mdioread(). ch9200mdioread() utilises a local buffer called "buff", which is initialised with controlread(). However "buff" is conditionally initialised inside control_read():

    if (err == size) {
            memcpy(data, buf, size);
    }

If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200mdioread():

    return (buff[0] | buff[1] << 8);

The problem stems from the fact that ch9200mdioread() ignores the return value of control_read(), leading to uinit-access of "buff".

To fix this we should check the return value of control_read() and return early on error.(CVE-2025-38086)

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

bus: fsl-mc: fix double-free on mc_dev

The blamed commit tried to simplify how the deallocations are done but, in the process, introduced a double-free on the mc_dev variable.

In case the MC device is a DPRC, a new mcbus is allocated and the mcdev variable is just a reference to one of its fields. In this circumstance, on the error path only the mc_bus should be freed.

This commit introduces back the following checkpatch warning which is a false-positive.

WARNING: kfree(NULL) is safe and this check is probably not required + if (mcbus) + kfree(mcbus);(CVE-2025-38313)

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

fs/ntfs3: cancle set bad inode after removing name fails

The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted.

The underlying bug is that makebadinode() is called on a live inode. In some cases it's "icache lookup finds a normal inode, dsplicealias() is called to attach it to dentry, while another thread decides to call makebadinode() on it - that would evict it from icache, but we'd already found it there earlier". In some it's outright "we have an inode attached to dentry - that's how we got it in the first place; let's call makebadinode() on it just for shits and giggles".(CVE-2025-38615)

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

ARM: rockchip: fix kernel hang during smp initialization

In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect.

The patch moves SRAM initialization step to the point where all secondary CPUs are powered down.

That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchipsmpprepare_cpus: ncores 4(CVE-2025-39752)

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

tee: fix NULL pointer dereference in teeshmput

teeshmput have NULL pointer dereference:

_opteedisableshmcache --> shm = regpairtoptr(...);//shm maybe return NULL teeshmfree(shm); --> teeshm_put(shm);//crash

Add check in teeshmput to fix it.

panic log: Unable to handle kernel paging request at virtual address 0000000000100cca Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000 [0000000000100cca] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ---- 6.6.0-39-generic #38 Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07 Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0 10/26/2022 pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : teeshmput+0x24/0x188 lr : teeshmfree+0x14/0x28 sp : ffff001f98f9faf0 x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000 x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048 x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88 x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff x17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003 x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101 x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c x8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca Call trace: teeshmput+0x24/0x188 teeshmfree+0x14/0x28 _opteedisableshmcache+0xa8/0x108 opteeshutdown+0x28/0x38 platformshutdown+0x28/0x40 deviceshutdown+0x144/0x2b0 kernelpoweroff+0x3c/0x80 hibernate+0x35c/0x388 statestore+0x64/0x80 kobjattrstore+0x14/0x28 sysfskfwrite+0x48/0x60 kernfsfopwriteiter+0x128/0x1c0 vfswrite+0x270/0x370 ksyswrite+0x6c/0x100 _arm64syswrite+0x20/0x30 invokesyscall+0x4c/0x120 el0svccommon.constprop.0+0x44/0xf0 doel0svc+0x24/0x38 el0svc+0x24/0x88 el0t64synchandler+0x134/0x150 el0t64_sync+0x14c/0x15(CVE-2025-39865)

In the Linux kernel, a use-after-free vulnerability exists in the markinodedirty() function. The issue occurs when _markinodedirty() obtains a bdiwriteback that is in the process of switching. This is a race condition vulnerability between inodeswitchwbsworkfn() and markinode_dirty(), causing the old writeback structure to be accessed after it has been released, triggering a use-after-free vulnerability.(CVE-2025-39866)

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

mm/memory-failure: fix VMBUGON_PAGE(PagePoisoned(page)) when unpoison memory

When I did memory failure tests, below panic occurs:

page dumped because: VMBUGONPAGE(PagePoisoned(page)) kernel BUG at include/linux/page-flags.h:616! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40 RIP: 0010:unpoisonmemory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Call Trace: <TASK> unpoisonmemory+0x2f3/0x590 simpleattrwritexsigned.constprop.0.isra.0+0xb3/0x110 debugfsattrwrite+0x42/0x60 fullproxywrite+0x5b/0x80 vfswrite+0xd5/0x540 ksyswrite+0x64/0xe0 dosyscall64+0xb9/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f08f0314887 RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887 RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001 RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009 R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00 </TASK> Modules linked in: hwpoisoninject ---[ end trace 0000000000000000 ]--- RIP: 0010:unpoison_memory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]---

The root cause is that unpoisonmemory() tries to check the PGHWPoison flags of an uninitialized page. So VMBUGON_PAGE(PagePoisoned(page)) is triggered. This can be reproduced by below steps:

1.Offline memory block:

echo offline > /sys/devices/system/memory/memory12/state

2.Get offlined memory pfn:

page-types -b n -rlN

3.Write pfn to unpoison-pfn

echo <pfn> > /sys/kernel/debug/hwpoison/unpoison-pfn

This scenario can be identified by pfntoonlinepage() returning NULL. And ZONEDEVICE pages are never expected, so we can simply fail if pfntoonline_page() == NULL to fix the bug.(CVE-2025-39883)