Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755253AbbKYBSe (ORCPT ); Tue, 24 Nov 2015 20:18:34 -0500 Received: from mail-wm0-f49.google.com ([74.125.82.49]:33075 "EHLO mail-wm0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754255AbbKYBS2 (ORCPT ); Tue, 24 Nov 2015 20:18:28 -0500 MIME-Version: 1.0 In-Reply-To: <87io4qevdp.fsf@doppelsaurus.mobileactivedefense.com> References: <87poyzj7j2.fsf@doppelsaurus.mobileactivedefense.com> <87io4qevdp.fsf@doppelsaurus.mobileactivedefense.com> Date: Tue, 24 Nov 2015 17:18:27 -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: 1884 Lines: 42 On Tue, Nov 24, 2015 at 5:10 PM, Rainer Weikusat wrote: > > The af_unix part of this, yes, ie, what gets allocated in > unix_create1. But neither the socket inode nor the struct sock > originally passed to unix_create. Since these are part of the same > umbrella structure, they'll both be freed as consequence of the > sock_release iput. As far as I can tell (I don't claim that I'm > necessarily right on this, this is just the result of spending ca 2h > reading the code with the problem report in mind and looking for > something which could cause it), doing a sock_hold on the unix peer of > the socket in unix_stream_sendmsg is indeed not needed, however, there's > no additional reference to the inode or the struct sock accompanying it, > ie, both of these will be freed by unix_release_sock. This also affects > unix_dgram_sendmsg. > > It's also easy to verify: Swap the unix_state_lock and > other->sk_data_ready and see if the issue still occurs. Right now (this > may change after I had some sleep as it's pretty late for me), I don't > think there's another local fix: The ->sk_data_ready accesses a > pointer after the lock taken by the code which will clear and > then later free it was released. It seems that : int sock_wake_async(struct socket *sock, int how, int band) should really be changed to int sock_wake_async(struct socket_wq *wq, int how, int band) So that RCU rules (already present) apply safely. sk->sk_socket is inherently racy (that is : racy without using sk_callback_lock rwlock ) Other possibility would be _not_ calling sock_orphan() from unix_release_sock() -- 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/