Re: [PATCH net-next v4] erspan: drop packets with an unknown ERSPAN version

[Ido Schimmel <idosch@nvidia.com>]

On Wed, Nov 11, 2026 at 12:28:48AM +0900, Haishuang Yan wrote:
> The ERSPAN type II and III receive paths take the length of the ERSPAN
> header from the version field of the packet, with erspan_hdr_len(), but
> never check that the version is one they know: 1 for type II or 2 for
> type III.
> 
> For any other version, erspan_hdr_len() returns 0 or the type III
> length. With version 0, the ERSPAN header is not pulled, so it is
> passed up as the start of the inner Ethernet frame, and in collect_md
> mode the metadata is filled from the wrong part of the header. The
> ETH_HLEN pull in __iptunnel_pull_header() still covers the bytes that
> are copied, so nothing is read past the pulled data.
> 
> Reject such packets, as a packet with a truncated ERSPAN header already
> is.
> 
> On IPv4, a packet with a 4-byte GRE header is taken as type I without
> looking at the protocol. gre_parse_header() treats an ETH_P_ERSPAN2
> packet as carrying an ERSPAN header whatever the GRE header length,
> but erspan_rcv() then skips that header's version and passes it up as
> the inner frame. Type I only uses ETH_P_ERSPAN, so check the protocol
> too. Such a packet now goes through the type III path and its version
> check.
> 
> IPv6 has no type I, but ip6erspan_rcv() does not reject a type I
> packet, an ETH_P_ERSPAN packet with a 4-byte GRE header. Such a packet
> has no ERSPAN header, so the version is read from the inner destination
> MAC address, and if that happens to be 1 or 2, the start of the inner
> frame is stripped as an ERSPAN header. Reject these packets too.
> 
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>

Reviewed-by: Ido Schimmel <idosch@nvidia.com>