OESA-2025-1925

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

scsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGI

If lpfcissueels_flogi() fails and returns non-zero status, the node reference count is decremented to trigger the release of the nodelist structure. However, if there is a prior registration or dev-loss-evt work pending, the node may be released prematurely. When dev-loss-evt completes, the released node is referenced causing a use-after-free null pointer dereference.

Similarly, when processing non-zero ELS PLOGI completion status in lpfccmplelsplogi(), the ndlp flags are checked for a transport registration before triggering node removal. If dev-loss-evt work is pending, the node may be released prematurely and a subsequent call to lpfcdevlosstmo_handler() results in a use after free ndlp dereference.

Add test for pending dev-loss before decrementing the node reference count for FLOGI, PLOGI, PRLI, and ADISC handling.(CVE-2022-49535)

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

scsi: qla2xxx: Fix crash due to stale SRB access around I/O timeouts

Ensure SRB is returned during I/O timeout error escalation. If that is not possible fail the escalation path.

Following crash stack was seen:

BUG: unable to handle kernel paging request at 0000002f56aa90f8 IP: qlachkedifrxsadeletepending+0x14/0x30 [qla2xxx] Call Trace: ? qla2x00statusentry+0x19f/0x1c50 [qla2xxx] ? qla2x00startsp+0x116/0x1170 [qla2xxx] ? dmapoolalloc+0x1d6/0x210 ? mempoolalloc+0x54/0x130 ? qla24xxprocessresponsequeue+0x548/0x12b0 [qla2xxx] ? qladowork+0x2d/0x40 [qla2xxx] ? processonework+0x14c/0x390(CVE-2022-50098)

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:

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)

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

perf: Revert to requiring CAPSYSADMIN for uprobes

Jann reports that uprobes can be used destructively when used in the middle of an instruction. The kernel only verifies there is a valid instruction at the requested offset, but due to variable instruction length cannot determine if this is an instruction as seen by the intended execution stream.

Additionally, Mark Rutland notes that on architectures that mix data in the text segment (like arm64), a similar things can be done if the data word is 'mistaken' for an instruction.

As such, require CAPSYSADMIN for uprobes.(CVE-2025-38466)