Re: KASAN: use-after-free Read in __dev_queue_xmit

[Willem de Bruijn]

>> But a crash with the same signature is still occurring, so it should eventually
>> get reported again.  C reproducer is here, it works on Linus' tree (commit
>> 036db8bd963): https://syzkaller.appspot.com/text?tag=ReproC&x=105b1ae7800000
>
> This appears to be a separate issue.
>
> This reproducer requires a setsockopt SOL_SOCKET/SO_TIMESTAMPING
> to trigger the use-after-free. And the freed path also points at a timestamping
> skb:
>
> [   31.963619] Freed by task 2672:
> [   31.964006]  __kasan_slab_free+0x125/0x170
> [   31.964509]  kfree+0x8b/0x1a0
> [   31.964875]  skb_free_head+0x6f/0xa0
> [   31.965314]  skb_release_data+0x420/0x5a0
> [   31.965802]  skb_release_all+0x46/0x60
> [   31.966260]  kfree_skb+0x91/0x1c0
> [   31.966669]  __skb_complete_tx_timestamp+0x2e9/0x3d0
> [   31.967273]  __skb_tstamp_tx+0x3b3/0x620
> [   31.967774]  __dev_queue_xmit+0xed5/0x1a20
> [   31.968300]  packet_sendmsg+0x36fd/0x5400
> [   31.968821]  sock_sendmsg+0xc0/0x100
> [   31.969284]  ___sys_sendmsg+0x367/0x880
> [   31.969777]  __sys_sendmmsg+0x178/0x410
> [   31.970267]  __x64_sys_sendmmsg+0x99/0x100
> [   31.970789]  do_syscall_64+0x9a/0x2c0
> [   31.971260]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

This is a rare path taken when the timestamp skb cannot be queued
onto the socket (likely because of insufficient rcvbuf).

Somehow, freeing the timestamp skb triggers this use-after-free in
the original skb from which the timestamp was cloned. As if there
is a bug in the shared info dataref.

The report does occur on reading a shinfo field (gso_size).