OESA-2025-1928

The Linux Kernel, the operating system core itself.

Security Fix(es):

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)