Description

In the Linux kernel, the following vulnerability has been resolved: ipvlan: inherit needed_headroom and needed_tailroom from phy_dev ipvlan devices inherit hard_header_len from phy_dev during ipvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying phy_dev (or stacked lower device) requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / ipvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from phy_dev in ipvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached ipvlans in ipvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-26T15:16:53.250Z",
  "pubdate": "2026-08-26T15:16:53.250Z",
  "executiveSummary": "The Linux kernel ipvlan driver contains a vulnerability involving improper calculation of packet header and trailer space requirements. The flaw resides in the initialization and synchronization of network device properties, where ipvlan devices fail to inherit needed_headroom and needed_tailroom values from their physical (phy_dev) counterparts.\nThis defect leads to insufficient buffer reservation for protocols requiring extra space, such as MACsec, IPsec, or tunnels. Exploitation can trigger skb (socket buffer) headroom underflows, memory reallocation overhead, or critical KASAN-detected slab-use-after-free crashes.\nThe vulnerability affects Linux kernel systems utilizing ipvlan interfaces over physical devices that require additional headroom or tailroom. An attacker capable of sending traffic through such an improperly configured interface could induce kernel instability or denial-of-service (DoS) conditions due to memory corruption. No specific authentication or complex exploit chain is required, as the crash is an intrinsic result of incorrect buffer size expectations during packet processing.",
  "technicalDetails": "The root cause of this vulnerability is the incomplete initialization and propagation of hardware-specific networking requirements within the ipvlan driver. Specifically, while ipvlan_init() properly handles hard_header_len inheritance, it leaves needed_headroom and needed_tailroom at zero. These fields are critical for the networking stack to determine how much space must be reserved in the sk_buff structure to accommodate protocol headers or trailers appended by lower-layer devices.\nWhen an ipvlan interface is stacked upon a physical device (or an intermediate tunnel/veth device) that requires extra room—common in encapsulating protocols like wireguard or hardware-accelerated offloading like MACsec—the ipvlan device remains unaware of these requirements. Consequently, when dev_hard_header() or ipvlan_hard_header() is invoked, the underlying network stack prepares an skb that lacks the necessary headroom to prepend required headers or the tailroom to append trailer data.\nThe exploitation flow begins when a packet is transmitted through the ipvlan interface. Because the driver under-reports its needed_headroom and needed_tailroom, the skb allocation for the packet is smaller than required by the lower-level transmission hardware. As the stack attempts to write header data into the insufficient headroom space, it performs an out-of-bounds write or an underflow operation. Similarly, appending data to an insufficient tailroom causes memory corruption in adjacent slab cache objects. This behavior manifests as KASAN slab-use-after-free errors or kernel panics when the memory allocator attempts to manage the corrupted or incorrectly accessed skb structure.\nThis vulnerability is triggered during standard packet transmission paths whenever the lower-layer hardware requirement for space is non-zero. It does not require remote authentication or elevated privileges, as the system state itself is insecure upon interface initialization. The lack of propagation during NETDEV_FEAT_CHANGE events further exacerbates the issue, as dynamic changes to the phy_dev configuration are not reflected in the dependent ipvlan devices, ensuring that even systems that start in a stable state may become vulnerable after network topology or feature updates."
}