Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp2747573pxb; Mon, 31 Jan 2022 03:31:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJz3XuC8iMx6v3ASnT+lBydwOmQ6jMiNURDQRxhlsLlHwYHpaXpzxF4j0/CstRJ3FsrIq0x7 X-Received: by 2002:a17:902:e74a:: with SMTP id p10mr20420032plf.16.1643628674001; Mon, 31 Jan 2022 03:31:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643628673; cv=none; d=google.com; s=arc-20160816; b=YK6m22zklWbXso9A525cqY9T6q7KLwMt2he9GruH0V2qk1LJJB9xdL7UVnqg4uFgOF U3RYdui9A611+iF8OKmVVx8El7nHrODphPC+yiWYOKQ1t2NuBELb7PbVzehDvAZrOZSX UpWpkUgkvq+ZhyW41Db91H/twX1tNpxkKd3vKwMQG/HQHZ/5PtSEfRlp+GJdqIS42H4N aOuYQT/q/LNSFiBa68mc7NOvD0+Jsji0EDxle8WXC3ILwlbryNxz3KGvOOxH0VceNQ7s 5m65sakJp1h7Amq8l9phzYUDkH3mcP+dVp6gpdULjgRR6S4haNjC/lY+JRzrxY/dVbtK iRow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=J9y2by9UifiGK2iQbj8ezMPJrN7PeMnk6RdIcj/KsLw=; b=g+47THtptsRJp58RA5uunYxbMdCGABbXax5UHlHQrjf24vGnld8WaJJi4nodrafdAe JdMK6/XWj4SYNHmiQ9Sy+ifkFOh0qrkBMd+ScBSiJh4EP7VDvOYJlDowPi0EMs7U/MqJ fiqpKBj9nUlZpYRByj5THCxayFO7HV5P4b/PHwAol32RnDfC6BR97gFC1sqvtc8Twsn+ Ong+0T++PjJx/ziqi/qAbMF9kKTUmMWEFBMA+WMtsxgQe4tKbGwdlOswVYwfxuKeDxI6 OI9obvHZ5+QDURC5xU/YfabZt3x+uCbjdV7jjaqwE7kndFVpawNOPEDtr66IAe/En/Nc TUHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=u5OjJY5X; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q7si13984957pgk.345.2022.01.31.03.31.03; Mon, 31 Jan 2022 03:31:13 -0800 (PST) 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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=u5OjJY5X; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350579AbiA1Sed (ORCPT + 99 others); Fri, 28 Jan 2022 13:34:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229827AbiA1Se3 (ORCPT ); Fri, 28 Jan 2022 13:34:29 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA07AC061714 for ; Fri, 28 Jan 2022 10:34:29 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 47D2761CEC for ; Fri, 28 Jan 2022 18:34:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C665BC340EA; Fri, 28 Jan 2022 18:34:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643394868; bh=qc2srDJ/Tr/4ioZ7NvjqTJDjb9MXIJRHw3QP9k8RdMM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=u5OjJY5X3oKqZEg+u4pRnQLY6p6bUrZUtD3XGdF5VuT+Ig+6nkvSCPF2JzFnxFFj+ HYTNj4Vpxq+xe4R8rVScMZdLvYAYxnjpqQNEZEisUuPZOiHLkqIrlGr61D5UYIF2IY YI7Nfrd2YctZE9ohtuwiJ61n7viksHkGEA4/Yv04RnX/OdGDk8ncasrqx1vzVxRHgx pX0ZgK9ZOaVMtXBJVIqXv6CfEd3trjfyCQTw+pIKeTnn1pOpqZu7nyoJNlwtC1T2zp kSSdj7/RSzN8tEVKPOPYaYPVp1FuvUf7yPK0/8D4jKOqzanG+AC3q6Op2kQ91nZ+bB ZD1xTZ5dVFEug== Date: Fri, 28 Jan 2022 19:34:23 +0100 From: Christian Brauner To: "Eric W. Biederman" Cc: Linus Torvalds , linux-kernel@vger.kernel.org, Alexey Gladkov , Qian Cai , Mathias Krause , Linux Containers Subject: Re: [GIT PULL] ucount rlimit fixes for v5.17-rc2 Message-ID: <20220128183423.d5z7v46opgphrbdb@wittgenstein> References: <871r0rss9q.fsf@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <871r0rss9q.fsf@email.froward.int.ebiederm.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 28, 2022 at 11:07:45AM -0600, Eric W. Biederman wrote: > > Linus, > > Please pull the ucount-rlimit-fixes-for-v5.17-rc2 branch from the git tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git ucount-rlimit-fixes-for-v5.17-rc2 > HEAD: f9d87929d451d3e649699d0f1d74f71f77ad38f5 ucount: Make get_ucount a safe get_user replacement > > > From: "Eric W. Biederman" > Date: Mon, 24 Jan 2022 12:46:50 -0600 > Subject: [PATCH] ucount: Make get_ucount a safe get_user replacement > > When the ucount code was refactored to create get_ucount it was missed > that some of the contexts in which a rlimit is kept elevated can be > the only reference to the user/ucount in the system. > > Ordinary ucount references exist in places that also have a reference > to the user namspace, but in POSIX message queues, the SysV shm code, > and the SIGPENDING code there is no independent user namespace > reference. > > Inspection of the the user_namespace show no instance of circular > references between struct ucounts and the user_namespace. So > hold a reference from struct ucount to it's user_namespace to > resolve this problem. > > Link: https://lore.kernel.org/lkml/YZV7Z+yXbsx9p3JN@fixkernel.com/ > Reported-by: Qian Cai > Reported-by: Mathias Krause > Tested-by: Mathias Krause > Reviewed-by: Mathias Krause > Reviewed-by: Alexey Gladkov > Fixes: d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts") > Fixes: 6e52a9f0532f ("Reimplement RLIMIT_MSGQUEUE on top of ucounts") > Fixes: d7c9e99aee48 ("Reimplement RLIMIT_MEMLOCK on top of ucounts") > Cc: stable@vger.kernel.org > Signed-off-by: "Eric W. Biederman" > --- Hey, Please ensure that next time a security issue is reported to security@kernel.org for userns such as this UAF that the pull request that gets sent to fix this issue Ccs the containers development list. This whole ucount conversion has been quite problematic so far. And that's not the problem, bugs happen. But fixes for bugs that were reported as security issues should at least have visibility on the right lists so people don't go and get pinged about them on Twitter [1]. A Cc for the oss-security list would've also sufficed where most of us are subscribed. None of this is pleasant, I very much sympathise. Thanks for fixing this, and thanks to Mathias for the report. [1]: https://twitter.com/grsecurity/status/1487119590425600005 > kernel/ucount.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/ucount.c b/kernel/ucount.c > index 7b32c356ebc5..65b597431c86 100644 > --- a/kernel/ucount.c > +++ b/kernel/ucount.c > @@ -190,6 +190,7 @@ struct ucounts *alloc_ucounts(struct user_namespace *ns, kuid_t uid) > kfree(new); > } else { > hlist_add_head(&new->node, hashent); > + get_user_ns(new->ns); > spin_unlock_irq(&ucounts_lock); > return new; > } > @@ -210,6 +211,7 @@ void put_ucounts(struct ucounts *ucounts) > if (atomic_dec_and_lock_irqsave(&ucounts->count, &ucounts_lock, flags)) { > hlist_del_init(&ucounts->node); > spin_unlock_irqrestore(&ucounts_lock, flags); > + put_user_ns(ucounts->ns); > kfree(ucounts); > } > } > -- > 2.29.2 > > eric >