OESA-2025-1926

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

bus: mhi: host: pcigeneric: Use pcitryresetfunction() to avoid deadlock

There are multiple places from where the recovery work gets scheduled asynchronously. Also, there are multiple places where the caller waits synchronously for the recovery to be completed. One such place is during the PM shutdown() callback.

If the device is not alive during recoverywork, it will try to reset the device using pciresetfunction(). This function internally will take the devicelock() first before resetting the device. By this time, if the lock has already been acquired, then recoverywork will get stalled while waiting for the lock. And if the lock was already acquired by the caller which waits for the recoverywork to be completed, it will lead to deadlock.

This is what happened on the X1E80100 CRD device when the device died before shutdown() callback. Driver core calls the driver's shutdown() callback while holding the device_lock() leading to deadlock.

And this deadlock scenario can occur on other paths as well, like during the PM suspend() callback, where the driver core would hold the devicelock() before calling driver's suspend() callback. And if the recoverywork was already started, it could lead to deadlock. This is also observed on the X1E80100 CRD.

So to fix both issues, use pcitryresetfunction() in recoverywork. This function first checks for the availability of the devicelock() before trying to reset the device. If the lock is available, it will acquire it and reset the device. Otherwise, it will return -EAGAIN. If that happens, recoverywork will fail with the error message "Recovery failed" as not much could be done.(CVE-2025-21951)

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

HID: ignore non-functional sensor in HP 5MP Camera

The HP 5MP Camera (USB ID 0408:5473) reports a HID sensor interface that is not actually implemented. Attempting to access this non-functional sensor via iio_info causes system hangs as runtime PM tries to wake up an unresponsive sensor.

[453] hid-sensor-hub 0003:0408:5473.0003: Report latency attributes: ffffffff:ffffffff [453] hid-sensor-hub 0003:0408:5473.0003: common attributes: 5:1, 2:1, 3:1 ffffffff:ffffffff

Add this device to the HID ignore list since the sensor interface is non-functional by design and should not be exposed to userspace.(CVE-2025-21992)

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

dmaengine: idxd: fix memory leak in error handling path of idxd_alloc

Memory allocated for idxd is not freed if an error occurs during idxd_alloc(). To fix it, free the allocated memory in the reverse order of allocation before exiting the function in case of an error.(CVE-2025-38015)

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

nvmet-tcp: don't restore null skstatechange

queue->statechange is set as part of nvmettcpsetqueuesock(), but if the TCP connection isn't established when nvmettcpsetqueuesock() is called then queue->statechange isn't set and sock->sk->skstatechange isn't replaced.

As such we don't need to restore sock->sk->skstatechange if queue->state_change is NULL.

This avoids NULL pointer dereferences such as this:

