After kernel update to 4.18.553.166, the server is locking up and requires a reboot

Rocky Linux Help & Support
1

Hello,

I started experiencing a server lockup issue after a security update that upgraded the kernel from 4.18.0-553.53.1.el8_10.x86_64 to 4.18.0-553.166.1.el8_10.x86_64. I updated several servers that night, but the one in question is unique because it connects to a CIFS share. In looking at the journalctl logs, I find the following entries:

kernel: watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [cifsd:2115]

kernel: Modules linked in: binfmt_misc cmac nls_utf8 cifs cifs_arc4 rdma_cm iw_cm ib_cm ib_core cifs_md4 dns_resolver nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock vfat fat intel_rapl_msr intel_rapl_common intel_uncore_frequency_common isst_if_mbox_msr isst_if_common nfit libnvdimm crc32_pclmul vmw_balloon rapl joydev pcspkr i2c_piix4 vmw_vmci xfs libcrc32c vmwgfx drm_ttm_helper ttm sr_mod cdrom drm_kms_helper sd_mod t10_pi crct10dif_pclmul syscopyarea sysfillrect crc32c_intel ata_generic sysimgblt sg drm ghash_clmulni_intel ahci ata_piix libahci serio_raw libata vmxnet3 vmw_pvscsi fuse

During one of the reboots, the CIFS mount failed. The server was stable overnight; I reconnected the mount in the morning, and the server locked up again about an hour later.

I booted the server with an older kernel, and it has been stable since then.

I searched but couldn’t find any other articles about a possible bug in that kernel with CIFS.

This is my first post here in the forums, so I’d appreciate any assistance.

Rocky Linux 8.10

Thanks!

Ira

2

It’s a bug, 4.18.0-553.170.1.el8_10.x86_64 has the fix. Red Hat is releasing it soon, don’t know when it will be available in Rocky Linux.

3

As per here: Rocky Releases - Documentation

So once RHEL releases it, we will have it in the timeframe mentioned above.

4

Thank you both for the information! That is very helpful, and I will keep an eye out for the updated kernel.

Ira

5

I’m not sure if this is the same issue, but when I updated our dev servers last Friday from / to:

4.18.0-553.163.1.el8_10.x86_64 (before)

4.18.0-553.168.1.el8_10.x86_64 (after)

most, but not all, servers that made any NFS mounts would hang during that step in the boot process. One server that didn’t have any NFS mounts in its /etc/fstab hung when automount mounted an NFS home directory. I was able to trace it down to NFSv4. If I force mount to use vers=3, then the hosts booted and mounted the NFS file systems without issue.

6

Might be worthwhile opening a bug here: https://bugs.rockylinux.org/ as now looks like not only cifs but nfs mounts also have issues would certainly suggest a kernel problem.

7

Redhat and Rocky have released 4.18.0-553.170.1.el8_10.x86_64 so you should be safe to update now

8

I installed 4.18.0-553.170.1.el8_10.x86_64 this morning and indeed, my issue is resolved.

I asked Claude about what might have fixed the issue and got this response:

Found it — and interestingly, none of the listed CVE fixes are NFS-related either (RDMA/siw, vmxnet3, liquidio, dm-integrity), but there’s a non-CVE bug fix in that same update that’s a very strong candidate:

request_key_auth use-after-free on every request-key upcall since 4.18.0-553.165.1 (regression from CVE-2026-63823 backport)

That’s significant for your case. Here’s why:

NFSv4 relies heavily on request-key upcalls. NFSv4 uses the kernel’s request_key() mechanism for both idmapper (uid/gid name mapping, via id_resolver/id_legacy key types — which you can actually see registering in your very first screenshot) and, if Kerberos is involved, for rpc.gssd ticket handling. NFSv3 does not use this path at all, since it’s all AUTH_SYS and doesn’t need name-to-id resolution via upcall.

Thanks!