CVE-2025-71160
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2026-01-23

Last updated on: 2026-02-26

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: avoid chain re-validation if possible Hamza Mahfooz reports cpu soft lock-ups in nft_chain_validate(): watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547] [..] RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables] [..] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_table_validate+0x6b/0xb0 [nf_tables] nf_tables_validate+0x8b/0xa0 [nf_tables] nf_tables_commit+0x1df/0x1eb0 [nf_tables] [..] Currently nf_tables will traverse the entire table (chain graph), starting from the entry points (base chains), exploring all possible paths (chain jumps). But there are cases where we could avoid revalidation. Consider: 1 input -> j2 -> j3 2 input -> j2 -> j3 3 input -> j1 -> j2 -> j3 Then the second rule does not need to revalidate j2, and, by extension j3, because this was already checked during validation of the first rule. We need to validate it only for rule 3. This is needed because chain loop detection also ensures we do not exceed the jump stack: Just because we know that j2 is cycle free, its last jump might now exceed the allowed stack size. We also need to update all reachable chains with the new largest observed call depth. Care has to be taken to revalidate even if the chain depth won't be an issue: chain validation also ensures that expressions are not called from invalid base chains. For example, the masquerade expression can only be called from NAT postrouting base chains. Therefore we also need to keep record of the base chain context (type, hooknum) and revalidate if the chain becomes reachable from a different hook location.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-01-23
Last Modified
2026-02-26
Generated
2026-05-07
AI Q&A
2026-01-23
EPSS Evaluated
2026-05-05
NVD
CVE-2025-71160
Affected Vendors & Products
Showing 4 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.19
linux linux_kernel From 6.13 (inc) to 6.18.6 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.66 (exc)
linux linux_kernel From 4.18 (inc) to 6.6.121 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability involves the Linux kernel's netfilter nf_tables component, where the chain validation process (nft_chain_validate) can cause CPU soft lock-ups due to inefficient re-validation of chains. The issue arises because nf_tables traverses the entire chain graph for validation, even when some chains have already been validated. This leads to unnecessary repeated validations and potential CPU lock-ups. The fix avoids re-validating chains if they have already been checked, while ensuring that chain loop detection and base chain context validations are still correctly handled.


How can this vulnerability impact me? :

This vulnerability can cause CPU soft lock-ups, meaning the CPU can become stuck for extended periods (e.g., 27 seconds), leading to system performance degradation or unresponsiveness. This can affect systems using nftables for firewall or network packet filtering, potentially causing disruptions or denial of service due to the kernel's CPU being stuck during chain validation.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart