Re: [PATCH v2] can: restore skb header initialisations in init_can_skb()

[Quchaosheng]

Hello zjamg,

I reproduced the panic independently and verified that your patch alone
fixes it, so:

Tested-by: Quchaosheng <quchaosheng000406@xxxxxxx>

How I tested, in case it is useful for the maintainers.  The driver RX
path is required: vcan does not reproduce it, because can_send() resets
the headers itself on the way out.  I used slcan over a pty, opened a
SOCK_PACKET socket on the resulting can0, and pushed one frame in through
the line discipline.  Two kernels, same config, same initramfs, only your
patch differing.

Without the patch, v7.3.0-rc5 under QEMU:

  skbuff: skb_under_panic: text:ffffffffa0b28261 len:-65455 put:-65471 head:... data:... tail:0x50 end:0x180 dev:can0
  kernel BUG at net/core/skbuff.c:214!
  RIP: 0010:skb_panic+0x50/0x60
  Call Trace:
   <TASK>
   skb_push+0x4d/0x60
   packet_rcv_spkt+0xe1/0x170
  Kernel panic - not syncing: Fatal exception in interrupt

  (the len/put values match the ones in your report)

With your v2 applied verbatim, the identical run prints

  RESULT: survived, no skb_under_panic

and the guest powers off normally.

One note that may be worth adding to the commit message if you respin: the
2015 fix you reference, 969439016d2c, is the second time this class of bug
was closed on the producer side.  packet_rcv_spkt() has still never been
hardened, which is why the same failure mode came back a third time when
9f10374bb024 dropped the calls again.  I sent a separate patch for that
receiver-side guard so the next regression of this kind degrades to a
dropped frame instead of a panic - no overlap with this one, and yours is
the one that fixes the actual regression.

Thanks for picking this up,
Quchaosheng