[ 286.462026][ C0] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 286.462814][ C0] #PF: supervisor instruction fetch in kernel mode [ 286.463796][ C0] #PF: errorcode(0x0010) - not-present page [ 286.464392][ C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0 [ 286.465086][ C0] Oops: Oops: 0010 [#1] SMP KASAN PTI [ 286.465559][ C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary) [ 286.466393][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 [ 286.467147][ C0] RIP: 0010:0x0 [ 286.467420][ C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 286.467977][ C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246 [ 286.468425][ C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43 [ 286.469019][ C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100 [ 286.469545][ C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c [ 286.470072][ C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3 [ 286.470585][ C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268 [ 286.471070][ C0] FS: 00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000 [ 286.471644][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 286.472543][ C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0 [ 286.473500][ C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 286.474467][ C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 [ 286.475453][ C0] Call Trace: [ 286.476102][ C0] <IRQ> [ 286.476719][ C0] tcpfin+0x2bb/0x440 [ 286.477429][ C0] tcpdataqueue+0x190f/0x4e60 [ 286.478174][ C0] ? _buildskbaround+0x234/0x330 [ 286.478940][ C0] ? rcuiswatching+0x11/0xb0 [ 286.479659][ C0] ? _pfxtcpdataqueue+0x10/0x10 [ 286.480431][ C0] ? tcptryundoloss+0x640/0x6c0 [ 286.481196][ C0] ? seqcountlockdepreaderaccess.constprop.0+0x82/0x90 [ 286.482046][ C0] ? kvmclockgetcycles+0x14/0x30 [ 286.482769][ C0] ? ktimeget+0x66/0x150 [ 286.483433][ C0] ? rcuiswatching+0x11/0xb0 [ 286.484146][ C0] tcprcvestablished+0x6e4/0x2050 [ 286.484857][ C0] ? rcuiswatching+0x11/0xb0 [ 286.485523][ C0] ? ipv4dstcheck+0x160/0x2b0 [ 286.486203][ C0] ? _pfxtcprcvestablished+0x10/0x10 [ 286.486917][ C0] ? lockrelease+0x217/0x2c0 [ 286.487595][ C0] tcpv4dorcv+0x4d6/0x9b0 [ 286.488279][ C0] tcpv4rcv+0x2af8/0x3e30 [ 286.488904][ C0] ? rawlocaldeliver+0x51b/0xad0 [ 286.489551][ C0] ? rcuiswatching+0x11/0xb0 [ 286.490198][ C0] ? _pfxtcpv4rcv+0x10/0x10 [ 286.490813][ C0] ? _pfxrawlocaldeliver+0x10/0x10 [ 286.491487][ C0] ? _pfxnfconfirm+0x10/0x10 [nfconntrack] [ 286.492275][ C0] ? rcuiswatching+0x11/0xb0 [ 286.492900][ C0] ipprotocoldeliverrcu+0x8f/0x370 [ 286.493579][ C0] iplocaldeliverfinish+0x297/0x420 [ 286.494268][ C0] iplocaldeliver+0x168/0x430 [ 286.494867][ C0] ? _pfxiplocaldeliver+0x10/0x10 [ 286.495498][ C0] ? _pfxiplocaldeliverfinish+0x10/0x10 [ 286.496204][ C0] ? iprcvfinishcore+0x19a/0x1f20 [ 286.496806][ C0] ? lockrelease+0x217/0x2c0 [ 286.497414][ C0] iprcv+0x455/0x6e0 [ 286.497945][ C0] ? _pfxiprcv+0x10/0x10 [ ---truncated---(CVE-2025-38035)

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

atm: Revert atmaccounttx() if copyfromiter_full() fails.

In vccsendmsg(), we account skb->truesize to sk->skwmemalloc by atmaccount_tx().

It is expected to be reverted by atmpopraw() later called by vcc->dev->ops->send(vcc, skb).

However, vccsendmsg() misses the same revert when copyfromiterfull() fails, and then we will leak a socket.

Let's factorise the revert part as atmreturntx() and call it in the failure path.

Note that the corresponding skwmemalloc operation can be found in alloc_tx() as of the blamed commit.

$ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~(CVE-2025-38190)

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

fbcon: Make sure modelist not set on unregistered console

It looks like attempting to write to the "store_modes" sysfs node will run afoul of unregistered consoles:

UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28 index -1 is out of range for type 'fbinfo *[32]' ... fbconinfofromconsole+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122 fbconnewmodelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048 fbnewmodelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673 storemodes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113 devattr_store+0x55/0x80 drivers/base/core.c:2439

static struct fbinfo *fbconregisteredfb[FBMAX]; ... static signed char con2fbmap[MAXNRCONSOLES]; ... static struct fbinfo *fbconinfofromconsole(int console) ... return fbconregisteredfb[con2fbmap[console]];

If con2fbmap contains a -1 things go wrong here. Instead, return NULL, as callers of fbconinfofromconsole() are trying to compare against existing "info" pointers, so error handling should kick in correctly.(CVE-2025-38198)

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

i40e: fix MMIO write access to an invalid page in i40eclearhw

When the device sends a specific input, an integer underflow can occur, leading to MMIO write access to an invalid page.

Prevent the integer underflow by changing the type of related variables.(CVE-2025-38200)

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

configfs-tsm-report: Fix NULL dereference of tsm_ops

