lkml.org 
[lkml]   [2018]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: KASAN: use-after-free Read in __dev_queue_xmit
On Wed, May 9, 2018 at 12:38 PM, Willem de Bruijn
<willemdebruijn.kernel@gmail.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..

\
 
 \ /
  Last update: 2018-05-09 21:22    [W:0.053 / U:0.644 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site