RE: [PATCH v6 net-next 09/15] net: dsa: add NETC switch tag support

> commit 497c9819ff3bedb82e4e40b92e407f5f3d81f984
> Author: Wei Fang <[email protected]>
> 
> net: dsa: add NETC switch tag support
> 
> This commit adds support for the NXP NETC proprietary switch tag to the DSA
> subsystem. It defines the NETC tag formats and implements the transmit,
> receive, and flow dissection operations for the new tag protocol.
> 
> > diff --git a/net/dsa/tag_netc.c b/net/dsa/tag_netc.c new file mode
> > 100644 index 0000000000000..b29aa54b19881
> > --- /dev/null
> > +++ b/net/dsa/tag_netc.c
> 
> [ ... ]
> 
> > +static void netc_flow_dissect(const struct sk_buff *skb, __be16 *proto,
> > +			      int *offset)
> > +{
> > +	struct netc_tag_cmn *tag_cmn = (struct netc_tag_cmn *)(skb->data - 2);
> > +	int tag_len = netc_get_rx_tag_len(tag_cmn->type);
> > +
> > +	*offset = tag_len;
> > +	*proto = ((__be16 *)skb->data)[(tag_len / 2) - 1];
> 
> Is it possible for the packet headers to span paged fragments when this is
> called?
> 
> Since flow_dissect takes a const struct sk_buff pointer and can be invoked
> on untrusted or non-linear SKBs (for example, those injected via AF_PACKET
> on the egress path), the linear portion of the buffer might be smaller
> than the expected tag length.
> 
> If tag_len reaches up to 14 bytes, these direct accesses to skb->data
> could read past the linear boundary and trigger a page fault or read
> uninitialized memory.
> 
> Would it be safer to use skb_header_pointer() here to reliably extract the
> tag and protocol fields instead of relying on direct pointer arithmetic?
> 

This is a false positive, or at least it can be ignored. The RX minimum frame
length of each NETC switch port is set to 64 bytes. The frame will be received
by the ENETC driver. From the hardware perspective, each RX BD receive
buffer is at least 128 bytes, so the skb's linear buffer will definitely contain
the switch tag.