Re: [PATCH v3 net] net/packet: guard the ll header push in packet_rcv_spkt()

From: Willem de Bruijn

Date: Wed Sep 30 2026 - 21:03:16 EST


netdev-bot+sashiko@ wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider.
>
> Critical: 0 · High: 0 (2) · Medium: 1 · Low: 0
>
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
>
> - [Medium] The history and Fixes attribution in the commit message are
> inaccurate.
>
> Pre-existing issues:
> - [High] This problem wasn't introduced by this patch, but the same CAN
> RX skb with mac_header == 0xFFFF (left that way by init_can_skb()…
> - [High] This problem wasn't introduced by this patch, but the
> SOCK_PACKET receive path this patch touches leaks stale skb->cb bytes…
>

> [Severity: High]
> This is a pre-existing issue, but further down, packet_rcv_spkt() builds
> the sockaddr_pkt in place in skb->cb:
>
> spkt->spkt_family = dev->type;
> strscpy(spkt->spkt_device, dev->name, sizeof(spkt->spkt_device));
> spkt->spkt_protocol = skb->protocol;
>
> strscpy() writes strlen(name) + 1 bytes and doesn't pad, and nothing clears
> the rest of spkt_device. packet_recvmsg() then copies the full
> sizeof(struct sockaddr_pkt) to userspace:
>
> memcpy(msg->msg_name, &PACKET_SKB_CB(skb)->sa, copy_len);
>
> Can this leak stale skb->cb bytes to userspace?

This is being addressed in a separate fix that is in the review process:

https://lore.kernel.org/netdev/20260919215237.3470987-1-benquike@xxxxxxxxx/