CVE-2022-49872: net: gso: fix panic on frag_list with mixed head alloc types

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

net: gso: fix panic on fraglist with mixed head alloc types

Since commit 3dcbdb134f32 ("net: gso: Fix skbsegment splat when splitting gsosize mangled skb having linear-headed fraglist"), it is allowed to change gsosize of a GRO packet. However, that commit assumes that "checking the first listskb member suffices; i.e if either of the listskb members have non headfrag head, then the first one has too".

It turns out this assumption does not hold. We've seen BUGON being hit in skbsegment when skbs on the fraglist had differing headfrag with the vmxnet3 driver. This happens because netdevallocskb and napiallocskb can return a skb that is page backed or kmalloced depending on the requested size. As the result, the last small skb in the GRO packet can be kmalloced.

There are three different locations where this can be fixed:

(1) We could check headfrag in GRO and not allow GROing skbs with different headfrag. However, that would lead to performance regression on normal forward paths with unmodified gsosize, where !headfrag in the last packet is not a problem.

(2) Set a flag in bpfskbnetgrow and bpfskbnetshrink indicating that NETIFFSG is undesirable. That would need to eat a bit in skbuff. Furthermore, that flag can be unset when all skbs on the fraglist are page backed. To retain good performance, bpfskbnetgrow/shrink would have to walk the fraglist.

(3) Walk the fraglist in skbsegment when determining whether NETIFFSG should be cleared. This of course slows things down.

This patch implements (3). To limit the performance impact in skbsegment, the list is walked only for skbs with SKBGSODODGY set that have gsosize changed. Normal paths thus will not hit it.

We could check only the last skb but since we need to walk the whole list anyway, let's stay on the safe side.