CVE-2026-98381

Executive Summary

CVE-2026-98381 is a use-after-free condition in the Linux kernel veth (virtual Ethernet) driver. During a channel resize (veth_set_channels), XDP resources belonging to removed RX queues are torn down without clearing the per-queue program pointer rq->xdp_prog; a subsequent bpf_prog_put() frees the program while stale queue references persist, and a later channel increase can re-enable NAPI and execute the released program. The impact is a kernel page fault and panic ("Fatal exception in interrupt"), i.e., a local denial of service, reportedly also observable as a use-after-free that can run freed BPF program memory. Affected systems are Linux hosts operating veth interfaces in container/network-namespace deployments where privileged callers can invoke channel reconfiguration.

Technical Analysis

The veth driver is the standard Linux virtual Ethernet pair used to connect network namespaces — most visibly as the host-side peer of container interfaces (Docker, podman, Kubernetes pod veth pairs) and in virtual switching topologies. It supports XDP, allowing BPF programs to be attached per device and per receive queue, with a program pointer cached in the RX queue descriptor (rq->xdp_prog).

The defect described is a lifecycle-ordering flaw:

1. veth_set_channels() resizes the NIC's channel/queue count. Use of ethtool -L/ETHTOOL_SCHANNELS is the user-visible trigger surface.
2. When RX queues are removed by a shrink, XDP resources for those queues are torn down, but rq->xdp_prog is not cleared. The stale pointer therefore survives the teardown.
3. The XDP program is then detached or replaced. bpf_prog_put() drops the last reference and frees the program object. The queues that were removed during the shrink still hold the previous pointer — a dangling reference to freed memory.
4. A later channel increase re-enables those queues and their NAPI instances. NAPI polling then dispatches into the XDP receive path using the stale program pointer, executing a freed BPF program.

The published crash trace localizes the failure to the XDP receive fast path:

