CVE-2022-39190

What it actually does

Binding to an already-bound nf_tables chain in net/netfilter/nf_tables_api.c triggers a kernel denial of service, typically via use-after-free or invalid state leading to crash or panic.

Why it matters to the business

Local users on affected Linux systems can crash the kernel, causing unplanned reboots, loss of network connectivity, and service interruption until the host recovers.

How an attack unfolds

An attacker with local access obtains privileges sufficient to interact with nf_tables, locates or creates a chain that is already bound, and issues a second bind operation that the kernel mishandles, resulting in denial of service.

How to fix it

Upgrade the Linux kernel to a version containing commit e02f0d3970404bfea385b6edb86f2d936db0ea2b or later; rebuild and reboot all affected hosts with the patched kernel.

How to confirm the fix worked

Confirm the running kernel contains commit e02f0d3970404bfea385b6edb86f2d936db0ea2b or a backport that prevents duplicate binds; attempt the bind operation in a test environment and verify no crash occurs.

Typical attack path

1. Obtain local shell or code execution on target Linux host
2. Acquire capabilities or root privileges needed to manipulate nf_tables
3. Identify or create an nf_tables chain that is already bound to a table
4. Issue a duplicate bind operation against the same chain
5. Trigger kernel crash or hang

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for nf_tables or netfilter oops/panic messages around the time of suspected incidents; correlate with process execution of nft or iptables commands by privileged users.

What your security team should do

• Prioritize patching kernel packages on all internet-facing and multi-tenant systems within the next maintenance window
• Restrict unprivileged users from nf_tables operations via capabilities or seccomp where possible
• Monitor kernel crash logs for nf_tables-related oops or panic entries until patches are deployed