CVE-2026-72407: geneve: validate inner network offset in geneve_gro_complete()

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, genevegrocomplete() re-derives the inner dispatch type and length from the packet and the current gs->grohint, independently of genevegroreceive(). 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 ETHPTEB 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 ghlen 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 groreceive() did not honour dispatches past the validated inner header, i.e. the out-of-bounds completion. Only the latter is rejected.