CVE-2025-38192: Linux kernel DoS from NAT46 eBPF protocol flip

A careless protocol flip inside an eBPF helper can crash a Linux host: CVE-2025-38192 is a kernel networking bug that occurs when a NAT46 BPF program changes an skb's protocol from IPv4 to IPv6 without clearing the associated destination (dst) pointer, producing a NULL pointer dereference and a reproducible kernel panic that results in denial of service. (cvefeed.io)

Background​

For years the Linux networking stack has relied on the socket buffer (struct sk_buff, or skb) and its associated metadata (including skb->protocol and skb_dst()) to route and process packets as they traverse kernel layers. The advent of extended Berkeley Packet Filter (eBPF) programs dramatically increased flexibility for in-kernel traffic manipulation — including NAT46 transformations that translate IPv4 to IPv6 on the fly. That power comes with risk: if a helper or BPF program mutates skb->protocol without adjusting or clearing other dependent metadata, later code paths can dereference stale pointers and crash the kernel. CVE-2025-38192 is a textbook example of that hazard. (cvefeed.io)
Published to public vulnerability feeds on July 4, 2025, the issue was addressed upstream in kernel patches that clear the destination (dst) metadata whenever a BPF helper changes skb->protocol, while attempting to preserve non-routing metadata dsts where appropriate. Multiple vendor advisories and vulnerability databases have tracked the issue and posted mitigation guidance and fixed package rollouts for affected distributions. (cvefeed.io)

---

What exactly is the bug?​

The trigger: NAT46 BPF programs that flip protocols​

At its core, CVE-2025-38192 is triggered when an ingress eBPF program — for example a NAT46 helper that converts IPv4 packets to IPv6 — modifies the packet header in-place and sets skb->protocol to the new family (ETH_P_IPV6). That action places the packet onto an IPv6 receive path that expects IPv6-specific routing metadata to be present. If the packet’s dst pointer is still an IPv4 routing entry (left over from an earlier output path), the IPv6 receive routines attempt to access IPv6-specific structures through that stale pointer. The mismatch can lead to a NULL pointer dereference inside ip6_rcv_core() and a full kernel panic. (cvefeed.io)

The crash signature​

Reports and stack traces published alongside advisories show a clear pattern: ip6_rcv_core → ipv6_rcv → process_backlog → napi_poll → net_rx_action → netif_rx → dev_loopback_xmit → ip_mc_finish_output → ip_mc_output → dst_output → ip_local_out → ip_send_skb → udp_send_skb → udp_sendmsg. In practice this means the kernel is attempting to loop a multicast packet back to the sending socket after an ingress BPF program changed the protocol, and the stale dst pointer causes the NULL dereference. Administrators will typically observe an immediate kernel panic or oops followed by service outage. (cvefeed.io)

---

Impact: who and what is affected​

• Affected component: Linux kernel networking stack, specifically code paths that handle multicast/loopback and BPF helpers that manipulate skb->protocol. (cvefeed.io)
• Primary impact: Denial of Service (DoS) — a local attacker or misconfigured BPF program can crash the kernel, causing a sustained or persistent loss of availability. In some vendor scoring this is rated as Important to Medium depending on environment and exposure.
• Exploitability: The vulnerability requires the presence of BPF functionality and the ability to load or run a NAT46 manipulator in an ingress context; that generally implies local access or privileged programmatic ability to insert BPF hooks. Public proof-of-concept exploits were not widely observed at disclosure time; however, the underlying primitive (NULL pointer dereference) is straightforward to trigger when the conditions exist. Vendors classify exploitation risk as mostly local but real for systems that permit untrusted eBPF programs. (cvefeed.io)
• Affected versions: Vendor trackers list a broad swath of Linux kernel series as affected in certain configurations — historically the issue surfaces across recent kernel releases that contain the relevant BPF helpers and multicast handling. Specific CPE ranges reported by aggregation feeds include kernels from 4.8 up through parts of the 6.x series where the behavior existed; vendors listed fixes for 6.12.35 and other stable branches. Administrators must consult their distribution's advisory for exact package-level information. Do not assume your kernel is unaffected based solely on major version. (cvefeed.io)

---

How vendors and upstream fixed it​

The upstream fix is conceptually simple and surgically applied: whenever a BPF helper (or other in-kernel helper) changes the skb->protocol from one family to another, the kernel must also clear the routing dst pointer (or at least validate/replace it for the new family). The patches introduced in the stable kernel tree explicitly clear the dst in all BPF helpers that convert protocol families, and they attempt to preserve metadata dsts that carry non-routing information rather than direct routing state. The goal is to prevent later IPv6 receive code from dereferencing an IPv4 routing pointer. (cvefeed.io)
Distribution vendors — including Amazon Linux, SUSE, Debian, and Red Hat downstream trackers — published advisories and backported fixes to their stable kernels. Some vendors noted pending fixes for older, long-term kernels where backporting requires extra testing; others issued immediate package updates for active branches. The timeline and availability of updates vary by distribution.

