This CVE exposes a class of header offset errors that accumulated across three separate transmit-path call sites (vxlan_xmit(), arp_reduce(), and vxlan_mdb_entry_skb_get()) because the kernel's pskb pulling API creates conditions where the wrong function feels locally rational. The bug: these functions call pskb_may_pull() when they should call pskb_network_may_pull(). The distinction matters because pskb_may_pull() calculates offsets from skb->data (which points at the MAC layer in TX paths), while pskb_network_may_pull() calculates from skb_network_offset()—a difference of ETH_HLEN bytes. Under normal MTU configurations this bug is invisible because the pull succeeds even with the wrong reference point. It surfaces only under fragmentation or specific encapsulation conditions where the header offset error leaves network layer headers in non-linear skb regions.
The concerning pattern is that three independent developers, across separate commits and review cycles, made the same conceptual error. This suggests pskb_network_may_pull()—which already existed—was not self-evidently the correct choice. The function name pskb_may_pull() reads as a general-purpose 'make this much header available' operation, creating false affordances. The API's naming prioritizes terseness over cognitive usability.
Check your kernel versions: this affects recent stable releases and the fix is a straightforward function swap. Audit adjacent transmit-path tunnel code (geneve, gre, bareudp) for similar patterns—skb->data pointing at MAC headers is the indicator. If you're maintaining network subsystem code, consider whether static analysis tooling could flag pskb_may_pull() calls where skb->data points at ETH_HLEN offset, or whether wrapper functions with unambiguous TX semantics would prevent recurrence.