Re: [PATCH net-next v4 2/5] net: dsa: mv88e6xxx: use ARRIVAL1 counter for all peer delay messages

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing SKB Linearization for PTP Header Access
--

--- Patch [2]: [PATCH net-next v4 2/5] net: dsa: mv88e6xxx: use ARRIVAL1 counter for all peer delay messages ---
commit 4e21fb1f9ef35cdb7536e32b19f9424e5f8c90e2
Author: Luke Howard <lukeh@padl.com>

net: dsa: mv88e6xxx: use ARRIVAL1 counter for all peer delay messages

This commit updates the mv88e6xxx driver to use the second arrival counter
(ARRIVAL1) for PDelayReq messages as well as PDelayResp messages. This allows
capturing timestamps for both when they arrive simultaneously from a peer.

> diff --git a/drivers/net/dsa/mv88e6xxx/hwtstamp.c b/drivers/net/dsa/mv88e6xxx/hwtstamp.c
> --- a/drivers/net/dsa/mv88e6xxx/hwtstamp.c
> +++ b/drivers/net/dsa/mv88e6xxx/hwtstamp.c
> @@ -323,9 +323,16 @@ static void mv88e6xxx_rxtstamp_work(struct mv88e6xxx_chip *chip,
>  				   &ps->rx_queue2);
>  }
>  
> -static int is_pdelay_resp(const struct ptp_header *hdr)
> +static bool is_pdelay_msg(const struct ptp_header *hdr)
>  {
> -	return (hdr->tsmt & 0xf) == 3;
> +	switch (ptp_get_msgtype(hdr, PTP_CLASS_V2)) {

[Severity: High]
This is a pre-existing issue, but can this dereference of the header cause an
out-of-bounds read if the PTP packet is fragmented?

Looking at ptp_parse_header() which provides the hdr pointer, it ensures the
header is within the total length of the SKB, but it does not seem to check if
it is within the linear data buffer:

net/core/ptp_classifier.c:ptp_parse_header() {
    ...
	/* Ensure that the entire header is present in this packet. */
	if (ptr + sizeof(struct ptp_header) > skb->data + skb->len)
		return NULL;

	return (struct ptp_header *)ptr;
}

If a maliciously crafted or fragmented PTP packet pushes the header into the
non-linear paged fragments, could this direct pointer access read past the
linear boundary when ptp_get_msgtype() accesses hdr->tsmt?

The same concern seems to apply to the read of hdr->sequence_id in
mv88e6xxx_port_txtstamp() on the TX path.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727-mv88e6xxx-ptp-fixes-v4-0-10b4020155fc@padl.com?part=2