Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755599AbbKXXnw (ORCPT ); Tue, 24 Nov 2015 18:43:52 -0500 Received: from mail-wm0-f46.google.com ([74.125.82.46]:34019 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932500AbbKXXnu (ORCPT ); Tue, 24 Nov 2015 18:43:50 -0500 MIME-Version: 1.0 In-Reply-To: <87poyzj7j2.fsf@doppelsaurus.mobileactivedefense.com> References: <87poyzj7j2.fsf@doppelsaurus.mobileactivedefense.com> Date: Tue, 24 Nov 2015 15:43:48 -0800 Message-ID: Subject: Re: use-after-free in sock_wake_async From: Eric Dumazet To: Rainer Weikusat Cc: Dmitry Vyukov , Benjamin LaHaise , "David S. Miller" , Hannes Frederic Sowa , Al Viro , David Howells , Ying Xue , "Eric W. Biederman" , netdev , LKML , syzkaller , Kostya Serebryany , Alexander Potapenko , Sasha Levin Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3470 Lines: 98 On Tue, Nov 24, 2015 at 3:34 PM, Rainer Weikusat wrote: > Eric Dumazet writes: >> On Tue, Nov 24, 2015 at 6:18 AM, Dmitry Vyukov wrote: >>> Hello, >>> >>> The following program triggers use-after-free in sock_wake_async: > > [...] > >>> void *thr1(void *arg) >>> { >>> syscall(SYS_close, r2, 0, 0, 0, 0, 0); >>> return 0; >>> } >>> >>> void *thr2(void *arg) >>> { >>> syscall(SYS_write, r3, 0x20003000ul, 0xe7ul, 0, 0, 0); >>> return 0; >>> } > > [...] > >>> pthread_t th[3]; >>> pthread_create(&th[0], 0, thr0, 0); >>> pthread_create(&th[1], 0, thr1, 0); >>> pthread_create(&th[2], 0, thr2, 0); >>> pthread_join(th[0], 0); >>> pthread_join(th[1], 0); >>> pthread_join(th[2], 0); >>> return 0; >>> } > > [...] > >> Looks like commit 830a1e5c212fb3fdc83b66359c780c3b3a294897 should be reverted ? >> >> commit 830a1e5c212fb3fdc83b66359c780c3b3a294897 >> Author: Benjamin LaHaise >> Date: Tue Dec 13 23:22:32 2005 -0800 >> >> [AF_UNIX]: Remove superfluous reference counting in unix_stream_sendmsg >> >> AF_UNIX stream socket performance on P4 CPUs tends to suffer due to a >> lot of pipeline flushes from atomic operations. The patch below >> removes the sock_hold() and sock_put() in unix_stream_sendmsg(). This >> should be safe as the socket still holds a reference to its peer which >> is only released after the file descriptor's final user invokes >> unix_release_sock(). The only consideration is that we must add a >> memory barrier before setting the peer initially. >> >> Signed-off-by: Benjamin LaHaise >> Signed-off-by: David S. Miller > > JFTR: This seems to be unrelated. (As far as I understand this), the > problem is that sk_wake_async accesses sk->sk_socket. That's invoked via > the > > other->sk_data_ready(other) > > in unix_stream_sendmsg after an > > unix_state_unlock(other); > > because of this, it can race with the code in unix_release_sock clearing > this pointer (via sock_orphan). The structure this pointer points to is > freed via iput in sock_release (net/socket.c) after the af_unix release > routine returned (it's really one part of a "twin structure" with the > socket inode being the other). > > A quick way to test if this was true would be to swap the > > unix_state_unlock(other); > other->sk_data_ready(other); > > in unix_stream_sendmsg and in case it is, a very 'hacky' fix could be to > put a pointer to the socket inode into the struct unix_sock, do an iget > on that in unix_create1 and a corresponding iput in > unix_sock_destructor. This is interesting, but is not the problem or/and the fix. We are supposed to own a reference on the 'other' socket or make sure it cannot disappear under us. Otherwise, no matter what you do, it is racy to even access other->any_field In particular, you can trap doing unix_state_lock(other), way before the code you want to change. Please do not propose hacky things like iget or anything inode related, this is clearly af_unix bug. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/