CVE-2026-52998

What it actually does

This flaw is a Linux kernel denial-of-service vulnerability in the netfilter operating-system fingerprinting path, specifically nfnetlink_osf TTL handling. The vulnerable code can dereference skb->dev without first confirming that the packet has an associated network device. If a packet reaches the affected TTL-check logic in a context where that pointer is NULL, the kernel may trigger an oops or panic, disrupting packet processing or crashing the system depending on kernel configuration. Exposure is most relevant on systems using netfilter OS fingerprinting rules through iptables/nftables or where the nfnetlink_osf/OSF match functionality is loaded and reachable by network traffic.

Why it matters to the business

Successful exploitation can cause service interruption on affected Linux systems by crashing the kernel or destabilizing networking. For internet-facing gateways, firewalls, load balancers, container hosts, Kubernetes nodes, VPN endpoints, and other network-heavy Linux servers, this may result in loss of connectivity, application outages, failover events, or degraded availability. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no known public exploit maturity, and has a low EPSS score, so urgency is lower than actively exploited kernel flaws; however, kernel-level denial-of-service issues should still be remediated promptly on exposed or high-availability systems.

How an attack unfolds

An attacker first identifies a Linux system whose firewall or packet filtering configuration uses netfilter OS fingerprinting functionality. The attacker then sends network packets that are processed by the OSF TTL-check path. In vulnerable kernels, that code assumes the packet has a valid network device pointer and attempts to access it. If the packet is processed in a context where skb->dev is NULL, the kernel performs an invalid memory access. The result is typically a kernel oops and, depending on system settings such as panic_on_oops, may escalate to a full kernel panic and reboot. The practical outcome is denial of service rather than code execution or data theft.

How to fix it

Apply the Linux kernel update from the relevant distribution or vendor that includes the netfilter nfnetlink_osf fix for the NULL dereference in nf_osf_ttl. Because no exact affected product list or fixed package versions were provided, use vendor advisories for the specific distribution and kernel stream in use. Prioritize externally reachable systems, firewalls, routing hosts, container nodes, and any Linux systems using iptables/nftables OS fingerprinting. If immediate patching is not possible, reduce exposure by disabling or removing netfilter OSF matching rules, unloading unused OSF-related modules where feasible, and limiting untrusted traffic paths to hosts that rely on OS fingerprinting firewall rules. Avoid relying on mitigation alone for long-term risk reduction because this is kernel code and behavior can vary by distribution configuration.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor fix for the nfnetlink_osf TTL NULL dereference. Check the active kernel with uname -r and compare it against the distribution’s fixed advisory version. Confirm the system was rebooted into the updated kernel, not merely that the package was installed. Review firewall configuration for OSF usage with iptables-save, ip6tables-save, nft list ruleset, and loaded-module checks such as lsmod for nfnetlink_osf or xt_osf. After patching, monitor kernel logs for absence of new NULL pointer dereference/oops messages referencing nf_osf_ttl, nfnetlink_osf, or OSF matching during normal traffic. In staging, validate that OS fingerprinting firewall rules still function as expected after the upgrade or after temporary removal.

Typical attack path

1. Identify a Linux host, firewall, gateway, or container/networking node that may use netfilter OS fingerprinting rules.
2. Send traffic that is evaluated by an iptables/nftables OSF match or nfnetlink_osf TTL-check path.
3. Cause the vulnerable nf_osf_ttl logic to evaluate a packet without a valid skb->dev pointer.
4. Trigger a NULL pointer dereference in kernel space.
5. Cause a kernel oops, network stack disruption, service instability, or full system panic/reboot depending on kernel settings.

How to detect it

To determine whether this was already exploited, review kernel and system logs for crashes, oopses, or reboots occurring during inbound network activity, especially on systems using OS fingerprinting firewall rules. Relevant sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump repositories, kdump/vmcore records, netconsole logs, hypervisor console logs, and availability monitoring around unexplained node reboots. Look for stack traces that include nf_osf_ttl, nfnetlink_osf, xt_osf, netfilter, or NULL pointer dereference messages. Correlate timestamps with firewall logs, packet captures, load balancer health-check failures, interface resets, kernel panic events, and automated failovers. There may be no durable file artifact beyond kernel logs or crash dumps, and packet-level attribution may be difficult unless network telemetry was retained.

• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• NULL pointer dereference
• nf_osf_ttl
• nfnetlink_osf
• xt_osf
• osf ttl
• IP: nf_osf_ttl
• RIP: nf_osf_ttl
• Call Trace: nf_osf_ttl
• kernel panic - not syncing
• Oops: 0000
• panic_on_oops
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• journalctl -k
• /proc/vmcore
• iptables -m osf
• --genre
• nft list ruleset
• lsmod | grep nfnetlink_osf
• lsmod | grep xt_osf

What your security team should do

• Inventory Linux systems that use netfilter OS fingerprinting rules, especially internet-facing firewalls, gateways, container hosts, and high-availability network nodes.
• Patch affected systems using the appropriate vendor kernel update and reboot into the fixed kernel.
• Prioritize systems where nfnetlink_osf or xt_osf is loaded, or where iptables/nftables rules reference OSF matching.
• If patching is delayed, remove or disable OSF match rules and unload unused OSF-related kernel modules where operationally safe.
• Add monitoring for kernel oops/panic events referencing nf_osf_ttl, nfnetlink_osf, xt_osf, NULL pointer dereference, or network-filtering paths.
• Review panic_on_oops and crash-recovery settings to understand whether exploitation would cause a reboot or partial service degradation.
• Because the vulnerability is not known to be exploited and has low EPSS, treat it as medium operational urgency unless the affected host is exposed, mission-critical, or part of a network control plane.