From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ABBEBC43461 for ; Tue, 13 Apr 2021 17:54:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7126C613B6 for ; Tue, 13 Apr 2021 17:54:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230179AbhDMRyb (ORCPT ); Tue, 13 Apr 2021 13:54:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:45858 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345824AbhDMRyW (ORCPT ); Tue, 13 Apr 2021 13:54:22 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7B65461249; Tue, 13 Apr 2021 17:53:58 +0000 (UTC) Date: Tue, 13 Apr 2021 19:53:55 +0200 From: Christian Brauner To: Rodrigo Campos Cc: Kees Cook , Andy Lutomirski , Will Drewry , linux-kernel@vger.kernel.org, containers@lists.linux-foundation.org, Sargun Dhillon , Mauricio =?utf-8?Q?V=C3=A1squez?= Bernal , Alban Crequy , stable@vger.kernel.org Subject: Re: [PATCH 1/1] seccomp: Always "goto wait" if the list is empty Message-ID: <20210413175355.kttgdouoyiykug5i@wittgenstein> References: <20210413160151.3301-1-rodrigo@kinvolk.io> <20210413160151.3301-2-rodrigo@kinvolk.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210413160151.3301-2-rodrigo@kinvolk.io> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 13, 2021 at 06:01:51PM +0200, Rodrigo Campos wrote: > It is possible for the thread with the seccomp filter attached (target) > to be waken up by an addfd message, but the list be empty. This happens > when the addfd ioctl on the other side (seccomp agent) is interrupted by > a signal such as SIGURG. In that case, the target erroneously and > prematurely returns from the syscall to userspace even though the > seccomp agent didn't ask for it. > > This happens in the following scenario: > > seccomp_notify_addfd() | seccomp_do_user_notification() > | > | err = wait_for_completion_interruptible(&n.ready); > complete(&knotif->ready); | > ret = wait_for_completion_interruptible(&kaddfd.completion); | > // interrupted | > | > mutex_lock(&filter->notify_lock); | > list_del(&kaddfd.list); | > mutex_unlock(&filter->notify_lock); | > | mutex_lock(&match->notify_lock); > | // This is false, addfd is false > | if (addfd && n.state != SECCOMP_NOTIFY_REPLIED) > | > | ret = n.val; > | err = n.error; > | flags = n.flags; > > So, the process blocked in seccomp_do_user_notification() will see a > response. As n is 0 initialized and wasn't set, it will see a 0 as > return value from the syscall. > > The seccomp agent, when retrying the interrupted syscall, will see an > ENOENT error as the notification no longer exists (it was already > answered by this bug). > > This patch fixes the issue by splitting the if in two parts: if we were > woken up and the state is not replied, we will always do a "goto wait". > And if that happens and there is an addfd element on the list, we will > add the fd before "goto wait". > > This issue is present since 5.9, when addfd was added. > > Fixes: 7cf97b1254550 > Cc: stable@vger.kernel.org # 5.9+ > Signed-off-by: Rodrigo Campos > --- So the agent will see the return value from wait_for_completion_interruptible() and know that the addfd wasn't successful and the target will notice that no addfd request has actually been added and essentially try again. Seems like a decent fix and can be backported cleanly. I assume seccomp testsuite passes. Acked-by: Christian Brauner