LiveActive security incident?Get immediate response
CVE Record

CVE-2025-71160: netfilter: nf_tables: avoid chain re-validation if possible

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.

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysisunknown

Security readout for executives and security teams

Plain-English summary

This Linux kernel issue can make nftables firewall validation consume CPU long enough to trigger soft lockups. The public record describes a resolved kernel bug, not a confirmed data theft or remote code execution issue. Business risk is mainly service degradation on systems where firewall rules are loaded or changed.

Executive priority

Treat this as a kernel stability and availability issue. Prioritize patching on firewall hosts, container platforms, and systems with automated rule updates. Escalate only if vendor guidance shows broader impact or local exposure allows untrusted rule changes.

Technical view

The flaw is in nf_tables chain validation. Revalidating already-visited chain paths can repeatedly traverse jump graphs during nftables commits, causing soft lockups in nft_chain_validate and related call paths. The fix avoids unnecessary revalidation while preserving checks for jump depth and base-chain context.

Likely exposure

Linux systems using nf_tables, including iptables-nft compatibility paths, are the relevant exposure. The source bundle lists Linux kernel versions and stable commits but does not provide distro package names, complete version ranges, or appliance-specific impact.

Exploitation context

The sources show a reported CPU soft lockup during iptables-nft-restore and state KEV is false. They do not establish active exploitation, remote exploitability, privilege requirements, or a public weaponized exploit.

Researcher notes

The fix appears focused on avoiding redundant graph validation while tracking maximum call depth and base-chain context. Evidence is incomplete for exploitability and severity; avoid assuming remote denial of service without vendor or upstream confirmation.

Mitigation direction

  • Update to a vendor kernel containing the referenced stable fixes.
  • Check distribution advisories for exact fixed package versions.
  • Restrict nftables and iptables-nft rule changes to trusted administrators.
  • Review firewall automation that submits complex nftables rules.
  • Monitor kernel logs for nf_tables soft lockup symptoms.

Validation and detection

  • Inventory Linux kernels running nf_tables or iptables-nft.
  • Compare installed kernels with vendor-fixed versions or listed stable commits.
  • Search logs for watchdog soft lockups in nft_chain_validate.
  • Confirm firewall rule deployment succeeds after patching in staging.
  • Verify only trusted users can alter nftables rules.
Prepared
Confidence
medium
Sources
6

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2025-71160 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
0ADP providers
5Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinuxa654de8fdc1815676ab750e70cab231fc814c29f, a654de8fdc1815676ab750e70cab231fc814c29f, a654de8fdc1815676ab750e70cab231fc814c29f, a654de8fdc1815676ab750e70cab231fc814c29funaffected
LinuxLinux4.18, 0, 6.6.121, 6.12.66, 6.18.6, 6.19affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.