CVE-2026-98240
NoneCVSS
—
EPSS
0.2%
Published
Oct 6, 2026
CISA due date
—
Cloudanix analysis
A mistake in how the Linux kernel handles certain network tunnel settings can let an attacker crash the whole computer with one command.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Buffer Overflow
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Uninitialized options_len variable in ip_tun_parse_opts_geneve allows memcpy to write 4 bytes into a zero-length destination buffer, triggering fortified memcpy failure and kernel BUG/panic under CONFIG_FORTIFY_SOURCE.
Why it matters to the business
Local or remote attackers can crash affected Linux systems by sending crafted tunnel configuration commands, causing denial of service and potential loss of network connectivity or availability.
How an attack unfolds
An attacker with sufficient privileges issues an ip route add command containing geneve_opts that sets a 4-byte DATA attribute; ip_tunnel_info_opts returns a pointer offset by the still-zero options_len, so the subsequent memcpy writes outside the intended options buffer and hits the fortified check.
How to fix it
Apply the upstream fix that initializes options_len before any reference to ip_tunnel_info_opts; rebuild and boot the patched kernel; verify the geneve_opts parsing path no longer triggers the fortified memcpy check.
How to confirm the fix worked
Confirm the kernel contains the commit that moves the options_len assignment before the geneve_opt pointer calculation; re-run the triggering ip route command under a kernel with CONFIG_FORTIFY_SOURCE and ensure no BUG at lib/string_helpers.c occurs.
Typical attack path
- Obtain local shell or routing configuration access on a vulnerable kernel
- Execute ip link add dummy interface and bring it up
- Run ip route add with encap ip id and geneve_opts carrying a 4-byte payload
- Trigger ip_tun_build_state which calls the uninitialized options_len path
- Fortified memcpy detects overflow and panics the kernel
How to detect it
Search kernel logs and dmesg for "memcpy: detected buffer overflow", "kernel BUG at lib/string_helpers.c", and stack traces containing ip_tun_parse_opts_geneve or ip_tun_build_state; correlate with recent execution of ip route commands containing geneve_opts.
- memcpy: detected buffer overflow: 4 byte write of buffer size 0
- kernel BUG at lib/string_helpers.c:1044
- ip_tun_parse_opts.part.0.cold
- ip_tun_build_state+0x116
- geneve_opts
What your security team should do
- Prioritize kernel upgrade on all systems exposing tunnel configuration interfaces
- Restrict unprivileged users from netlink route operations via capabilities or SELinux policies
- Monitor kernel logs for fortified memcpy and ip_tun_parse_opts strings
- Test the published reproducer in a lab environment after patching
The record
In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: initialize `options_len` before referencing options The following command triggers a kernel panic: ip link add d0 type dummy; ip link set d0 up ip route add 10.30.0.0/16 \ encap ip id 300 geneve_opts 4660:66:11223344 dev d0 memcpy: detected buffer overflow: 4 byte write of buffer size 0 kernel BUG at lib/string_helpers.c:1044! ... ip_tun_parse_opts.part.0.cold+0x10/0x10 ip_tun_build_state+0x116/0x2a0 On kernels built with GCC 15+ and `CONFIG_FORTIFY_SOURCE`, the fortified `memcpy()` got 0 sized destination with request of 4 bytes length: static int ip_tun_parse_opts_geneve(...) { ... attr = tb[LWTUNNEL_IP_OPT_GENEVE_DATA]; data_len = nla_len(attr); /* == 4 */ struct geneve_opt *opt = ip_tunnel_info_opts(info) + opts_len; memcpy(opt->opt_data, nla_data(attr), data_len); /* ^^^^^^^^^^^^^ 0 since options_len is assigned afterwards */ Fixed by initializing the counter before the options are referenced. Matching what `tunnel_key_opts_set()` already does.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|