CVE-2022-2586: nftables Cross-Table Use-After-Free in Linux Kernel

A subtle misstep in nftables object handling created a classic kernel-level use‑after‑free that has since rippled through distributions and cloud images: an nft object or expression could point to a set in a different nft table, and when that table was removed the remaining dangling reference could be evaluated — producing memory corruption with real-world consequences, from denial-of-service to local privilege escalation.

Background / Overview​

nftables is the Linux kernel’s modern packet‑filtering framework that replaced iptables as the canonical mechanism for firewall rules, NAT, sets, and complex rule logic. Like many kernel subsystems, nftables relies on careful object lifetime management: when a table or set is deleted the kernel must ensure every structure that referenced it is either removed or updated to avoid dereferencing freed memory.
CVE-2022-2586 arises from a failure to enforce that boundary. In short: an nft object or expression could reference a nft set that belonged to another nft table. When that referenced table was deleted, the referencing object was not always updated or invalidated, allowing the kernel to access freed memory. The result is a use‑after‑free (UAF) that can lead to crashes (availability loss) or, under skilled exploitation, arbitrary kernel memory corruption and privilege escalation.
Multiple vendors and security teams analyzed the problem and issued advisories and fixes; the kernel patch stream and distribution updates followed in the weeks after disclosure. Canonical, SUSE, Red Hat, Amazon (ALAS), and others cataloged the flaw and produced fixes for affected kernels and backported branches.

---

How the vulnerability works — a technical walkthrough​

The actors: tables, sets, objects, expressions​

nftables organizes filtering logic around the concepts of tables, which contain chains and sets. Objects and expressions inside rules evaluate against packet attributes and can reference sets (for membership testing, counters, etc.). Correct operation requires that references from an object to a set are valid and that deletion of a set or an entire table cannot leave behind a live pointer somewhere else in kernel space.

The flaw: cross‑table referencing and dangling pointers​

The vulnerable behavior allowed an nft object/expression to contain a reference to a set that belonged to a different table. When the referenced table was removed, the kernel freed the memory backing the set — but the referencing object remained. Subsequent evaluation of that object would dereference a pointer to freed memory: a textbook use‑after‑free. This is the exact condition tracked by CVE‑2022‑2586.

Exploitation primitives and real‑world feasibility​

Use‑after‑free bugs in the kernel are especially dangerous because they operate at the most privileged level. The exploitation model here typically follows a multi‑step approach:

• Create two tables (t1, t2).
• In t2 create a set S and populate it with data.
• In t1 create an object or rule that (improperly) references t2.S.
• Delete table t2, freeing the set’s memory while leaving the referencing object intact.
• Perform a kernel heap grooming / spraying operation to force the freed region to be reallocated with attacker‑controlled data.
• Trigger evaluation of the referencing object (by sending a packet that hits the rule), causing the kernel to use the attacker‑controlled data under the assumption it is a legitimate nft set structure.

When successful this sequence produces an arbitrary write/read primitive in kernel memory — a powerful lever for local privilege escalation. Practical exploitation requires the attacker to have the right local capabilities, and the exploit typically relies on techniques such as userfaultfd or other heap grooming tools to get reliable control over the reclaimed memory. Several public analyses and proof‑of‑concepts describe this pattern in detail for this CVE.

Precondition: privileges required​

Exploitation requires the ability to create and modify nftables objects. The canonical required privilege is CAP_NET_ADMIN within a network namespace or the relevant container/VM environment. In plain terms: an unprivileged remote user cannot trigger this across the network, but a local user with network administration capability, or a container/breakout context that grants CAP_NET_ADMIN, can. This requirement reduces the remote threat surface but still leaves many real attack paths intact — e.g., misconfigured containers, weak sudo rules, or compromised application sandboxes.

---

Impact: what attackers can and cannot do​

• Denial of Service (Availability): The easiest outcome is a crash. Triggering the UAF can cause kernel panics or oopses that bring down networking or the whole host, producing a total loss of availability for affected services until the host is restarted. This is a direct service disruption and can be exploited repeatedly. Multiple vendors list DoS as a primary impact.
• Local Privilege Escalation (Confidentiality / Integrity): With careful heap grooming an attacker with CAP_NET_ADMIN may use the UAF to corrupt kernel memory in a controlled way, potentially gaining arbitrary kernel read/write and escalating to root. Several advisories and public analyses describe working proof‑of‑concepts that show this is realistic, although the exploitation complexity is higher than a pure crash.
• Attack scope: The vulnerability is local in attack vector: it cannot be exploited directly over the network by a remote unauthenticated actor. However, because CAP_NET_ADMIN is commonly available in containerized workloads, virtualized guest environments, and certain service accounts, the local requirement does not eliminate serious practical risk.
• Persistence vs. transient effect: A successful crash is transient (requires restart), but a successful privilege escalation that plants a backdoor can produce a persistent compromise. Additionally, automated or repeated exploitation can render services unavailable for prolonged periods even without persistent compromise.

