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

commit 497c9819ff3bedb82e4e40b92e407f5f3d81f984
Author: Wei Fang [off-list ref]

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.

quoted

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

[ ... ]

quoted

+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.