Unlike sysfs, the lifetime of configfs objects is controlled by userspace. There is no mechanism for the kernel to find and delete all created config-items. Instead, the configfs-tsm-report mechanism has an expectation that tsm_unregister() can happen at any time and cause established config-item access to start failing.

That expectation is not fully satisfied. While tsmreportread(), tsmreport{is,isbin}visible(), and tsmreportmakeitem() safely fail if tsmops have been unregistered, tsmreportprivlevelstore() tsmreportprovidershow() fail to check for ops registration. Add the missing checks for tsm_ops having been removed.

Now, in supporting the ability for tsmunregister() to always succeed, it leaves the problem of what to do with lingering config-items. The expectation is that the admin that arranges for the ->remove() (unbind) of the ${tsmarch}-guest driver is also responsible for deletion of all open config-items. Until that deletion happens, ->probe() (reload / bind) of the ${tsm_arch}-guest driver fails.

This allows for emergency shutdown / revocation of attestation interfaces, and requires coordinated restart.(CVE-2025-38210)

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

nvme-tcp: sanitize request list handling

Validate the request in nvmetcphandle_r2t() to ensure it's not part of any list, otherwise a malicious R2T PDU might inject a loop in request list processing.(CVE-2025-38264)

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

mpls: Use rcudereferencertnl() in mplsrouteinput_rcu().

As syzbot reported [0], mplsrouteinputrcu() can be called from mplsgetroute(), where is under RTNL.

net->mpls.platform_label is only updated under RTNL.

Let's use rcudereferencertnl() in mplsrouteinput_rcu() to silence the splat.

6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted

net/mpls/afmpls.c:84 suspicious rcudereference_check() usage!

other info that might help us debug this:

rcuscheduleractive = 2, debuglocks = 1 1 lock held by syz.2.4451/17730: #0: ffffffff9012a3e8 (rtnlmutex){+.+.}-{4:4}, at: rtnllock net/core/rtnetlink.c:80 [inline] #0: ffffffff9012a3e8 (rtnlmutex){+.+.}-{4:4}, at: rtnetlinkrcvmsg+0x371/0xe90 net/core/rtnetlink.c:6961

stack backtrace: CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x16c/0x1f0 lib/dumpstack.c:120 lockdeprcususpicious+0x166/0x260 kernel/locking/lockdep.c:6865 mplsrouteinputrcu+0x1d4/0x200 net/mpls/afmpls.c:84 mplsgetroute+0x621/0x1ea0 net/mpls/afmpls.c:2381 rtnetlinkrcvmsg+0x3c9/0xe90 net/core/rtnetlink.c:6964 netlinkrcvskb+0x16d/0x440 net/netlink/afnetlink.c:2534 netlinkunicastkernel net/netlink/afnetlink.c:1313 [inline] netlinkunicast+0x53a/0x7f0 net/netlink/afnetlink.c:1339 netlinksendmsg+0x8d1/0xdd0 net/netlink/afnetlink.c:1883 socksendmsgnosec net/socket.c:712 [inline] _socksendmsg net/socket.c:727 [inline] _syssendmsg+0xa98/0xc70 net/socket.c:2566 _syssendmsg+0x134/0x1d0 net/socket.c:2620 _syssendmmsg+0x200/0x420 net/socket.c:2709 _dosyssendmmsg net/socket.c:2736 [inline] _sesyssendmmsg net/socket.c:2733 [inline] _x64syssendmmsg+0x9c/0x100 net/socket.c:2733 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0x230 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f0a2818e969 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIGRAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969 RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268 </TASK>(CVE-2025-38324)

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

usb: typec: altmodes/displayport: do not index invalid pin_assignments

A poorly implemented DisplayPort Alt Mode port partner can indicate that its pin assignment capabilities are greater than the maximum value, DPPINASSIGNF. In this case, calls to pinassignment_show will cause a BRK exception due to an out of bounds array access.

Prevent for loop in pinassignmentshow from accessing invalid values in pinassignments by adding DPPINASSIGNMAX value in typecdp.h and using i < DPPINASSIGNMAX as a loop condition.(CVE-2025-38391)