---

Timeline and attribution​

• The bug dates back historically in kernel commits: it was introduced by commit 958bee14d071 as part of an nf_tables transaction change, present since early kernel versions (the change appears in v3.16‑rc1 lineage). The flaw was reported by Team Orca of Sea Security in cooperation with Trend Micro’s Zero Day Initiative (ZDI) and tracked as ZDI‑CAN‑17470, then assigned CVE‑2022‑2586. Fixes were proposed and merged into the netfilter tree following disclosure.
• Distributors and cloud vendors rapidly produced patches and advisories after the kernel patch appeared: Red Hat and SUSE published CVE notices and updates, Canonical published Ubuntu fixes, and Amazon cataloged the issue in its ALAS advisories. Kernel stable branches were updated with backported fixes for supported stable trees.

---

Patching and mitigation status​

Kernel versions and fixes​

Vendor and upstream guidance point to fixes backported to multiple stable branches. Upstream kernels with patches include (examples reported by vendors):

• Linux 5.18.2 (and corresponding 5.15/5.10/5.4 stable backports) and later releases that include the netfilter fixes. Many distributions published explicit fixed kernel package versions (for example, Ubuntu fixed the jammy kernel in a particular update). Cloud distribution advisories also list the affected and fixed package versions.

Because kernel packaging and numbering vary by distribution, administrators should follow their distro security advisories or cloud provider ALAS/RHSA/SUSE notifications and apply the specific kernel package updates the vendor publishes. Amazon, Ubuntu, Red Hat, SUSE, and others issued distribution‑specific advisories and fixed packages.

Configuration and hardening steps (short‑term mitigations)​

While the correct remedy is to install vendor kernel updates, operators who cannot patch promptly can consider mitigation steps that reduce exposure:

• Restrict CAP_NET_ADMIN: audit which users, containers, and system components have CAP_NET_ADMIN and remove it where unnecessary. Use least privilege for container runtimes and orchestration defaults.
• Harden container runtimes and orchestrators: prevent containers from using host network namespaces or from gaining CAP_NET_ADMIN unless explicitly required.
• Audit nftables rules: avoid or tightly control dynamic table creation/deletion from untrusted contexts. Where possible design nft rulesets and automation so that table deletion is gated behind administrative review.
• Monitor for crashes and exploitation indicators: unexpected kernel oops, repeated panics, or unusual nft table manipulation from non‑trusted users should trigger incident investigation.

Note that these mitigations are compensating controls; they do not remove the underlying bug. The only comprehensive fix is to apply the kernel update from your vendor.

---

Why this bug matters to administrators and cloud operators​

Containers and capabilities make local kernel bugs dangerous​

Modern deployment models — containers, orchestrators, and multi‑tenant VMs — routinely blur the traditional “local user” boundary. Containers often run with elevated capabilities for practical reasons (network configuration, routing, etc.). An attacker who gains execution in a container and can obtain CAP_NET_ADMIN (or was granted it by default) may leverage this UAF to break out to the host.
This threat is not hypothetical: many exploit writeups for kernel UAFs focus on container escape as a high‑value target. Operators must reexamine how capabilities are assigned and defaulted in their container images and orchestration templates.

Kernel memory corruption equals reliability risk​

Even where privilege escalation is not achieved, kernel memory corruption can crash the host or disrupt networking, producing severe availability consequences in production environments. Web servers, load balancers, and network functions running on a vulnerable kernel are at risk of service outages if the bug is triggered, intentionally or accidentally. The availability impact alone justifies prioritizing the fix for many operations teams.

---

Responsible disclosure and the upstream response​

The vulnerability’s public handling followed coordinated disclosure norms. The discoverers worked with ZDI and upstream maintainers, fixes were proposed to netfilter-devel and applied in stable kernel trees, and distributors published corresponding advisories and package updates. The open source ecosystem’s rapid reaction minimized the window of mass exploitation, but the usual distribution lag (backports, QA cycles, cloud image refreshes) means some systems remained vulnerable for weeks or months until vendors shipped and operators installed updates.

---

Detection and threat hunting guidance​

Operators hunting for attempts to exploit CVE‑2022‑2586 should look for a combination of signals:

