CVE-2026-68121

What it actually does

This is a Linux kernel use-after-free flaw in PPPoE packet transmission. The vulnerable code in pppoe_sendmsg() stores a pointer to the PPPoE header, then calls dev_hard_header(). Certain device header callbacks can expand or reallocate the socket buffer head, invalidating the saved pointer. PPPoE then writes six bytes through that stale pointer into freed kernel memory. Depending on kernel configuration, timing, and reachable networking setup, this can cause kernel memory corruption, denial of service, or potentially local privilege escalation if an attacker can reliably shape the freed memory and trigger the race.

Why it matters to the business

Systems using affected Linux kernels with PPPoE and relevant virtual or team networking configurations may be exposed to kernel crashes or deeper compromise from a local attacker or a process with access to the vulnerable network path. Because the flaw is in the kernel, successful exploitation can affect system stability and isolation boundaries. There is no confirmed CISA KEV listing or ransomware association at this time, and no public exploit maturity is indicated, but the issue is recent and should be addressed through normal kernel update channels, especially on hosts using PPPoE, team devices, GRE/GRETAP-style networking, or complex virtual networking.

How an attack unfolds

An attacker needs the ability to trigger PPPoE send operations on a vulnerable kernel while causing a device header callback to reallocate the skb head after pppoe_sendmsg() has saved a header pointer. The described vulnerable sequence can occur when a send operation blocks in copy_from_user() while a first non-Ethernet port is added to an empty team device, causing a delegated GRE header callback to expand the skb head. After the skb head is moved, the original PPPoE header pointer becomes stale, but the PPPoE code continues using it and writes into freed memory. In the simplest case this produces a kernel crash. With precise timing and heap manipulation, an attacker may attempt to turn the freed-memory write into controlled kernel memory corruption.

How to fix it

Apply the vendor-provided Linux kernel update containing the PPPoE fix that reloads the PPPoE header pointer after dev_hard_header() using the skb network-header offset. Because no affected product or fixed-version list was provided, use distribution-specific kernel advisories and update to the first kernel package that includes the upstream fix for this issue. Where immediate patching is not possible, reduce exposure by disabling unused PPPoE functionality, limiting local access to PPPoE socket creation and network device administration, restricting CAP_NET_ADMIN to trusted processes only, and avoiding vulnerable combinations of PPPoE, team devices, and GRE/GRETAP-style delegated header paths on unpatched systems.

How to confirm the fix worked

Confirm the running kernel version includes the vendor backport or upstream patch for this issue; do not rely only on the upstream version number because Linux distributions commonly backport fixes. Validate with distribution security advisories, package changelogs, or kernel source patches showing pppoe_sendmsg() reloads the PPPoE header after dev_hard_header(). Check whether PPPoE and team/GRE-related modules are loaded or in use, and confirm that unneeded modules and capabilities have been restricted. After patching, reboot into the fixed kernel and verify the running kernel with uname -a or equivalent package inventory tooling.

Typical attack path

1. Gain local code execution or sufficient local ability to create/use PPPoE sockets and manipulate relevant network device state.
2. Prepare a vulnerable network configuration involving PPPoE and a device path whose header callback can expand or reallocate the skb head, such as team plus delegated GRE-style header handling.
3. Trigger a PPPoE send path that reaches pppoe_sendmsg() and stores a pointer into the skb head.
4. Induce blocking or timing conditions around copy_from_user() while changing the network device configuration so dev_hard_header() reallocates the skb head.
5. Cause PPPoE to write through the stale header pointer into freed kernel memory.
6. Leverage the resulting memory corruption for denial of service or attempt further exploitation for elevated kernel privileges.

How to detect it

To assess possible prior exploitation, review kernel logs, persistent journald records, crash dumps, kdump/vmcore data, audit logs, and endpoint telemetry for kernel memory-corruption events involving PPPoE transmission. Useful sources include /var/log/kern.log, /var/log/messages, journalctl -k output, dmesg captures, kdump crash directories, auditd logs for network device changes, and container/runtime logs showing CAP_NET_ADMIN use. Look for kernel oops, panic, KASAN, KFENCE, or slab allocator warnings that mention pppoe_sendmsg(), PPPoE, skb expansion, dev_hard_header(), pskb_expand_head(), team devices, GRE, GRETAP, or network-device reconfiguration occurring close in time to crashes. Also investigate suspicious sequences where local users, containers, or services create PPPoE activity while adding ports to team devices or modifying GRE/GRETAP interfaces. There are no known public exploit-specific payload strings or network IOCs provided for this vulnerability; detection is primarily behavioral and forensic, based on kernel crash artifacts and unusual local network-configuration activity.

• BUG: KASAN: use-after-free in pppoe_sendmsg
• KASAN: use-after-free in pppoe_sendmsg
• BUG: KFENCE: use-after-free
• pppoe_sendmsg
• dev_hard_header
• pskb_expand_head
• skb head
• PPPoE
• gretap
• GRE header
• team device
• NETDEV_CHANGE
• RTM_NEWLINK
• kernel panic
• kernel BUG
• Oops:
• general protection fault

What your security team should do

• Prioritize kernel updates on systems that use PPPoE, team/bond-like virtual networking, GRE/GRETAP tunnels, container networking, virtualization hosts, network appliances, or multi-tenant local access.
• Inventory systems with PPPoE-related modules or configurations and identify where untrusted users or workloads may have CAP_NET_ADMIN or similar network-administration privileges.
• Until patched, restrict local users, containers, and services from creating PPPoE sockets or modifying network devices unless explicitly required.
• Monitor for kernel crashes, KASAN reports, oopses, or panics referencing pppoe_sendmsg(), dev_hard_header(), pskb_expand_head(), team devices, or GRE header handling.
• Review distribution kernel advisories and confirm the fixed kernel is actually booted after installation.
• Treat suspicious kernel memory-corruption crashes on exposed hosts as potential security events and preserve crash dumps, kernel logs, and recent network configuration activity for investigation.