Live › vulnerability › CVE-2026-98568
Go to dashboardA race in the Linux kernel's VXLAN driver lets a concurrent link change make the neighbour-reply code size its buffer too small. The result is an out-of-bounds write of a few bytes into kernel memory, which can corrupt the kernel.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with the VXLAN driver loaded and in use, where neighbour suppression replies are generated and the VXLAN link is reconfigured at runtime. Hosts that do not use VXLAN, or that do not change VXLAN link settings while traffic flows, are much less exposed. unknown for exact trigger conditions beyond this.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
vxlan: use one headroom snapshot for neighbour replies
vxlan_na_create() samples LL_RESERVED_SPACE() to size the reply skb and then samples it again to reserve headroom. A concurrent vxlan_changelink() can update needed_headroom between the two reads, creating a TOCTOU race. The second value can exceed the allocation and make the Ethernet header write out of bounds.
The race is reproducible on the unpatched kernel. It occurred when vxlan_na_create() generated a neighbour reply while vxlan_changelink() changed the link headroom. KASAN caught a four-byte write two bytes beyond a 704-byte skbuff_small_head allocation.
Snapshot the headroom once and use that value for both allocation and reservation.
This page as .md · .json · in your agent: get_signal("CVE-2026-98568")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.