On Sat, Nov 21, 2020 at 2:56 AM Jason A. Donenfeld <ja...@zx2c4.com> wrote:
>
> On 11/21/20, Eyal Birger <eyal.bir...@gmail.com> wrote:
> > In the patchset merged by commit b9fcf0a0d826
> > ("Merge branch 'support-AF_PACKET-for-layer-3-devices'") L3 devices which
> > did not have header_ops were given one for the purpose of protocol parsing
> > on af_packet transmit path.
> >
> > That change made af_packet receive path regard these devices as having a
> > visible L3 header and therefore aligned incoming skb->data to point to the
> > skb's mac_header. Some devices, such as ipip, xfrmi, and others, do not
> > reset their mac_header prior to ingress and therefore their incoming
> > packets became malformed.
> >
> > Ideally these devices would reset their mac headers, or af_packet would be
> > able to rely on dev->hard_header_len being 0 for such cases, but it seems
> > this is not the case.
> >
> > Fix by changing af_packet RX ll visibility criteria to include the
> > existence of a '.create()' header operation, which is used when creating
> > a device hard header - via dev_hard_header() - by upper layers, and does
> > not exist in these L3 devices.
> >
> > As this predicate may be useful in other situations, add it as a common
> > dev_has_header() helper in netdevice.h.
> >
> > Fixes: b9fcf0a0d826 ("Merge branch
> > 'support-AF_PACKET-for-layer-3-devices'")
> > Signed-off-by: Eyal Birger <eyal.bir...@gmail.com>> Acked-by: Jason A. Donenfeld <ja...@zx2c4.com> Acked-by: Willem de Bruijn <will...@google.com>
