CVE-2026-98377 in Linux
Summary
by MITRE • 10/09/2026
In the Linux kernel, the following vulnerability has been resolved:
vlan: require the MAC header to be present in __vlan_insert_inner_tag()
__vlan_insert_inner_tag() only guarantees head room via skb_cow_head(), never that mac_len bytes of MAC header are present. Its ETH_HLEN wrappers - __vlan_insert_tag() under skb_vlan_push(), and vlan_insert_tag() under validate_xmit_vlan() on the generic transmit path - therefore rewrite the first 16 bytes at skb->data: a 12-byte memmove plus two 2-byte stores at +12 and +14. No caller supplies the bound, while the pop helpers use skb_ensure_writable()/pskb_may_pull().
An IFF_TUN device has hard_header_len == 0, so packet_snd() accepts a one-byte AF_PACKET/SOCK_RAW frame. The first vlan push only sets a hwaccel tag; the next - clsact "action vlan push" or bpf_skb_vlan_push() - enters the helper with skb->len still 1. The head comes from skbuff_small_head without __GFP_ZERO, so each push drags bytes from beyond skb->tail into the frame. After three the one-byte send leaves as 13 bytes carrying 11 bytes of uninitialised slab:
0000: 5a b3 62 12 80 88 ff ff 00 b3 62 12 81 `------------------------------' only 0x5a was sent; the rest is slab, here the top 56 bits of a linear-map address
Require the MAC header the helper rewrites to be present, so such a frame is dropped rather than transmitted.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified in the Linux kernel involves a critical flaw within the VLAN tag insertion logic, specifically affecting the __vlan_insert_inner_tag() function and its associated wrappers used during packet transmission. This issue stems from an insufficient validation of buffer boundaries before attempting to rewrite network headers. The core technical deficiency lies in the fact that while the helper function ensures there is sufficient headroom via skb_cow_head(), it fails to guarantee that the full MAC header length, defined by ETH_HLEN, is actually present and writable within the socket buffer data area. Consequently, when functions like __vlan_insert_tag() or vlan_insert_tag() are invoked during the generic transmit path, they proceed to rewrite the first sixteen bytes of the packet data without verifying if those specific memory locations contain valid MAC header information. This operation involves a twelve-byte move followed by two two-byte stores at offsets plus twelve and plus fourteen relative to the start of the buffer. Because no caller explicitly supplies or validates this bound prior to execution, the system assumes the presence of these bytes when they may not exist, leading to out-of-bounds memory access patterns that compromise data integrity and potentially expose sensitive kernel information.
The operational impact is most severe in scenarios involving IFF_TUN devices where hard_header_len is set to zero. In such configurations, the packet_snd() function accepts extremely short frames from AF_PACKET or SOCK_RAW sockets, including those as small as one byte. When a VLAN push action is applied via clsact actions or BPF programs like bpf_skb_vlan_push(), the helper enters with an skb length of only one byte. Since the headroom allocation relies on skbuff_small_head which does not guarantee zeroed memory, each subsequent VLAN tag insertion drags uninitialized bytes from beyond the current socket buffer tail into the frame being constructed. After three such operations, a single-byte send operation results in a thirteen-byte packet that carries eleven bytes of uninitialised slab memory. This effectively leaks kernel heap contents to the network interface, as evidenced by captured packets containing fragments of linear-map addresses and other sensitive data structures residing in adjacent memory regions.
This vulnerability aligns with CWE-125 Out-of-bounds Read, as it involves reading from memory locations outside the intended buffer boundaries due to improper boundary checks. Furthermore, the ability to leak uninitialized kernel slab memory can be classified under CWE-200 Information Exposure, particularly when such data includes pointers or addresses that aid in further exploitation attempts like return-oriented programming attacks. From a threat modeling perspective using MITRE ATT&CK, this behavior facilitates Data Staged Exfiltration and potentially aids in Defense Evasion by allowing attackers to gather information about kernel memory layout without triggering immediate detection mechanisms associated with larger data transfers. The lack of proper validation allows an unprivileged user or a compromised application utilizing raw sockets to trigger these conditions remotely if the interface is accessible, turning what appears to be a simple packet construction error into a significant security risk involving confidentiality and integrity violations within the network stack.
To mitigate this vulnerability, it is imperative that developers enforce strict checks for MAC header presence before any rewrite operations are performed on socket buffers in VLAN-related helper functions. The fix involves requiring __vlan_insert_inner_tag() to verify that ETH_HLEN bytes of MAC header data are present and writable at skb->data prior to proceeding with the memmove and store operations. If this condition is not met, the packet should be dropped immediately rather than transmitted with corrupted or leaked content. This approach mirrors the safety mechanisms already employed by VLAN pop helpers which utilize functions like skb_ensure_writable() and pskb_may_pull() to guarantee data availability before access. By implementing these boundary checks consistently across both push and pop operations, the kernel prevents out-of-bounds reads and ensures that only properly formatted packets with valid headers are processed for transmission. System administrators should ensure their kernels are updated to include patches addressing this specific logic error in vlan.c to prevent potential information disclosure through raw socket interactions on tunable interfaces.