Bug#1126957: kernel panic when repeatedly trying to mount an nfsv4 share with mtls and failing

From	Salvatore Bonaccorso <carnil@debian.org>
Newsgroups	linux.debian.bugs.dist, linux.debian.kernel
Subject	Bug#1126957: kernel panic when repeatedly trying to mount an nfsv4 share with mtls and failing
Date	2026-02-19 14:00 +0100
Message-ID	<MqbNn-1LiU-5@gated-at.bofh.it> (permalink)
References	<MqbNn-1LiU-7@gated-at.bofh.it> <MqbNn-1LiU-7@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Cross-posted to 2 groups.

Show all headers | View raw

Control: tags -1 + upstream
Control: found -1 6.18.12-1

Hi Norbert,

On Wed, Feb 04, 2026 at 04:59:10PM +0100, Norbert Zentai wrote:
> Package: linux-image-amd64
> Version: 6.17.13-1~bpo13+1
> 
> When I repeatedly mount an NFSv4 share using the following command:
> mount -t nfs4 -o xprtsec=mtls nfs-server.local:/rpool/demo-share /mnt
> 
> and the command fails with one of the following:
> mount.nfs4: access denied by server while mounting
> nfs-server.local:/rpool/demo-share
> OR
> mount.nfs4: Broken pipe for nfs-server.local:/rpool/demo-share on /mnt
> 
> after a couple of tries I receive the following kernel panic:
> 
> [   39.161785] kernel BUG at mm/slub.c:563!
> [   39.164131] Oops: invalid opcode: 0000 [#1] SMP PTI
> [   39.166674] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted
> 6.17.13+deb13-amd64 #1 PREEMPT(lazy)  Debian 6.17.13-1~bpo13+1
> [   39.172472] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
> [   39.178438] RIP: 0010:__slab_free+0x152/0x310
> [   39.180996] Code: 00 4c 89 ff e8 df 95 9c 00 48 8b 14 24 48 8b 4c 24 20
> 48 89 44 24 08 48 8b 03 48 c1 e8 09 83 e0 01 88 44 24 13 e9 71 ff ff ff <0f>
> 0b 66 41 f7 44 24 08 87 04 75 b3 eb a9 66 41 f7 44 24 08 87 04
> [   39.190660] RSP: 0018:ffffd19100003dc0 EFLAGS: 00010246
> [   39.193455] RAX: ffff8bf903e9f150 RBX: fffff9e7c00fa7c0 RCX:
> 000000000010000c
> [   39.197106] RDX: ffff8bf903e9f100 RSI: fffff9e7c00fa7c0 RDI:
> ffffd19100003e30
> [   39.200820] RBP: ffffd19100003e60 R08: 0000000000000001 R09:
> ffffffffab62d068
> [   39.204472] R10: 0000000000000002 R11: ffffffffad208100 R12:
> ffff8bf9011fe900
> [   39.208167] R13: ffff8bf903e9f100 R14: ffff8bf9011fe900 R15:
> ffffffffab62d068
> [   39.211793] FS:  0000000000000000(0000) GS:ffff8bf9cfdb6000(0000)
> knlGS:0000000000000000
> [   39.215868] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [   39.219011] CR2: 00007f7dfcbb71a0 CR3: 0000000008b12000 CR4:
> 00000000000006f0
> [   39.222866] Call Trace:
> [   39.224294]  <IRQ>
> [   39.225436]  ? rcu_do_batch+0x1c8/0x570
> [   39.227443]  kmem_cache_free+0x3a3/0x450
> [   39.229579]  ? free_uid+0x3c/0xc0
> [   39.231375]  rcu_do_batch+0x1c8/0x570
> [   39.233332]  ? rcu_do_batch+0x167/0x570
> [   39.235461]  rcu_core+0x175/0x350
> [   39.237280]  handle_softirqs+0xdf/0x320
> [   39.239381]  __irq_exit_rcu+0xbc/0xe0
> [   39.241366]  sysvec_apic_timer_interrupt+0x71/0x90
> [   39.243928]  </IRQ>
> [   39.245097]  <TASK>
> [   39.246375]  asm_sysvec_apic_timer_interrupt+0x1a/0x20
> [   39.249011] RIP: 0010:pv_native_safe_halt+0xf/0x20
> [   39.251544] Code: 20 d0 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90
> 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d 55 92 1a 00 fb f4 <e9>
> 3c 2a 01 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90
> [   39.262235] RSP: 0018:ffffffffad203e70 EFLAGS: 00000212
> [   39.265355] RAX: 0000000000000000 RBX: ffffffffad213080 RCX:
> ffff8bf90390b320
> [   39.269527] RDX: 4000000000000000 RSI: 0000000000000000 RDI:
> 000000000001979c
> [   39.273714] RBP: 0000000000000000 R08: 000000091e153ed8 R09:
> 0000000000000001
> [   39.277877] R10: 0000000000000000 R11: ffff8bf97dc1cd00 R12:
> 0000000000000000
> [   39.282054] R13: 0000000000000000 R14: 0000000000000000 R15:
> 000000000008a000
> [   39.286400]  default_idle+0x9/0x20
> [   39.287579]  default_idle_call+0x29/0x100
> [   39.288952]  do_idle+0x1f8/0x240
> [   39.290106]  cpu_startup_entry+0x29/0x30
> [   39.291428]  rest_init+0xe7/0xf0
> [   39.292561]  start_kernel+0x776/0x780
> [   39.293848]  x86_64_start_reservations+0x24/0x30
> [   39.295443]  x86_64_start_kernel+0x126/0x130
> [   39.297322]  common_startup_64+0x13e/0x141
> [   39.299047]  </TASK>
> [   39.300130] Modules linked in: tls rpcsec_gss_krb5 nfsv4 dns_resolver nfs
> lockd grace netfs cfg80211 rfkill 8021q garp stp llc mrp binfmt_misc
> aesni_intel pcspkr virtio_balloon button joydev evdev sg auth_rpcgss
> efi_pstore sunrpc configfs nfnetlink vsock_loopback
> vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock vmw_vmci
> qemu_fw_cfg ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2
> crc32c_cryptoapi hid_generic usbhid hid sr_mod cdrom uhci_hcd bochs
> ata_generic ehci_pci drm_client_lib sd_mod drm_shmem_helper ata_piix
> ehci_hcd drm_kms_helper usbcore virtio_net libata psmouse drm virtio_scsi
> net_failover scsi_mod i2c_piix4 failover i2c_smbus serio_raw usb_common
> scsi_common floppy
> [   39.321098] ---[ end trace 0000000000000000 ]---
> [   39.322977] RIP: 0010:__slab_free+0x152/0x310
> [   39.324762] Code: 00 4c 89 ff e8 df 95 9c 00 48 8b 14 24 48 8b 4c 24 20
> 48 89 44 24 08 48 8b 03 48 c1 e8 09 83 e0 01 88 44 24 13 e9 71 ff ff ff <0f>
> 0b 66 41 f7 44 24 08 87 04 75 b3 eb a9 66 41 f7 44 24 08 87 04
> [   39.331380] RSP: 0018:ffffd19100003dc0 EFLAGS: 00010246
> [   39.333381] RAX: ffff8bf903e9f150 RBX: fffff9e7c00fa7c0 RCX:
> 000000000010000c
> [   39.335985] RDX: ffff8bf903e9f100 RSI: fffff9e7c00fa7c0 RDI:
> ffffd19100003e30
> [   39.338598] RBP: ffffd19100003e60 R08: 0000000000000001 R09:
> ffffffffab62d068
> [   39.341237] R10: 0000000000000002 R11: ffffffffad208100 R12:
> ffff8bf9011fe900
> [   39.343830] R13: ffff8bf903e9f100 R14: ffff8bf9011fe900 R15:
> ffffffffab62d068
> [   39.346460] FS:  0000000000000000(0000) GS:ffff8bf9cfdb6000(0000)
> knlGS:0000000000000000
> [   39.349343] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [   39.351503] CR2: 00007f7dfcbb71a0 CR3: 0000000008b12000 CR4:
> 00000000000006f0
> [   39.354071] Kernel panic - not syncing: Fatal exception in interrupt
> [   39.356640] Kernel Offset: 0x2a200000 from 0xffffffff81000000 (relocation
> range: 0xffffffff80000000-0xffffffffbfffffff)
> [   39.360273] ---[ end Kernel panic - not syncing: Fatal exception in
> interrupt ]---
> 
> I originally tried this with the trixie kernel 6.12.63+deb13-amd64 and then
> with the backport to see if this bug has been resolved.
> 
> Output of uname -a:
> Linux nfs-client.local 6.17.13+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian
> 6.17.13-1~bpo13+1 (2025-12-28) x86_64 GNU/Linux
> 
> This bug is reproducible and you only need to try to mount less than 10
> times.
> 
> I found a similar kernel bug report:
> https://bugzilla.kernel.org/show_bug.cgi?id=24302
> 
> I am using the nfs-utils and ktls-utils package to set up NFS over mutual
> TLS. I was testing the system by providing a valid but not trusted client
> side TLS certificate and expecting the NFS server to not let me in.

I'm able to peproduce the issue with a modified script from the
ktls-utils autopkgtests as follows:

----cut---------cut---------cut---------cut---------cut---------cut-----
#!/bin/sh

# base directory for configuration
TLSHDDIR='/etc/tlshd'

# install required packages
apt-get -y install nfs-kernel-server ktls-utils

# Create CA private key and certificate
openssl genrsa -out "$TLSHDDIR/ca.key.priv.pem" 2048
cat >"$TLSHDDIR/ca.openssl.cnf" <<EOF
[ req ]
distinguished_name = req_dn
string_mask = utf8only
prompt = no
x509_extensions = req_ext

[ req_dn ]
commonName = ktls-utils test CA

[ req_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = critical, CA:true
EOF

openssl req -new -key "$TLSHDDIR/ca.key.priv.pem" \
        -utf8 -nodes -batch -x509 \
        -outform PEM -out "$TLSHDDIR/ca.x509.pem" \
        -config "$TLSHDDIR/ca.openssl.cnf"

# cleanup comments
sed -i '/^\[authenticate\.client\]/,$ { /=/d }' \
    /etc/tlshd/config

# Create certificate for server role signed with CA
# Create private key and certificate for role
openssl genrsa -out "$TLSHDDIR/server.key.priv.pem" 2048
cat >"$TLSHDDIR/server.openssl.cnf" <<EOF
[ req ]
distinguished_name = req_dn
string_mask = utf8only
prompt = no
x509_extensions = req_ext

[ req_dn ]
commonName = server.internal

[ req_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = critical, CA:false
extendedKeyUsage = critical, serverAuth
EOF

openssl req -new -key "$TLSHDDIR/server.key.priv.pem" \
	-out "$TLSHDDIR/server.req.pem" \
	-config "$TLSHDDIR/server.openssl.cnf"
openssl req -in "$TLSHDDIR/server.req.pem" \
	-copy_extensions copy \
	-CA "$TLSHDDIR/ca.x509.pem" \
	-CAkey "$TLSHDDIR/ca.key.priv.pem" \
	-utf8 -nodes -batch -x509 \
	-outform PEM -out "$TLSHDDIR/server.x509.pem"

# Create certificate for client role (self-signed)
cat > "$TLSHDDIR/client.openssl.cnf" <<EOF
[ req ]
distinguished_name = req_dn
string_mask = utf8only
prompt = no
x509_extensions = req_ext

[ req_dn ]
commonName = client.internal

[ req_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = critical, CA:false
extendedKeyUsage = critical, clientAuth
EOF

openssl req -noenc -x509 -newkey rsa -pkeyopt rsa_keygen_bits:2048 \
	-keyout "$TLSHDDIR/client.key.priv.pem" \
	-out "$TLSHDDIR/client.x509.pem" \
	-config "$TLSHDDIR/client.openssl.cnf"

# Update tlshd config
for role in server client ; do
    sed -i '/^\[authenticate\.'$role'\]/a\
x509.truststore='"$TLSHDDIR/ca.x509.pem"'\
x509.certificate='"$TLSHDDIR/$role.x509.pem"'\
x509.private_key='"$TLSHDDIR/$role.key.priv.pem" \
        /etc/tlshd/config
done

# Make server name resolvable
if ! grep -qw 'server\.internal' /etc/hosts; then
    cat >>/etc/hosts <<EOF
::1     server.internal client.internal
EOF
fi

# Restart tlshd with new config
systemctl restart tlshd.service

# Configure export
export_dir=/srv/server.internal
mkdir -p "$export_dir"
mkdir -p "/etc/exports.d"
cat > /etc/exports.d/server.internal.exports <<EOF
$export_dir localhost(no_root_squash,rw,xprtsec=mtls)
EOF
exportfs -a

# Try to mount
mount_dir=/media/server.internal
mkdir -p "$mount_dir"
! mountpoint "$mount_dir" || umount "$mount_dir"

# Trigger #1126957
while true ; do
	mount -t nfs -o nodev,nosuid,xprtsec=mtls "server.internal:$export_dir" "$mount_dir"
done
----cut---------cut---------cut---------cut---------cut---------cut-----

Before the kernel panic I see some processes with high CPU
utilisation:

   8982 root      20   0   36776   6256   3284 S  20.0   0.3   0:00.76 (udev-worker)
    321 root      20   0   36772  11748   8808 R  10.0   0.6   0:02.00 systemd-udevd
   3486 root      20   0    2944   2424   2244 S  10.0   0.1   0:00.13 rpc.idmapd
   8987 root      20   0   36776   6256   3284 S  10.0   0.3   0:00.48 (udev-worker)

Regards,
Salvatore

Back to linux.debian.kernel | Previous | Next | Find similar | Unroll thread

Thread

Bug#1126957: kernel panic when repeatedly trying to mount an nfsv4 share with mtls and failing Salvatore Bonaccorso <carnil@debian.org> - 2026-02-19 14:00 +0100

csiph-web