CVE-2026-99064
High · 8.1CVSS
8.1
EPSS
0.5%
Published
Oct 23, 2026
CISA due date
—
Cloudanix analysis
A bug in how the Linux kernel handles certain network packets can let attackers cause crashes or take over systems by sending specially formatted traffic.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Moderate
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
cipso_v4_skbuff_delattr removes CIPSO option bytes without subtracting cipso_len from cached srr, rr, ts and router_alert offsets, causing later consumers such as ip_forward_options and __ip_options_echo to read or write at stale offsets and interpret arbitrary packet data as option lengths or values.
Why it matters to the business
Linux-based network devices and servers may experience crashes, information leaks, or remote code execution when processing specially crafted IP packets, potentially disrupting routing, forwarding, or host services.
How an attack unfolds
An attacker crafts an IPv4 packet containing a CIPSO option followed by another IP option such as RR, sends it toward a vulnerable Linux system or through a vulnerable forwarder; the kernel removes the CIPSO bytes, leaves the cached offset unchanged, and subsequent option-processing functions dereference the stale offset, reading or writing attacker-controlled bytes.
How to fix it
Apply the upstream kernel commit that mirrors cipso_v4_delopt logic and subtracts cipso_len from all trailing option offsets; rebuild and deploy the patched kernel on all affected systems.
How to confirm the fix worked
Confirm the fix by inspecting cipso_v4_skbuff_delattr and cipso_v4_delopt for matching offset-adjustment code; test with synthetic packets containing CIPSO plus RR/TS options and verify no stale-offset accesses occur.
Typical attack path
- Craft IPv4 packet with valid CIPSO option followed by RR, TS or router-alert option
- Send packet to a vulnerable Linux host or router that invokes cipso_v4_skbuff_delattr
- Trigger ip_forward_options or __ip_options_echo on the modified skb
- Stale offset causes out-of-bounds read or write into packet data or option storage
How to detect it
Review kernel logs for oops traces referencing ip_forward_options, __ip_options_echo, or cipso_v4_skbuff_delattr; inspect network captures for IPv4 packets carrying both CIPSO and RR/TS options arriving at or transiting Linux systems.
What your security team should do
- Prioritize kernel updates on all systems that perform IP option processing or forwarding
- Monitor for kernel oops or panics involving ip_options functions
- Consider network-level filtering of CIPSO options until patches are deployed
The record
In the Linux kernel, the following vulnerability has been resolved: cipso: adjust cached option offsets when removing CIPSO cipso_v4_skbuff_delattr() removes the CIPSO bytes but does not adjust cached offsets for options that follow them. For example, with a valid 10-byte CIPSO option followed by a seven-byte RR option, parsing records rr at offset 30. Removing CIPSO moves RR to offset 20, while the cached offset remains 30. Consumers such as ip_forward_options() and __ip_options_echo() then access the wrong bytes; the latter may interpret packet data as the option length and copy it into fixed-size option storage. Mirror cipso_v4_delopt() and subtract cipso_len from the srr, rr, ts and router_alert offsets when they follow CIPSO. cipso_len is the distance the first memmove() shifts those options. The later header move and network-header reset relocate the bytes and their offset base together.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|