Re: NULL indirect call in xs_read_stream_request, leaked socket lock wedges all NFS traffic

[Kris Globtrotter]

On Sat, Oct 31, 2026 at 4:23 PM Roland Wunderlich <roland@xxxxxxxxx> wrote:
> Kris: which microcode revision and stepping are you on
> (grep -m1 -E 'stepping|microcode' /proc/cpuinfo)? Could you try
> clearcpuid=fsrm?

Hi Roland,

Answers to your questions, plus a third oops from this machine that
was never posted anywhere.

Hardware: ASRock Rack W680 WS, BIOS 21.12 (10/25/2024), i5-13500
(06-bf-02: model 191, stepping 2), 128 GB DDR5 ECC, bare metal
Proxmox. NFS client is the host, server is a TrueNAS VM on the same
host, NFSv4.2 over TCP via a virtio bridge. Workload: a couple of
dozen containers doing many small, concurrent RPCs on the mount
(metadata, random reads), not sequential whole-file reads.

Microcode: 0x3d, unchanged on all 30 boots since 2026-08-02 (journal
"microcode: Current revision: 0x0000003d" on every one). The BIOS
ships 0x35 ("Updated early from: 0x00000035"); 0x3d is early-loaded
from Debian's intel-microcode 3.20251111.1~deb13u1, i.e. the November
2025 release, not 20260210. So all three of my oopses happened on
0x3d, and the 52 days without an oops since then are on the same
0x3d. Microcode is not a variable here. Whether 0x3d for 06-bf
corresponds to your 0x3a or 0x3e for 06-97, I don't know.

Timeline (all on 7.0.14-12-pve):
  #1  2026-08-24 11:23  Oops 0011, RIP == R12 (stack address, NX)
                        -- the one on the Proxmox forum
  #2  2026-08-27 02:56  Oops 0010, RIP = 0x8
                        -- the one that opened this thread
  #3  2026-09-10 05:17  Oops 0011, RIP == R12 again, full trace below

Since #3 the host has run 7.0.14-15-pve (from 2026-09-10 11:22) and
7.0.14-20-pve (from 2026-10-10): 52 days, 0 oopses, same workload,
same microcode, same NFS mount options. The kernel change happened
six hours after #3, so I can't separate "kernel" from "coincidence";
I'm not claiming -15/-20 fixed anything. The -13/-14 changelogs had
nothing touching sunrpc, which is why I had stayed on -12 until #3.

Oops #3 has the same register pattern you describe:

  RCX = 0
  RAX = RDX = R14 = R15 = 0x1000
  RDI = ffff8dc102fe1000  (page-aligned destination + 0x1000)
  RSI = ffff8dbdd3c1106c, R08 = ffff8dbdd3c1006c  (source + 0x1000)
  RIP = R12 = ffffd2d32e31bd68  (a kernel stack address -> NX fault)
  first trace entry _copy_to_iter+0x27f

so the 4 KiB copy had completed and execution continued at the value
of R12 instead of returning.

Not thermal as far as I can tell: CPU package 30-55 C in normal
operation, no thermal events in the journal around any of the three,
and #3 happened at 05:17 under night load.

I haven't run clearcpuid=fsrm: with no reproduction in 52 days a
host-side test would not be informative, and an oops on the host
wedges production NFS. If the x86 people think a third data point
matters, I can run your dd loop in a throwaway KVM guest on this host
against the same NFS server, 24-48 h with and without clearcpuid=fsrm.
Say so and I'll set it up.

Thanks,
Kris

----------------------------------------------------------------------
Oops #3 (2026-09-10 05:17 CEST, 7.0.14-12-pve, bare metal)
----------------------------------------------------------------------
kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
BUG: unable to handle page fault for address: ffffd2d32e31bd68
#PF: supervisor instruction fetch in kernel mode
#PF: error_code(0x0011) - permissions violation
PGD 100000067 P4D 100000067 PUD 1008d6067 PMD 19278a067 PTE 800000194a6f3163
Oops: Oops: 0011 [#1] SMP NOPTI
CPU: 16 UID: 0 PID: 1935713 Comm: kworker/u80:6 Tainted: P           O
       7.0.14-12-pve #1 PREEMPT(lazy)
Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE
Hardware name:  W680 WS/W680 WS, BIOS 21.12 10/25/2024
Workqueue: xprtiod xs_stream_data_receive_workfn [sunrpc]
RIP: 0010:0xffffd2d32e31bd68
Code: ff ff 00 fc 08 00 ac 8d ff ff 10 c6 b2 cb bc 8d ff ff 0c 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <02> 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0 5b 70 bf 8d
RSP: 0000:ffffd2d32e31b988 EFLAGS: 00010286
RAX: 0000000000001000 RBX: 0000000000006f94 RCX: 0000000000000000
RDX: 0000000000001000 RSI: ffff8dbdd3c1106c RDI: ffff8dc102fe1000
RBP: ffffd2d32e31ba18 R08: ffff8dbdd3c1006c R09: 0000000000000000
R10: 0000000000000000 R11: ffff8dac041d6100 R12: ffffd2d32e31bd68
R13: ffff8dbf705bf000 R14: 0000000000001000 R15: 0000000000001000
FS:  0000000000000000(0000) GS:ffff8dcb5db0e000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffd2d32e31bd68 CR3: 000000130c63e005 CR4: 0000000000f72ef0
PKRU: 55555554
Call Trace:
 <TASK>
 ? _copy_to_iter+0x27f/0x610
 ? __ip_queue_xmit+0x19b/0x4e0
 ? __check_object_size+0xb4/0x270
 ? __pfx_simple_copy_to_iter+0x10/0x10
 simple_copy_to_iter+0x3e/0x70
 __skb_datagram_iter+0x1b8/0x2f0
 ? __pfx_simple_copy_to_iter+0x10/0x10
 skb_copy_datagram_iter+0x39/0xc0
 tcp_recvmsg_locked+0x836/0xb00
 ? __tcp_send_ack.part.0+0xf3/0x1f0
 tcp_recvmsg+0x83/0x1f0
 inet_recvmsg+0x51/0x130
 ? apparmor_socket_recvmsg+0x64/0x80
 ? security_socket_recvmsg+0x70/0x1e0
 sock_recvmsg+0xb6/0xc0
 xs_sock_recvmsg.constprop.0+0x2c/0xa0 [sunrpc]
 xs_read_stream_request.constprop.0+0x255/0x4f0 [sunrpc]
 xs_read_stream.constprop.0+0x2b3/0x450 [sunrpc]
 xs_stream_data_receive_workfn+0x71/0x160 [sunrpc]
 process_one_work+0x1a9/0x3c0
 worker_thread+0x1b8/0x360
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xf7/0x130
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2da/0x3a0
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 </TASK>
note: kworker/u80:6[1935713] exited with irqs disabled

Blocked worker three hours later (kworker/u80:4+rpciod):
[<0>] __lock_sock+0x7c/0xd0
[<0>] lock_sock_nested+0x54/0x60
[<0>] tcp_sock_set_cork+0x19/0x60
[<0>] xs_tcp_send_request+0xe3/0x360 [sunrpc]
[<0>] xprt_transmit+0x1be/0x4b0 [sunrpc]
[<0>] call_transmit+0x7f/0xa0 [sunrpc]
[<0>] __rpc_execute+0xbb/0x4e0 [sunrpc]
[<0>] rpc_async_schedule+0x33/0x50 [sunrpc]