Cloudanix VulnDB

CVE-2026-98287

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the Linux network code for certain ATM connections could let an attacker on the same system crash the machine or gain elevated access by sending unusual network frames.

Exploitation
Adjacent Network
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The flaw allows packets arriving via PPP channel bridging to reach pppoatm_send without skb_cow_head, so the driver may push an LLC header into non-writable or insufficient headroom memory and may read skb->data[0] on zero-length or non-linear skbs, resulting in memory corruption or out-of-bounds reads.

Why it matters to the business

Systems using PPPoATM bridging can experience kernel crashes, data corruption, or potential local privilege escalation, leading to service outages and requiring emergency kernel updates on affected Linux hosts.

How an attack unfolds

An attacker with the ability to inject frames into a bridged PPP channel sends specially crafted zero-length or non-linear skbs that bypass the normal unsharing path; when pppoatm_send attempts to encapsulate without ensuring writability or performing a length check, it corrupts kernel memory or reads out-of-bounds.

How to fix it

Apply the upstream kernel patch that adds skb_cow_head, pskb_may_pull(1), and defers protocol compression; rebuild and boot the fixed kernel on all affected systems.

How to confirm the fix worked

Confirm the presence of skb_cow_head and pskb_may_pull calls in pppoatm_send in the running kernel source or binary; test bridging traffic with crafted short/non-linear frames to verify no crash or corruption occurs.

Typical attack path

  1. Obtain ability to bridge or inject into a PPP channel (local user or compromised container)
  2. Craft and transmit zero-length or non-linear skb frames via PPPIOCBRIDGECHAN
  3. Trigger pppoatm_send LLC encapsulation path without prior skb_cow_head
  4. Cause skb_push into non-writable headroom or pskb_may_pull failure leading to memory corruption

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for oops, warnings, or stack traces mentioning pppoatm_send, skb_cow_head, or LLC encapsulation around the time of bridging activity; correlate with unexpected PPP channel creation via PPPIOCBRIDGECHAN ioctls.

What your security team should do

  • Prioritize kernel update on any host exposing PPPoATM or using PPPIOCBRIDGECHAN
  • Disable PPP channel bridging if the feature is unused
  • Monitor kernel logs for skb-related warnings or oops in pppoatm after patching

The record

In the Linux kernel, the following vulnerability has been resolved: pppoatm: ensure a writable skb header and linear data In pppoatm_send(), LLC encapsulation checks whether there is sufficient headroom for the 4-byte LLC header, but does not ensure that the skb header is writable. Normal transmit packets passing through ppp_start_xmit() have their header unshared via skb_cow_head(). However, packets can also reach pppoatm_send() via PPP channel bridging (PPPIOCBRIDGECHAN) without going through ppp_start_xmit(). Use skb_cow_head() to ensure both sufficient headroom and a writable header before pushing the LLC header. While at it: - Call pskb_may_pull(skb, 1) before inspecting skb->data[0] to prevent out-of-bounds reads on zero-length or non-linear frames (e.g. from bridging). - Defer SC_COMP_PROT protocol compression until after pppoatm_may_send() succeeds. This eliminates the temporary skb allocation on admission failure and completely removes the fragile "undo" heuristic at the nospace label, avoiding any risk of reading uninitialized headroom or performing an unbalanced skb_push().

Affected packages

Ecosystem Package Introduced Fixed