[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF=yD-KGO=+=j3yTr4H8cF_WH3RGtnyMDgYRzd7da-r7D=U=GQ@mail.gmail.com>
Date: Wed, 9 May 2018 12:38:11 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Eric Biggers <ebiggers3@...il.com>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
Eric Dumazet <edumazet@...gle.com>,
syzbot <syzbot+71d74a5406d02057d559@...kaller.appspotmail.com>,
alexander.deucher@....com,
Andrey Konovalov <andreyknvl@...gle.com>,
Anoob Soman <anoob.soman@...rix.com>, chris@...is-wilson.co.uk,
David Miller <davem@...emloft.net>,
"Reshetova, Elena" <elena.reshetova@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Kees Cook <keescook@...omium.org>,
LKML <linux-kernel@...r.kernel.org>,
Mike Maloney <maloney@...gle.com>, mchehab@...nel.org,
netdev <netdev@...r.kernel.org>,
"Rosen, Rami" <rami.rosen@...el.com>,
Sowmini Varadhan <sowmini.varadhan@...cle.com>,
syzkaller-bugs@...glegroups.com,
Willem de Bruijn <willemb@...gle.com>
Subject: Re: KASAN: use-after-free Read in __dev_queue_xmit
>> 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).
Powered by blists - more mailing lists