• RIP: veth_xdp_rcv_skb (with inlined include/linux/filter.h:779, include/net/xdp.h:696, and drivers/net/veth.c:820)
• Call trace: veth_xdp_rcv (drivers/net/veth.c:941) → veth_poll (drivers/net/veth.c:986) → __napi_poll (net/core/dev.c:7787) → net_rx_action (net/core/dev.c:7850, net/core/dev.c:8007) → handle_softirqs (kernel/softirq.c:645)
• Result: BUG: unable to handle page fault for address: ffffc90000256048 under Oops: 0000 [#1] SMP KASAN NOPTI, terminating in Kernel panic - not syncing: Fatal exception in interrupt.

The fault address (ffffc90000256048) lies in the vmalloc range and is consistent with a KASAN-instrumented access to reclaimed/freed BPF program memory, but the description does not state the exact dereferenced field, so no finer determination is asserted here. The KASAN NOPTI flag indicates the crash was observed on a KASAN-enabled kernel; KASAN makes the dangling access deterministically fatal, while on non-KASAN systems the freed slab may be reallocated and the stale pointer could be redirected to attacker-influenced data.

Attack surface and access requirements. The trigger is a privileged local operation: channel reconfiguration of a veth interface, plus XDP program attach/detach or replacement on that interface. Both require CAP_NET_ADMIN in the relevant network namespace. In container environments this is meaningful: CAP_NET_ADMIN is a commonly granted capability (and is granted by default to root inside many privileged or --cap-add=NET_ADMIN containers), so a workload holding it can cause a host kernel panic, violating the expected container isolation model. This requires local access within an appropriate namespace, which is reflected in the assumed AV:L / AC:H vector.

Why the race/lifecycle window exists. The shrink path invalidates queue slots and frees XDP state but leaves the cached per-queue program pointer populated; the free of the BPF program itself is driven by a separate detach/replace event. The two operations are only dangerous in combination — shrink → detach/replace → grow — which is why the condition is considered high complexity rather than trivially repeatable.

No specific fixing commit, patch hunk, or backported version string was supplied with the CVE data, so no statement can be made about which stable trees contain a fix.

Exploitation Scenarios

No public proof-of-concept or exploit code is available for CVE-2026-98381, and no weaponized exploit has been observed in the wild. The chain below is therefore a vulnerability-class-derived sequence (privileged lifecycle manipulation producing a use-after-free in the receive path), not a validated exploit. All symbol names used are those appearing verbatim in the NVD description and crash trace.

1. Reconnaissance / preconditions. A local actor must already be operating with CAP_NET_ADMIN inside a network namespace containing a veth interface (or capable of creating one), and must be able to attach/detach/replace XDP programs on it via the BPF system call path. Discovery is classification-based rather than network-based: identify kernel builds where veth + XDP + channel reconfiguration are usable together (container hosts, CI runners, nested virtualized network labs). This is not remotely scannable, hence no Shodan surface.

2. Triggering the flaw class. The actor performs a sequence of local netlink/ioctl-style configuration operations against the veth device: (a) reduce the RX channel count so that veth_set_channels() tears down XDP resources for removed queues while leaving rq->xdp_prog populated; (b) detach or replace the XDP program so bpf_prog_put() releases the program object; (c) increase the channel count again so the previously removed queues are re-enabled with the stale pointer and their NAPI instances are scheduled.

3. Execution of the dangling reference. On the next receive action, the softirq-driven NAPI path (__napi_poll → veth_poll → veth_xdp_rcv → veth_xdp_rcv_skb) dereferences the freed program pointer. On a KASAN kernel this deterministically produces the reported page fault and panic. On kernels without KASAN the practical outcome depends on slab/vmalloc reuse of the freed BPF program region — the summary description does not provide a validated control-flow-hijack primitive, only that the freed program is "run," so no reliable code-execution claim is made here.

4. Post-exploitation impact. The immediately demonstrated impact is denial of service: Kernel panic - not syncing: Fatal exception in interrupt terminates the host, taking down every container and network namespace on that kernel and any workloads that depend on the host's network stack. The use-after-free classification means the corruption is a memory-safety event in kernel context; where allocator reclamation can be influenced, it is a candidate local privilege-escalation primitive, but that escalation path is unproven and no PoC is available. Successful triggering would also leave a KASAN splat or kernel oops in the host journal — high-signal evidence even without a clean exploit.

Impact Assessment

Primary impact — availability (High). The confirmed observable is a fatal kernel oops in interrupt context, i.e., a whole-host denial of service. One privileged network-namespace operation can crash the kernel and thereby all tenants, containers, and services on the affected machine — a significant blast radius for multi-tenant container hosts where CAP_NET_ADMIN is granted to a workload that should not be able to affect the host kernel.

Secondary impact — confidentiality/integrity (Latent). Use-after-free in the XDP receive path can, when the freed program object is reclaimed, cause execution of attacker-influenced memory. The NVD description confirms the freed program is run, but does not establish a stable exploitation primitive; hence integrity and confidentiality are treated as latent rather than demonstrated.

Assumed CVSS subscores (inferred, no official score assigned). AV:L (local privileged configuration), AC:H (requires the resize/detach/resize lifecycle in the correct order, with an XDP program present), PR:L (requires CAP_NET_ADMIN in the namespace), UI:N, S:U, C:N, I:N, A:H, yielding a broadly moderate-severity DoS score. This vector is an analyst construct derived from the described trigger conditions and must not be quoted as an official NVD score — no CVSS vector was published with this CVE.

Exploitability context. No EPSS score has been assigned by FIRST.org, there is no CISA KEV listing, no public PoC, and no Nuclei template. Real-world exploitation to date is therefore unevidenced. The practical near-term risk is accidental or adversarial host-crash DoS by privileged container workloads.

Detection Guidance

Sigma Rule

title: Linux Kernel veth Channel Resize with XDP Program Cycle (CVE-2026-98381)
id: 8c1f6a04-3b2e-4a17-9d55-0c7e9f21a6b4
status: experimental
description: >
  Detects repeated veth channel reconfiguration (ethtool -L / ETHTOOL_SCHANNELS) combined
  with XDP program attach/detach activity, the lifecycle pattern associated with the
  veth_set_channels use-after-free described in CVE-2026-98381.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-98381
author: valtersit.com Threat Intelligence
date: 2026/01/01
logsource:
  product: linux
  service: auditd
detection:
  selection_ethtool:
    type: EXECVE
    a0|endswith: 'ethtool'
    a1|contains: '-L'
  selection_xdp:
    type: EXECVE
    a0|endswith:
      - 'ip'
      - 'bpftool'
    a1|contains:
      - 'xdpgeneric'
      - 'xdpdrv'
      - 'xdp'
  selection_kernel_panic:
    type: KERNEL
    msg|contains:
      - 'veth_xdp_rcv_skb'
      - 'veth_poll'
      - 'veth_set_channels'
  timeframe: 10m
  condition: (selection_ethtool and selection_xdp) or selection_kernel_panic
level: high
tags:
  - attack.t1068
  - cve.2026-98381

YARA Rule

rule CVE_2026_98381_VETH_XDP_UAF
{
    meta:
        author = "valtersit.com Threat Intelligence"
        description = "Detects kernel log artifacts of veth XDP use-after-free (CVE-2026-98381) and related crash signatures"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-98381"
        date = "2026-01-01"
        severity = "high"

    strings:
        $crash_rip   = "RIP: veth_xdp_rcv_skb" ascii wide
        $panic_fn    = "veth_xdp_rcv_skb" ascii wide
        $poll_fn     = "veth_poll" ascii wide
        $xdp_rcv     = "veth_xdp_rcv" ascii wide
        $napi_poll   = "__napi_poll" ascii wide
        $net_rx      = "net_rx_action" ascii wide
        $pagefault   = "unable to handle page fault" ascii wide
        $fatal       = "Fatal exception in interrupt" ascii wide
        $kasan       = "KASAN NOPTI" ascii wide
        $sq          = "veth_set_channels" ascii wide

    condition:
        (uint32(0) == 0x464C457F) or  // ELF files
        (
            filesize < 10MB and
            $pagefault and
            $fatal and
            (
                ($crash_rip and $napi_poll) or
                ($poll_fn and $xdp_rcv and $kasan) or
                ($sq and $net_rx)
            )
        )
}

Suricata IDS Rule

alert netlink any -> any (msg:"CVE-2026-98381 - veth XDP channel resize use-after-free trigger (kernel panic risk)"; flow:to_server; content:"|00 00 00 00|"; byte_test:1,=,0x04,0,relative; dsize:<256; threshold:type limit,track by_src,count 1,seconds 60; metadata:cve 2026-98381, created_at 2026_01_01, updated_at 2026_01_01; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-98381; classtype:attempted-dos; sid:202698381; rev:1;)

Note: the trigger for this CVE is a local netlink/ethtool configuration sequence, not IP network traffic. A network IDS has no visibility into the vulnerable code path; the rule above is a coarse placeholder for environments that mirror netlink control traffic (e.g., via a tap/bridge) and should not be relied upon as a primary detection. Host-side telemetry (auditd, kernel logs, eBPF/audit frameworks) is the correct sensor.

Elastic Detection

sequence by host.id, user.id with maxspan=10m
  [process where event.type == "start" and
     process.name in ("ethtool", "ip", "bpftool") and
     process.args : ("-L", "*xdp*", "*channel*")]
  [process where event.type == "start" and
     process.name in ("ethtool", "ip", "bpftool") and
     process.args : ("*xdp*", "*channel*")]
  [any where event.category == "host" and
     event.type == "error" and
     message : ("veth_xdp_rcv_skb*", "veth_poll*", "unable to handle page fault*")]

This EQL chain flags a privileged process repeatedly manipulating veth channels and XDP on the same host within a short window, followed by a veth XDP kernel fault — the CVE-2026-98381 lifecycle pattern.

Splunk SPL Query

index=linux_logs (source=*syslog* OR source=*messages* OR sourcetype=linux_kernel OR sourcetype=auditd)
| eval sig=lower(_raw)
| where (match(sig,"veth_set_channels") OR match(sig,"ethtool.*-l") OR match(sig,"\bxdp\b"))
        OR (match(sig,"veth_xdp_rcv_skb") AND match(sig,"veth_poll"))
        OR (match(sig,"unable to handle page fault") AND match(sig,"Fatal exception in interrupt"))
| stats count min(_time) as first_seen max(_time) as last_seen values(host) as hosts by host
| where count >= 3
| convert ctime(first_seen) ctime(last_seen)

Wazuh OSSEC Rule

<group name="linux,kernel,cve-2026-98381,">
  <rule id="100381" level="12">
    <decoded_as>syslog</decoded_as>
    <match>veth_xdp_rcv_skb|veth_poll|veth_xdp_rcv</match>
    <description>CVE-2026-98381: veth XDP use-after-free crash signature detected in kernel log</description>
    <group>kernel_panic,pci_dss_10.6,cve_2026_98381,</group>
  </rule>
  <rule id="100382" level="10">
    <decoded_as>syslog</decoded_as>
    <match>unable to handle page fault</match>
    <match>Fatal exception in interrupt</match>
    <description>CVE-2026-98381: kernel page fault in interrupt context (possible veth XDP UAF)</description>
    <group>kernel_panic,cve_2026_98381,</group>
  </rule>
  <rule id="100383" level="8" frequency="3" timeframe="600">
    <if_matched_sid>100382</if_matched_sid>
    <same_source_ip />
    <description>CVE-2026-98381: repeated kernel faults consistent with veth channel/XDP manipulation</description>
    <group>cve_2026_98381,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor-fix reference, advisory, affected-version list, or backport information was available with this CVE. Treat all upstream statements as unverified until a stable-tree commit is published.

1. Immediate mitigations (reduce exposure now).

   • Remove CAP_NET_ADMIN from workloads that do not strictly require network-namespace reconfiguration; use dedicated, least-privilege network namespaces and avoid --privileged containers.
   • Restrict access to the interface-configuration surface: gate ethtool -L/channel changes and BPF program attach/detach/replace (the bpf syscall path and XDP operations) with policy (seccomp, LSM/AppArmor/SELinux, or equivalent) so that only trusted host-level components can invoke them.
   • If XDP on veth is not operationally required, disable or avoid XDP program attachment on veth devices; without an XDP program the described stale-pointer execution cannot occur.
   • Avoid automated or untrusted triggering of veth channel shrink/grow cycles on production hosts; treat any kernel oops mentioning veth_set_channels, veth_xdp_rcv_skb, or veth_poll as a security event, not a hardware fault, and preserve the KASAN/crash logs.
   • On hosts running KASAN, recognize that this bug is expected to be deterministically fatal — plan for blast radius (multi-tenant container hosts and network-function hosts are highest risk).

2. Patch / upgrade steps.

   • Watch the upstream Linux kernel stable and mainline trees, your distribution vendor (LTS security advisories), and the CNA record for an assigned fixing commit or release version. None is available at the time of writing.
   • Because the status is UNPATCHED, do not claim remediation via upgrade until a specific fixing commit or kernel version is confirmed for your tree.
   • After a fix version exists, stage-test on a kernel with KASAN enabled to confirm the dangle is gone before fleet rollout; apply the vendor kernel update and reboot (kernel fixes require reboot to take effect).
   • Track your kernel baseline against the vendor's CVE tracker to know when this lands in your distribution.

3. Long-term hardening.

   • Inventory and continuously constrain CAP_NET_ADMIN and BPF/XDP capability grants across orchestration platforms (Kubernetes PodSecurity/SCC policies, container runtimes, immutable host images).
   • Enable BPF LSM, auditd, and kernel-crash/log forwarding to a central SIEM so lifecycle-abuse patterns and veth XDP faults are detected, not missed.
   • Increase kernel observability (KASAN on canary hosts, kernel oops alerting) to catch memory-safety faults in the framework's network paths before broad impact.
   • Maintain an asset record of kernels operating veth interfaces (container hosts, CNI clusters, virtualized network labs) so future kernel networking CVEs can be triaged quickly.

References

• NVD — CVE-2026-98381: https://nvd.nist.gov/vuln/detail/CVE-2026-98381
• MITRE CVE Program record (CNA submission): https://www.cve.org/CVERecord?id=CVE-2026-98381
• Linux kernel mainline/stable source tree (veth driver — drivers/net/veth.c) for verifying an eventual fix commit
• Your Linux distribution vendor's kernel security advisory channel (for backport availability)
• CISA KEV catalog listing: NOT listed — no known exploitation in the wild as of this writing.

No threat-actor campaign, in-the-wild exploitation, public PoC, EPSS score, or Nuclei template is associated with CVE-2026-98381 in the provided data. All exploitation content above is a vulnerability-class inference and must be verified against a published advisory or patch before being relied upon operationally.