CVE-2026-72407

In the Linux kernel, the following vulnerability has been resolved:

geneve: validate inner network offset in genevegrocomplete()

Even with both paths gated on gs->grohint, genevegro_complete()

re-derives the inner dispatch type and length from the packet and the

current gs->grohint, independently of genevegro_receive(). The two can

disagree if gs->grohint flips under a concurrent genevequiesce()/

geneveunquiesce() (skuserdata is NULL across a synchronizenet()), or if

the re-read option bytes differ from the ones receive parsed.

genevegroreceive() already records the inner network header position in

NAPIGROCB()->innernetworkoffset. Have genevegrocomplete() compute the

offset it is about to dispatch at, adding ETHHLEN in the ETHP_TEB case

where ethgrocomplete() steps over the inner MAC header, and bail out if

it lands past innernetworkoffset.

Use a lower bound rather than exact equality: between gh_len and the inner

L3 header, genevegroreceive() may also have pulled an inner VLAN tag

(vlangroreceive() advances the recorded offset past it), which only moves

innernetworkoffset further out. A valid frame therefore always satisfies

innernh <= innernetworkoffset, while a ghlen inflated by a hint

gro_receive() did not honour dispatches past the validated inner header,

i.e. the out-of-bounds completion. Only the latter is rejected.