---

Detection and forensic signs​

Detecting CVE-2025-38192 in the wild is primarily a matter of log and crash analysis:

• Kernel oops or panic logs containing stack traces that include ip6_rcv_core() and references to net/ipv6/ip6_input.c are the most direct indicator. Those traces typically appear right before a restart or service outage. (cvefeed.io)
• Syslog, journalctl, or crashdump (kdump) files should be examined for repeated crashes that align with network input events or BPF program loads. If a crash occurs in response to particular ingress traffic or multicast loops, correlate with packet captures.
• Audit for eBPF program loads and privileged operations: systems that permit untrusted users to load complex BPF programs (for example container hosts with CAP_BPF or CAP_NET_ADMIN granted) are higher risk. Check auditing policies, container runtime privileges, and any orchestration tools that install BPF-based telemetry or NAT rules.

If you don't capture a full stack trace, pay close attention to patterns: sudden kernel restarts correlated with network events, multicast traffic patterns, or changes in BPF program configuration are suspicious.

---

Risk assessment: who should worry most​

• Cloud infrastructure and multi-tenant hosts: systems that let untrusted customers or processes attach eBPF programs to network devices are at elevated risk. BPF is powerful and widely used for observability, firewalling, and NAT; shared environments should be cautious with privileges.
• Hosts running custom NAT46 translation logic: environments that perform IPv4-to-IPv6 translation using in-kernel helpers or third-party BPF programs are directly in the threat model. Miswritten or aggressively transforming programs are the likely trigger. (cvefeed.io)
• Edge devices and routers using multicast: the bug’s crash path involves looping multicast packets back to the sending socket; devices that routinely handle multicast or implement loopback semantics may see a higher likelihood of encountering the condition. (cvefeed.io)
• Hardened single-tenant servers without BPF protections: even if BPF program loading is nominally restricted, misconfiguration or third-party software could introduce vulnerable code; audit privileged utilities and user namespaces.

---

Practical mitigation and remediation steps​

Follow this prioritized checklist to minimize exposure and remediate affected systems:

• Apply kernel updates from your distribution vendor immediately.
• Install vendor-supplied security updates that include the dst-clearing patches for BPF helpers. Distribution advisories (Amazon Linux ALAS, SUSE, Debian, Red Hat, Ubuntu) have listings and fixed packages; follow your distro-specific upgrade process.
• If you cannot patch immediately, mitigate exposure by tightening BPF capabilities.
• Remove or restrict CAP_BPF, CAP_NET_ADMIN, or other capabilities that permit untrusted users to load eBPF programs.
• Disable unneeded eBPF features via kernel boot parameters or seccomp profiles in container runtimes where possible.
• Audit and quarantine custom BPF programs.
• Inspect any in-house or third-party BPF code that manipulates protocol fields or performs NAT46 translations; fix code that flips skb->protocol without clearing or re-populating skb_dst() correctly.
• Use code review, static analysis for BPF bytecode, and runtime testing in isolated environments before deployment. (cvefeed.io)
• Monitor kernel logs and crash dumps.
• Enable persistent logging for kernel oops, collect kdump artifacts, and integrate detection rules in your SIEM for ip6_rcv_core/ip6_input.c traces. Rapid detection narrows downtime and improves postmortem analysis. (cvefeed.io)
• Network-level mitigations.
• Where practical, limit multicast reflection/loopback behavior or rate-limit multicast traffic until patches are deployed. Preventing the trigger traffic shape can reduce immediate risk. (cvefeed.io)
• Configuration for cloud and container environments.
• In Kubernetes, avoid granting privileged PodSecurityPolicy allowances that enable eBPF program loading. If your cluster requires eBPF-based observability, centralize those programs on a small number of trusted hosts rather than exposing broad loading rights to nodes.

---

Why this matters: the bigger technical lesson​

CVE-2025-38192 is a reminder of a subtle but recurring class of kernel bugs: metadata mismatches after in-place packet rewrites. The kernel maintains several distinct but interdependent data elements for packet processing: header bytes, protocol family, routing dst, and various per-packet metadata. Mutating one element (like skb->protocol) without reconciling the others creates latent inconsistencies that may only trigger far downstream in the execution path — often inside architecture- or protocol-specific code that expects consistent invariants. That separation of concerns made eBPF attractive and powerful; it also puts the onus on helpers and program authors to maintain those invariants. Upstream fixes that centralize or enforce invariant changes at helper boundaries are the correct engineering response. (cvefeed.io)

---

Operational guidance: patching strategy and testing​