• Unexplained kernel oopses, panics, or repeated reboots that correlate with nftables activity.
• Unusual sequences of nft commands executed by non‑admin users or containers (table creation, cross‑table set manipulation, deletion).
• Sudden and repeated table deletion/creation patterns in logs, especially from service accounts or containerized workloads.
• Network namespace operations or container capability escalations that grant CAP_NET_ADMIN.
• Where allowed by policy, kernel Address Sanitizer (KASAN) or other kernel memory-checking tools may produce reproducible warnings if a PoC is triggered; public PoCs have been used to create KASAN reports.

If you detect suspicious signs, treat them as potential intrusions and follow incident response playbooks: isolate the host, preserve memory and logs, and perform forensic analysis before patching or rebooting (where feasible and safe).

---

Critical analysis — strengths and remaining risks​

Notable strengths in the ecosystem’s response​

• The vulnerability received prompt attention from upstream maintainers and distributors; patches were produced and backported to stable branches and packaged kernels.
• Multiple vendor advisories provide clear upgrade paths and fixed package versions for diverse environments (enterprise Linux, cloud images, and distributions).
• The public writeups and PoCs give defenders the technical detail needed to detect and mitigate risk proactively.

These actions demonstrate the advantage of open, coordinated disclosure: code owners, vendors, and defenders can act quickly once a serious kernel bug is reported.

Remaining and systemic risks​

• Privilege model fragility: The exploit requires CAP_NET_ADMIN, but that capability is still commonly granted in practice — especially in containerized workloads or automated tooling. The systemic tendency to over-provision capabilities limits the effectiveness of the “local only” vector as a practical mitigation.
• Patch throughput gap: Even when vendors publish fixes, the time between release and mass deployment (testing, rolling updates, cloud image refreshes) creates a vulnerability window. Attackers with local access to images or container orchestrators can attempt exploitation in that window.
• Complex exploitation but high payoff: The technical complexity of reliable exploitation is higher than a simple remote code execution, but the payoff — kernel code execution or host compromise — is significant enough to motivate skilled attackers and opportunistic exploitation where local access exists.
• Visibility and detection challenges: Unless teams instrument nftables command paths and container capability usage, attempts to set up the exploit chain can be subtle. Kernel memory corruption events may be attributed to hardware or driver issues rather than malicious activity.

Taken together, these risks mean CVE‑2022‑2586 should be treated as a high operational priority for environments that run untrusted code, containers, or expose administrative network capabilities to non‑trusted users.

---

Action checklist for system administrators (prioritized)​

• Apply vendor kernel updates immediately.
• Identify your distribution’s fixed packages (Red Hat, Ubuntu, SUSE, Amazon) and install the patched kernel packages and reboot during the next maintenance window. Confirm the exact package versions with your vendor advisory.
• Audit CAP_NET_ADMIN and related capabilities.
• Enumerate containers and services with CAP_NET_ADMIN, and remove the capability where not strictly required.
• Harden container runtime and orchestration defaults.
• Enforce default capability dropping for containers; disallow CAP_NET_ADMIN in multi‑tenant environments unless justified and reviewed.
• Monitor and alert on nft table lifecycle operations.
• Log nft commands and watch for unexpected create/delete sequences coming from unprivileged contexts.
• Prepare incident response playbooks for kernel UAFs.
• Have procedures to collect memory, kernel logs, and nft state snapshots when a suspicious crash occurs.
• Validate cloud/VM images.
• Ensure base images and orchestration node images in your CI/CD pipelines are rebuilt with updated kernels.
• Consider runtime memory checks for high‑value hosts.
• Where performance allows, use KASAN or other kernel memory-checking tools on staging hosts to detect regressions or attempted exploitation.

---

Final assessment​

CVE‑2022‑2586 is a high‑consequence memory‑corruption flaw in a privileged kernel subsystem that demonstrates how small design or validation lapses can escalate into serious operational and security problems. The vulnerability is local by vector but practical in many modern environments where containerized workloads and elevated capabilities are common. The open source community and distributors responded appropriately by backporting fixes and issuing advisories; however, effective risk reduction requires operators to move quickly, patch systems, and harden capabilities and container defaults.
For defenders, the lesson is both tactical and strategic: tactical in the immediate need to patch and audit capabilities; strategic in the need to minimize the blast radius of local kernel attack primitives by constraining capabilities, improving image hygiene, and instrumenting kernel and network configuration changes. In the long run, better defaults around capability assignment and tighter lifecycle management of kernel objects would reduce similar classes of vulnerability — but until those defaults are universally adopted, CVE‑2022‑2586 remains a stark reminder that kernel correctness is central to system security.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center