From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Rainer Weikusat <rweikusat@mobileactivedefense.com>,
Eric Dumazet <edumazet@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Benjamin LaHaise <bcrl@kvack.org>,
"David S. Miller" <davem@davemloft.net>,
Hannes Frederic Sowa <hannes@stressinduktion.org>,
Al Viro <viro@zeniv.linux.org.uk>,
David Howells <dhowells@redhat.com>,
Ying Xue <ying.xue@windriver.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
syzkaller <syzkaller@googlegroups.com>,
Kostya Serebryany <kcc@google.com>,
Alexander Potapenko <glider@google.com>,
Sasha Levin <sasha.levin@oracle.com>
Subject: Re: use-after-free in sock_wake_async
Date: Wed, 25 Nov 2015 18:24:51 +0000 [thread overview]
Message-ID: <87610q3pjg.fsf@doppelsaurus.mobileactivedefense.com> (raw)
In-Reply-To: <1448473891.24696.21.camel@edumazet-glaptop2.roam.corp.google.com> (Eric Dumazet's message of "Wed, 25 Nov 2015 09:51:31 -0800")
Eric Dumazet <eric.dumazet@gmail.com> writes:
> On Wed, 2015-11-25 at 17:30 +0000, Rainer Weikusat wrote:
>
>> In case this is wrong, it obviously implies that sk_sleep(sk) must not
>> be used anywhere as it accesses the same struck sock, hence, when that
>> can "suddenly" disappear despite locks are used in the way indicated
>> above, there is now safe way to invoke that, either, as it just does a
>> rcu_dereference_raw based on the assumption that the caller knows that
>> the i-node (and the corresponding wait queue) still exist.
>>
>
> Oh well.
>
> sk_sleep() is not used if the return is NULL
static long unix_stream_data_wait(struct sock *sk, long timeo,
struct sk_buff *last, unsigned int last_len)
{
struct sk_buff *tail;
DEFINE_WAIT(wait);
unix_state_lock(sk);
for (;;) {
prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
tail = skb_peek_tail(&sk->sk_receive_queue);
if (tail != last ||
(tail && tail->len != last_len) ||
sk->sk_err ||
(sk->sk_shutdown & RCV_SHUTDOWN) ||
signal_pending(current) ||
!timeo)
break;
set_bit(SOCK_ASYNC_WAITDATA, &sk->sk_socket->flags);
unix_state_unlock(sk);
timeo = freezable_schedule_timeout(timeo);
unix_state_lock(sk);
if (sock_flag(sk, SOCK_DEAD))
break;
clear_bit(SOCK_ASYNC_WAITDATA, &sk->sk_socket->flags);
}
finish_wait(sk_sleep(sk), &wait);
unix_state_unlock(sk);
return timeo;
}
Neither prepare_to_wait nor finish_wait check if the pointer is
null. For the finish_wait case, it shouldn't be null because if
SOCK_DEAD is not found to be set after the unix_state_lock was acquired,
unix_release_sock didn't execute the corresponding code yet, hence,
inode etc will remain available until after the corresponding unlock.
But this isn't true anymore if the inode can go away despite
sock_release couldn't complete yet.
next prev parent reply other threads:[~2015-11-25 18:24 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-24 14:18 use-after-free in sock_wake_async Dmitry Vyukov
2015-11-24 15:21 ` Eric Dumazet
2015-11-24 15:39 ` Eric Dumazet
2015-11-24 21:30 ` Jason Baron
2015-11-24 21:40 ` Al Viro
2015-11-24 21:45 ` Benjamin LaHaise
2015-11-24 22:03 ` Eric Dumazet
2015-11-24 22:12 ` Eric Dumazet
2015-11-24 23:34 ` Rainer Weikusat
2015-11-24 23:43 ` Eric Dumazet
2015-11-25 1:10 ` Rainer Weikusat
2015-11-25 1:16 ` Rainer Weikusat
2015-11-25 1:18 ` Eric Dumazet
2015-11-25 2:28 ` Eric Dumazet
2015-11-25 5:43 ` Eric Dumazet
2015-11-25 14:18 ` Eric Dumazet
2015-11-25 16:43 ` Rainer Weikusat
2015-11-25 17:11 ` Eric Dumazet
2015-11-25 17:30 ` Rainer Weikusat
2015-11-25 17:51 ` Eric Dumazet
2015-11-25 18:24 ` Rainer Weikusat [this message]
2015-11-25 18:39 ` Eric Dumazet
2015-11-25 19:38 ` Rainer Weikusat
2015-11-25 19:50 ` Eric Dumazet
2015-11-25 20:23 ` Eric Dumazet
2015-11-25 20:57 ` Rainer Weikusat
2015-11-25 22:09 ` Eric Dumazet
2015-11-25 22:32 ` Hannes Frederic Sowa
2015-11-25 22:43 ` Eric Dumazet
2015-11-25 22:52 ` Hannes Frederic Sowa
2015-11-26 13:32 ` Hannes Frederic Sowa
2015-11-26 14:31 ` Hannes Frederic Sowa
2015-11-26 15:51 ` Eric Dumazet
2015-11-26 17:03 ` Hannes Frederic Sowa
2015-11-26 17:09 ` Eric Dumazet
2015-11-26 17:15 ` Hannes Frederic Sowa
2015-11-26 17:29 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87610q3pjg.fsf@doppelsaurus.mobileactivedefense.com \
--to=rweikusat@mobileactivedefense.com \
--cc=bcrl@kvack.org \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dvyukov@google.com \
--cc=ebiederm@xmission.com \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=glider@google.com \
--cc=hannes@stressinduktion.org \
--cc=kcc@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sasha.levin@oracle.com \
--cc=syzkaller@googlegroups.com \
--cc=viro@zeniv.linux.org.uk \
--cc=ying.xue@windriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).