>> 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).