• Prioritize production ingress/edge routers, cloud instance hosts, and machines running network observability/telemetry stacks that use eBPF.
• Test kernel updates in staging before mass rollout. The fix is small but kernel updates can ripple through drivers and backported subsystems; allocate time for functional verification, especially for network performance, multicast behavior, and BPF-dependent tooling.
• For immutable infrastructure (APIs, services that are restarted frequently), adopt a canary rollout: patch a subset of nodes, monitor crash metrics and network behavior, then roll patches cluster-wide.
• Maintain a rollback plan that includes preserved crash logs and packet captures for analysis in case post-patch regressions appear.

---

Detection signatures and SIEM rules to add now​

• Alert on kernel oopses that contain the string "ip6_rcv_core" or references to net/ipv6/ip6_input.c.
• Create correlation rules that link kernel panics with recent eBPF program loads or recent changes to tc/iptables/nftables configurations that could attach eBPF hooks.
• Watch for elevated multicast loopback activity or unexpected UDP socket loopbacks from the host itself, and correlate to UID/GID or container IDs that might have loaded BPF code. (cvefeed.io)

---

Responsible disclosure and upstream coordination​

Upstream kernel developers published patches to clear dsts in BPF helpers; vendor teams coordinated backports and advisories. As with many kernel vulnerabilities, disclosure and remediation required synchronizing stable kernel trees and distribution package maintainers. Organizations that operate custom kernels, embedded devices, or long-term support branches must track vendor-specific advisories because not all fixes are identical across branches. If you maintain in-house kernel patches, merge the upstream commits that address the issue or re-implement the dst-clearing semantics as a secure wrapper around any custom BPF helper functions. (cvefeed.io)

---

What attackers would need and realistic threat scenarios​

• Local adversary: to trigger CVE-2025-38192 reliably, an attacker typically needs the ability to run or install an ingress BPF program that performs NAT46 conversion — that implies local or containerized code execution plus capabilities to attach BPF hooks. In multi-tenant hosts or misconfigured containers, this is a realistic path. (cvefeed.io)
• Misconfiguration-induced outage: more likely than a targeted exploit campaign is accidental outages caused by a buggy in-house or third-party BPF program that flips protocols indiscriminately. Admins should assume misconfigurations are as dangerous as deliberate attacks.
• Remote exploitation: publicly available evidence at disclosure did not show RCE or remote exploitation without local program load capabilities; thus, immediate risk for remote-triggered, unauthenticated attacks is low. However, the potential exists for chained attacks in environments where untrusted code can be scheduled to run locally. Stay cautious. (cvefeed.io)

---

Recommended checklist for IT teams (actionable)​

• Inventory: Identify systems with eBPF usage, NAT46 workflows, or multicast-heavy workloads. Prioritize hosts where untrusted users can load BPF programs.
• Patch: Install vendor kernel updates that include the dst-clearing fix. Verify package versions against your vendor’s advisory.
• Restrict: Remove BPF and network capabilities from untrusted processes. Harden container runtimes and privilege models.
• Monitor: Add SIEM and kernel-oops alerts, collect kdump outputs, and set short detection windows for new crashes after patching. (cvefeed.io)
• Test: Run regression tests on network functionality (IPv4/IPv6 forwarding, multicast, BPF-based firewalls) after patching.

---

Final analysis: strengths of the response and residual risks​

The kernel fix for CVE-2025-38192 is narrowly targeted and conceptually robust: clear or revalidate routing metadata when you change the packet's protocol family. That is a low-risk, high-effectiveness change that preserves existing functionality while closing a clear invariant violation.
However, residual risks remain:

• Distribution lag: not all vendors can push fixes to older LTS or heavily customized kernels quickly; embedded and appliance vendors may require extended timelines. Organizations running custom or legacy kernels must either adopt vendor patches, backport the fixes themselves, or isolate affected hosts.
• Misbehaving BPF programs: the ecosystem is still learning safe BPF patterns. Automated code scanning and hardened helper semantics can help, but preventing all misuse requires operational controls (capability restrictions, code reviews) that many organizations have yet to adopt. (cvefeed.io)
• Detection gap: a NULL pointer dereference that results in an immediate kernel crash can be hard to exploit silently; but the lack of visible indicators before a panic makes proactive detection important. Without robust crash capture and correlation, root cause may be missed and reintroduced later.

---

CVE-2025-38192 underlines a perennial truth for kernel developers and operators: powerful in-kernel features (like eBPF) increase attack surface and accentuate the need for strict invariants at API boundaries. For administrators, the practical takeaway is simple and urgent — patch the kernel, audit who can load BPF programs, and treat eBPF transforms that change protocol families with extra scrutiny. Systems that do these three things will significantly reduce the risk of catastrophic downtime from this class of bug. (cvefeed.io)

---

Source: MSRC Security Update Guide - Microsoft Security Response Center