CVE-2026-53001

What it actually does

This Linux kernel netfilter/xtables flaw allows several xtables match extensions to be accepted outside the protocol families they were designed for. The affected match modules include xt_mac, xt_owner, xt_physdev, and xt_realm, with xt_realm intended only for IPv4. By allowing these matchers in inappropriate protocol contexts, the kernel can process rule state or packet metadata assumptions that are not valid for that family. Practical impact is most likely local kernel misbehavior, denial of service, or potential privilege-impacting behavior if an attacker can create or modify netfilter rules, typically requiring root or CAP_NET_ADMIN privileges, including inside some network namespace or container configurations.

Why it matters to the business

The primary operational risk is instability or compromise of Linux systems where untrusted users, workloads, containers, or automation can manipulate firewall or netfilter rules. Because the issue is in the kernel networking stack, a successful exploit could affect host availability and potentially weaken isolation boundaries. The currently low EPSS score and absence from the CISA KEV catalog indicate no broad confirmed exploitation at this time, but kernel flaws should still be prioritized on multi-tenant, containerized, or internet-facing Linux infrastructure because the blast radius can include the whole host.

How an attack unfolds

An attacker first needs the ability to load or modify netfilter/xtables rules, usually through root privileges, CAP_NET_ADMIN, a privileged container, or a network namespace configuration that grants firewall administration capability. They then attempt to install rules that use affected xtables match extensions in an unsupported protocol family or context, such as using match logic intended for IPv4/IPv6 where the kernel previously allowed broader NFPROTO_UNSPEC handling. When traffic or rule evaluation reaches the malformed or inappropriate match configuration, the kernel may operate on invalid assumptions about packet metadata or destination fields. Depending on kernel build, configuration, and surrounding code paths, this can result in a crash, denial of service, or other security-relevant kernel behavior. There is no public exploit maturity reported in the supplied data and no known KEV listing, so defenders should treat this primarily as a kernel hardening and privilege-boundary issue rather than evidence of active mass exploitation.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the upstream netfilter xtables fix restricting xt_mac, xt_owner, xt_physdev, and xt_realm to their valid protocol families. Because no exact fixed package versions were supplied, use the vendor advisory for the deployed distribution and kernel stream to identify the corrected kernel build. Reboot into the patched kernel after installation; live patching should only be considered sufficient if the vendor explicitly states that this specific netfilter fix is covered. As interim mitigation, restrict CAP_NET_ADMIN, avoid privileged containers, disable unprivileged user namespaces where operationally feasible, prevent untrusted workloads from managing iptables/nftables/ebtables rules, and unload or block unused xtables match modules where supported and safe for the environment.

How to confirm the fix worked

Confirm that systems are running a vendor kernel build that contains the fix, not merely that an updated package is installed but inactive. Validate with the running kernel version, vendor package changelog, and reboot status. Review whether local users, containers, orchestration agents, or service accounts have CAP_NET_ADMIN or privileged-container access. Test that unsupported combinations of xtables match extensions and non-inet protocol families are rejected by the patched kernel. Inventory use of xt_mac, xt_owner, xt_physdev, and xt_realm rules to ensure legitimate firewall behavior still works after patching.

Typical attack path

1. Obtain local access to a Linux host, container, or namespace with permission to administer netfilter rules.
2. Verify that xtables/netfilter tooling and the affected match extensions are available.
3. Create or modify firewall rules using xt_mac, xt_owner, xt_physdev, or xt_realm in an unsupported protocol-family context.
4. Trigger packet processing or rule evaluation against the crafted rule set.
5. Observe kernel instability, firewall malfunction, denial of service, or other unintended kernel behavior.
6. Use the outcome to disrupt the host or, if an exploit-specific primitive exists for the kernel build, attempt further privilege-boundary impact.

How to detect it

Detection should focus on evidence that a user or workload created unusual netfilter rules involving the affected xtables match modules, especially from containers, automation accounts, or unexpected interactive shells. Review auditd execve records, sudo logs, shell histories, endpoint telemetry, container runtime logs, Kubernetes audit logs, and systemd journal entries for execution of iptables, ip6tables, ebtables, arptables, nft, xtables-nft-multi, or xtables-legacy-multi with xt_mac, xt_owner, xt_physdev, or xt_realm-related options. Check kernel logs for oops, panic, WARN, BUG, general protection fault, NULL pointer dereference, soft lockup, or netfilter/xtables errors shortly after firewall rule changes. Compare current firewall rules against approved baselines using iptables-save, ip6tables-save, ebtables-save, arptables-save, and nft list ruleset. Because no public exploitation indicators or actor-specific artifacts are provided, detections should be behavior-based rather than relying on known malware or network IOCs.

• xt_mac
• xt_owner
• xt_physdev
• xt_realm
• -m mac
• -m owner
• -m physdev
• -m realm
• --mac-source
• --uid-owner
• --gid-owner
• --socket-exists
• --physdev-in
• --physdev-out
• --physdev-is-in
• --physdev-is-out
• --realm
• iptables -m owner
• ip6tables -m owner
• ebtables -m owner
• ebtables -m physdev
• arptables -m owner
• xtables-nft-multi
• xtables-legacy-multi
• nf_tables
• x_tables
• netfilter
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel panic
• soft lockup
• WARNING: CPU
• Oops:

What your security team should do

• Prioritize patching Linux hosts that run containers, multi-tenant workloads, CI/CD runners, VPN/network gateways, Kubernetes nodes, or services where non-admin users may gain namespace-level CAP_NET_ADMIN.
• Update and reboot affected Linux systems onto vendor-patched kernels; verify the active running kernel after maintenance.
• Reduce exposure by removing unnecessary CAP_NET_ADMIN grants and privileged-container configurations.
• Disable unprivileged user namespaces where feasible or apply distribution-specific controls that prevent untrusted users from creating network namespaces with firewall administration capabilities.
• Audit firewall-management automation and container runtimes for use of xt_mac, xt_owner, xt_physdev, and xt_realm match extensions.
• Monitor auditd, shell history, sudo logs, container runtime logs, and kernel logs for suspicious netfilter rule manipulation involving these match modules.
• Treat unexplained kernel oops, panic, soft lockup, or firewall rule failures around xtables/netfilter as potential exploitation signals until patched.
• Track vendor advisories for the exact fixed kernel versions applicable to each deployed distribution and kernel flavor.