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

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

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@gmail.com/