Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp322667pxk; Wed, 2 Sep 2020 02:13:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzd3ichBpRcy7IE4XYpOOJEL8gQC/cwXlFK3BsMeIeK99JGR0QCYPcSG69Wyp2lZ7O2ixjx X-Received: by 2002:a17:906:a0c2:: with SMTP id bh2mr5562646ejb.493.1599038022751; Wed, 02 Sep 2020 02:13:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599038022; cv=none; d=google.com; s=arc-20160816; b=WlsDyNEVo1ewn3yU6a1Vos0EgaydKFLVytDEEDHUS1cHPgs6hgtPejMSNO0RDy6sDf Wac5wX/438865GrzTjeZEtp2kDgic1Z5K6qwKBmZrqoM/hcLiUfYgG5joaswoUhm2KYA 4LzN+xEh6ZgsR+jx9X3JE7KNCR326hbKiugIITqeTN6xj/fTFFo7U7XTbPQVYyaS6z7+ e9MfJJKufZJiGq6xQmA2wrwn6xjmfloCpagEt7YipLnSbUT5gVWwKmusrLSYTbA7Wcz9 wYE2iQnKyRTPzlGmCeuOZhNvqywLvtriJzH890KDper6YxYEiNGZMeJ4WKmSXeq7khnE WCAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=pNxU6BU/9b1+cmZaLkV9OU6SX7nhPqt6ub/pmsbR6Dw=; b=UpfwAoOAQL54lYjMYb5Birc3R+BRhqnNVlT62Z8wStv2AzISeXmEThfXx6bPi47F4O WYA7R2y/bCWRMkF4i+JRdidFgj4lwiY2w1wVRDfs6F5CCYRb8UsuX5BddBjw9VLibWMp vtziGMTWGsgFo1Hus5NNJ98Bzkx79haTwdfCpPSPp6RXp+fbNZQ1AWw9eAeFHOK7aKxI sx3tRaL5L3d2AmzT+6U8bAdJYd6dBGR4MbJUaY0bJ9sR+7jMTWnSROJHcgPRuT45yQqs YgwwFnc3OpI8UPT4JIyKHaIZGU+uKCsr2d5ckExl7/5toGMxp1uWwjGIqFChkZ7Of39X s8rg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c2si2147553ejs.702.2020.09.02.02.13.18; Wed, 02 Sep 2020 02:13:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726285AbgIBJIx (ORCPT + 99 others); Wed, 2 Sep 2020 05:08:53 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:47035 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726140AbgIBJIx (ORCPT ); Wed, 2 Sep 2020 05:08:53 -0400 Received: from ip5f5af70b.dynamic.kabel-deutschland.de ([95.90.247.11] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kDOl8-0000WB-GK; Wed, 02 Sep 2020 09:08:50 +0000 Date: Wed, 2 Sep 2020 11:08:49 +0200 From: Christian Brauner To: Tycho Andersen Cc: Kees Cook , linux-kernel@vger.kernel.org, "Tobin C . Harding" , Christian Brauner , syzbot+3ad9614a12f80994c32e@syzkaller.appspotmail.com Subject: Re: [PATCH 1/2] seccomp: don't leak memory when filter install races Message-ID: <20200902090849.bvevcuhtae73pplm@wittgenstein> References: <20200902014017.934315-1-tycho@tycho.pizza> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200902014017.934315-1-tycho@tycho.pizza> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 01, 2020 at 07:40:16PM -0600, Tycho Andersen wrote: > In seccomp_set_mode_filter() with TSYNC | NEW_LISTENER, we first initialize > the listener fd, then check to see if we can actually use it later in > seccomp_may_assign_mode(), which can fail if anyone else in our thread > group has installed a filter and caused some divergence. If we can't, we > partially clean up the newly allocated file: we put the fd, put the file, > but don't actually clean up the *memory* that was allocated at > filter->notif. Let's clean that up too. > > To accomplish this, let's hoist the actual "detach a notifier from a > filter" code to its own helper out of seccomp_notify_release(), so that in > case anyone adds stuff to init_listener(), they only have to add the > cleanup code in one spot. This does a bit of extra locking and such on the > failure path when the filter is not attached, but it's a slow failure path > anyway. > > Fixes: 51891498f2da ("seccomp: allow TSYNC and USER_NOTIF together") > Reported-by: syzbot+3ad9614a12f80994c32e@syzkaller.appspotmail.com > Signed-off-by: Tycho Andersen > --- This looks sane to me! Acked-by: Christian Brauner One thing I noticed when checking the failure paths. In init_listener we allocate the notifier by directly storing it into filter->notif and if anon_inode_getfile() fails we simply kfree(filter->notif) but don't NULL it and leave filter->notif pointing to freed memory. Since we have a few places where we check filter->notif whether it is initialized or not maybe we should NULL filter->notif if init_listener() fails or alloc the notifier into a tmp variable and only assign it to filter->notif after we can't fail anymore in init_listener(). Just a thought since the error path in seccomp_set_mode_filter() is a little more complex. :) Thanks! Christian