netdev - Re: KASAN: use-after-free Read in __dev_queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 9 May 2018 15:21:33 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Eric Biggers <ebiggers3@...il.com>
Cc:     Eric Dumazet <eric.dumazet@...il.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

On Wed, May 9, 2018 at 12:38 PM, Willem de Bruijn
<willemdebruijn.kernel@...il.com> wrote:
>>> 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.

Indeed. The skb shared info struct is zeroed by dev_validate_header
as a result of dev->hard_header_len exceeding skb->end - skb->data.

Not exactly sure yet how this can happen. The hard header length space
is accounted for during allocation as reserved memory. But,
packet_alloc_skb does call skb_reserve(), moving skb->data
effectively beyond this reserved region.

It may be incorrect to pass skb->data to dev_validate_header, as that
does not point to the start of the ll_header anymore. Still figuring out what
the right fix is..