Cloudanix VulnDB

CVE-2026-98793

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux networking bug can let certain programs cause connection tracking problems that may crash or destabilize the system.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Invalid NAT manipulation type passed via bpf_ct_set_nat_info() to nf_nat_setup_info() bypasses validation, triggering WARN_ON and leaving IPS_SRC_NAT_DONE set without initializing nat_bysource, causing conntrack cleanup to dereference an uninitialized hlist node.

Why it matters to the business

Linux systems performing network address translation or connection tracking can experience kernel warnings, instability, or crashes under load from untrusted BPF programs, increasing downtime risk for network-heavy workloads.

How an attack unfolds

An attacker with the ability to load BPF programs supplies an invalid NAT manipulation type to bpf_ct_set_nat_info; the missing check allows the bad value to reach nf_nat_setup_info, hitting the warning path and corrupting conntrack state if panic_on_warn is disabled.

How to fix it

Update to a kernel containing the upstream fix that validates the NAT manipulation type before calling nf_nat_setup_info and returns NF_DROP on invalid input; rebuild and deploy the patched kernel across all affected systems.

How to confirm the fix worked

Inspect kernel source or running binary for the added type check in bpf_ct_set_nat_info and confirm nf_nat_setup_info is no longer reachable with invalid values; test with a deliberately invalid NAT type and verify NF_DROP is returned instead of WARN_ON.

Typical attack path

  1. Obtain CAP_BPF or root privileges on target Linux host
  2. Load a crafted BPF program that calls bpf_ct_set_nat_info with an out-of-range NAT type
  3. Trigger netfilter processing that invokes the NAT setup path
  4. Observe or force conntrack cleanup to trigger the uninitialized hlist dereference

How to detect it

Search kernel logs for WARN_ON messages originating from nf_nat_setup_info, unexpected IPS_SRC_NAT_DONE flags without corresponding nat_bysource entries, and conntrack cleanup errors referencing uninitialized hlist nodes.

  • nf_nat_setup_info
  • bpf_ct_set_nat_info
  • IPS_SRC_NAT_DONE without nat_bysource

What your security team should do

  • Prioritize kernel updates on systems exposing netfilter/BPF to untrusted code
  • Disable unneeded BPF program loading via LSM or seccomp where feasible
  • Enable panic_on_warn temporarily on test systems to surface the issue during validation
  • Review EPSS and KEV status weekly given the low but non-zero exploit probability

The record

In the Linux kernel, the following vulnerability has been resolved: netfilter: bpf: reject invalid NAT manipulation types As bpf_ct_set_nat_info() is not validating the NAT manipulation type a wrong value can be passed directly to nf_nat_setup_info(). This triggers the WARN_ON() at nf_nat_setup_info() and if panic_on_warn isn't set, then IPS_SRC_NAT_DONE is set without adding nat_bysource and conntrack cleanup tries to unlink an uninitialized hlist node. Fix this by checking that NAT manipulation type is correct before calling nf_nat_setup_info(). In addition, if the WARN_ON is hit, return NF_DROP instead of continuing with the processing to avoid similar situations in the future.

Affected packages

Ecosystem Package Introduced Fixed