Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932615AbbKQWt2 (ORCPT ); Tue, 17 Nov 2015 17:49:28 -0500 Received: from tiger.mobileactivedefense.com ([217.174.251.109]:55798 "EHLO tiger.mobileactivedefense.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932355AbbKQWtY (ORCPT ); Tue, 17 Nov 2015 17:49:24 -0500 From: Rainer Weikusat To: Rainer Weikusat Cc: David Miller , jbaron@akamai.com, dvyukov@google.com, syzkaller@googlegroups.com, mkubecek@suse.cz, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, hannes@stressinduktion.org, dhowells@redhat.com, paul@paul-moore.com, salyzyn@android.com, sds@tycho.nsa.gov, ying.xue@windriver.com, netdev@vger.kernel.org, kcc@google.com, glider@google.com, andreyknvl@google.com, sasha.levin@oracle.com, jln@google.com, keescook@google.com, minipli@googlemail.com Subject: Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue (w/ Fixes:) In-Reply-To: <87d1v85mtx.fsf@doppelsaurus.mobileactivedefense.com> (Rainer Weikusat's message of "Tue, 17 Nov 2015 21:37:46 +0000") References: <87a8qhspfm.fsf@doppelsaurus.mobileactivedefense.com> <876111wpza.fsf@doppelsaurus.mobileactivedefense.com> <87ziydvasn.fsf_-_@doppelsaurus.mobileactivedefense.com> <20151117.151421.249423864481324472.davem@davemloft.net> <87d1v85mtx.fsf@doppelsaurus.mobileactivedefense.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Tue, 17 Nov 2015 22:48:52 +0000 Message-ID: <874mgk5jjf.fsf@doppelsaurus.mobileactivedefense.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (tiger.mobileactivedefense.com [217.174.251.109]); Tue, 17 Nov 2015 22:49:02 +0000 (GMT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1814 Lines: 63 Rainer Weikusat writes: [...] > This leaves only the option of a somewhat incorrect solution and what is > or isn't acceptable in this respect is somewhat difficult to decide. The > basic options would be [...] > - retry sending a limited number of times, eg, once, before > returning EAGAIN, on the grounds that this is nicer to the > application and that redoing all the stuff up to the _lock in > dgram_sendmsg can possibly/ likely be avoided Since it's better to have a specific example of something: Here's another 'code sketch' of this option (hopefully with less errors this time, there's an int restart = 0 above): if (unix_peer(other) != sk && unix_recvq_full(other)) { int need_wakeup; [...] need_wakeup = 0; err = 0; unix_state_unlock(other); unix_state_lock(sk); if (unix_peer(sk) == other) { if (++restart == 2) { need_wakeup = unix_dgram_peer_wake_connect(sk, other) && sk_receive_queue_len(other) == 0; err = -EAGAIN; } else if (unix_dgram_peer_wake_me(sk, other)) err = -EAGAIN; } else err = -EAGAIN; unix_state_unlock(sk); if (err || !restart) { if (need_wakeup) wake_up_interruptible_poll(sk_sleep(sk), POLLOUT | POLLWRNORM | POLLWRBAND); goto out_free; } goto restart; } I don't particularly like that, either, and to me, the best option seems to be to return the spurious EAGAIN if taking both locks unconditionally is not an option as that's the simplest choice. -- 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/