Hi,

This series fixes a regression of the classic skb_under_panic in
packet_rcv_spkt() that was originally fixed in 2015 and re-introduced by
9f10374bb024 ("can: remove private CAN skb headroom infrastructure").

#regzbot introduced: 9f10374bb024

When an RX CAN skb (mac_header still at the 0xFFFF sentinel) reaches a
SOCK_PACKET socket, the length calculation in skb_push() overflows and
triggers skb_under_panic -> kernel BUG -> full machine panic. Because the
BUG occurs in softirq context, the machine panics even when
panic_on_oops=0.

Call chain (confirmed on 7.3.0-rc2, arm64 qemu):

  slcan_bump_frame
    -> alloc_can_skb          (init_can_skb no longer resets mac_header)
    -> netif_rx
    -> process_backlog
    -> __netif_receive_skb_core
    -> deliver_skb
    -> packet_rcv_spkt        <- sink (af_packet.c:1914)

Historical context:

  - 2014-07: Originally reported by Austin Schuh on linux-can
  - 2015-02: Fixed by 969439016d2c (producer-side resets)
  - 2020:    packet_rcv / tpacket_rcv got dev_has_header() checks;
             packet_rcv_spkt was left unprotected
  - 2026-02: 9f10374bb024 deleted the resets -> regression re-introduced

Patch 1 restores the three skb_reset_*_header() calls in init_can_skb(),
matching the 2015 fix.

I also prepared a defensive check in packet_rcv_spkt() itself
(skb_mac_header_was_set()), which would protect against any future
producer that forgets to set the mac header. I can send it separately
if the maintainers would like it.

Reproducer (100% reliable):

  modprobe can can-dev slcan
  # attach N_SLCAN to a pty pair, bring can0 up
  # create SOCK_PACKET socket bound to can0
  echo -ne "t1238DEADBEEFDEADBEEF\r" > /dev/pts/X

Result:
  skbuff: skb_under_panic: len:-65455 put:-65471 ...
  kernel BUG at net/core/skbuff.c:214!
  Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt

Thanks.