Kernel panic in __nf_ct_delete_from_lists
Environment
- Red Hat Enterprise Linux 10.1 and earlier
- Red Hat Enterprise Linux 9.6 and earlier
- Firewall (iptables, nftables, firewalld) with connection tracking
- Firewall rules matching on
ct state nf_conntrackkernel module loaded
- Firewall rules matching on
Issue
- What is CVE-2025-38472?
- system repeated reboot
- Kernel crash
[exception RIP: __nf_ct_delete_from_lists+0xac] - Kernel crash
[exception RIP: __nf_ct_delete_from_lists+172] - vmcore with panic backtrace:
[exception RIP: __nf_ct_delete_from_lists+0xac]
#7 [ff6479a1995dca10] nf_ct_delete at ffffffffc14c0a51 [nf_conntrack]
#8 [ff6479a1995dca40] nf_ct_gc_expired at ffffffffc14c1049 [nf_conntrack]
#9 [ff6479a1995dca50] early_drop at ffffffffc14c14b3 [nf_conntrack]
#10 [ff6479a1995dca90] __nf_conntrack_alloc at ffffffffc14c16c4 [nf_conntrack]
#11 [ff6479a1995dcad0] init_conntrack.constprop.0 at ffffffffc14c1b0b [nf_conntrack]
#12 [ff6479a1995dcb40] resolve_normal_ct at ffffffffc14c2b10 [nf_conntrack]
#13 [ff6479a1995dcbb8] nf_conntrack_in at ffffffffc14c2cdf [nf_conntrack]
#14 [ff6479a1995dcc08] nf_hook_slow at ffffffffb2b2ca4c
#15 [ff6479a1995dcc38] nf_hook_slow_list at ffffffffb2b2cba1
#16 [ff6479a1995dcc90] ip_sublist_rcv at ffffffffb2b3c333
#17 [ff6479a1995dcd10] ip_list_rcv at ffffffffb2b3c775
#18 [ff6479a1995dcd70] __netif_receive_skb_list_core at ffffffffb2a8828f
#19 [ff6479a1995dcdf0] netif_receive_skb_list_internal at ffffffffb2a88976
#20 [ff6479a1995dce58] napi_complete_done at ffffffffb2a88c2e
#21 [ff6479a1995dce80] ice_napi_poll at ffffffffc0b47cb8 [ice]
#22 [ff6479a1995dcee0] __napi_poll at ffffffffb2a88e19
#23 [ff6479a1995dcf08] net_rx_action at ffffffffb2a8947c
#24 [ff6479a1995dcf88] handle_softirqs at ffffffffb2118a8e
#25 [ff6479a1995dcfe0] __irq_exit_rcu at ffffffffb2118d23
#26 [ff6479a1995dcff0] common_interrupt at ffffffffb2d21090
--- <IRQ stack> ---
Resolution
Upgrade to one of the following packages or later:
| Red Hat Enterprise Linux release | Package | Errata |
|---|---|---|
| 10.1 | kernel-6.12.0-124.8.1.el10_1 | RHSA-2025:20095 |
| 10.0.z | kernel-6.12.0-55.30.1.el10_0 | RHSA-2025:15005 |
| 9.7 | kernel-5.14.0-611.5.1.el9_7 | RHSA-2025:20518 |
| 9.6.z | kernel-5.14.0-570.49.1.el9_6 | RHSA-2025:16880 |
| 9.4.z | kernel-5.14.0-427.92.1.el9_4 | RHSA-2025:17241 |
| 9.2.z | kernel-5.14.0-284.140.1.el9_2 | RHSA-2025:17122 |
Workaround - Firewall Rules
Temporarily remove any firewall rules which match on ct state to avoid connection tracking
Temporarily add firewall rules which match all traffic with notrack verdict to avoid connection tracking.
Unload the nf_conntrack kernel module and prevent it from being loaded. Please see:
This workaround will be easier if you use nftables firewall rules.
It will be more difficult to do this workaround with firewalld. Consider writing nftables rules instead.
Mitigation for Some Environments
On non-containerized deployments of Red Hat Enterprise Linux, it is possible for a non-root user to intentionally trigger this panic with user namespaces.
On containerized deployments, such as Red Hat OpenShift Container Platform, Podman hosts, or Docker hosts do not use this mitigation as user namespace functionality is required for regular operation.
However, if you don't user container and have untrusted non-root users running commands in your environment, you can disable user namespaces to prevent users from intentionally causing this panic.
# echo "user.max_user_namespaces=0" > /etc/sysctl.d/userns.conf
# sysctl -p /etc/sysctl.d/userns.conf
Root Cause
This is theorised to be a race between three CPUs all handling the same firewall connection tracking entry, which starts with:
- CPU x finds a conntrack entry, which is expired, so deletes it
- CPU y finds the same conntrack entry before it is deleted
- CPU z creates a new conntrack entry, reusing the freed memory from CPU x
The conntrack entry is then used in a half-initialised state full of garbage data, resulting in this panic.
This issue is reported to Red Hat as CVE-2025-38472.
The following upstream commit describes the race condition in more detail and should address the bug:
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.