Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp345134ybl; Tue, 28 Jan 2020 04:21:31 -0800 (PST) X-Google-Smtp-Source: APXvYqyBJ0N84uVXQ5JJMuCkQLEa0V5+5DVInHDlzOfwfTbwTZDWearjw5f0ZJmPljeCGVc6v0z+ X-Received: by 2002:a9d:21f5:: with SMTP id s108mr16930416otb.152.1580214091054; Tue, 28 Jan 2020 04:21:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580214091; cv=none; d=google.com; s=arc-20160816; b=avIAC8GR4W3R2wJt5BzI340UCvWi3AWT9lVP9trmjuincvK6qd1Dzi6uYE2AKnu8Co pIpIpVpRim0BCgzwwvjkw8zfDkCkWAK13CpJbEFE6iQld3qkzCAS9VBt+u6On4wijxZA Q28wflQdF1lkRSxJ18EG3zCAZs/wd7Y0ZApn/IU8NUJ3G6fXAtSlHovBVMz0UV6AjQ+2 FJq1ztoA95A9WBOMTY+0K//TxtFnYhftx5IPZBCVHfY1nJ/3zuYJzmap4b4EsyLaOqwj f4YlY/+cPlGaoayp3RmHs4BqAZWKxk40Oksk9EGazbFainn5kU8ky3FuuqWLR91k6pL3 6CLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=hdMgsrTiGncdYOgcbUb9mlCe9olQ7xYagcxpFIcd6+E=; b=x4uDTONNaOsHR7HpZsLiY4NamBEFK6etUtprK8Rca8ekzhIWvePrz+7HlSb90AuzAp 4BVE57hgbRjC75pbGdx15pNxbceZrXqQtctZt75ldpAm3RCTGK9YpzFPhrJFjZC1XM/4 rakl7AppWflveQFjuj5iEDPDu2fY8DtgCve8Yw5BBmzAUMWV1Pi/W6ti3RDieofZ7/XN rBPv0s4NCpEVSgM4z7kR40D1/IehuwC/j/vCPye+gKTamPXs8YDiiMNdllQMDynhYeYv D8lZf3Xi90iO39Lnv8L2j8WGiRogGLD1zzVOByJlKlGND+zsQdJ1yLb8CL1Erjmci/RW S6Yw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=j8Uvap6k; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b25si8331335otp.212.2020.01.28.04.21.18; Tue, 28 Jan 2020 04:21:31 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=j8Uvap6k; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726059AbgA1MUY (ORCPT + 99 others); Tue, 28 Jan 2020 07:20:24 -0500 Received: from mail-oi1-f194.google.com ([209.85.167.194]:39906 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725948AbgA1MUY (ORCPT ); Tue, 28 Jan 2020 07:20:24 -0500 Received: by mail-oi1-f194.google.com with SMTP id z2so10078949oih.6 for ; Tue, 28 Jan 2020 04:20:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hdMgsrTiGncdYOgcbUb9mlCe9olQ7xYagcxpFIcd6+E=; b=j8Uvap6kQWXoH1g7T0rcgZ04DrKktnfIlbnAjWMfP6Xff15gUkzPDQyaJudmsL1yDt Pb+vDR13QDZ1Ao2bxVflMcVglbNMcWn9vAZMCrxHoLBYDoD6bY2lDG7asXPOG50omDI8 dk5DIW0lN8yO+3QsjLezBreSJU6k/SztMUCNHfHgKIc2Cg5MDJi/GcJ/7WIZcrVJi1kh 0zHT2ERZ9mrZaEMn2TbChsjOz7VewVpcBB1/Yf2BzW2fvghPbhLKD4ANgvNUlOkS8sa8 /8X4lSS3iRshCXuyTobDjzOHPqKpmwm1o88j0yDlyTev/lDOnbA4duQ/Ybwk7zHH2N3s UmpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hdMgsrTiGncdYOgcbUb9mlCe9olQ7xYagcxpFIcd6+E=; b=k5Rxh+su/EZ7gey4bnjY723gVPz94CzlM6oXdH8+jiMkq1MN03Gh1CYCCm/ORjNfb5 SsifWrUl/BigYLZeeN0FhoF4Czrcb6jH0qg8lns07vfyx3DGVeGOXTwBaFIfii8zI3R7 S8d/2aQpmCt+FeBb1dVX0W9fUzLyW9dUb8jfAiO2tI/UdmRaIuaSuyUYE6KMB5+5rkPf dla+pEKXjlwoJgmSpLtOIkfUTboesJ4ddxFHJH2RIlhGo0q2x8rp6k6QJOvZowuWVP/P srBU6kZ9S+XDk9lYfj8fm/m2gW+29v7aDweIOrYsdrOqS2o3A87xvCTtLeJ2anSiLBXy cbkA== X-Gm-Message-State: APjAAAWGw66yYLrZ1ICRa55n/r75Ww0J9nujW/+G8BjRpDzjeXNUwIpq 0NHBbG0NsUrlhau+/KEY3nKlizD61e/hLGRj/DrI2w== X-Received: by 2002:a54:4716:: with SMTP id k22mr2625237oik.39.1580214023416; Tue, 28 Jan 2020 04:20:23 -0800 (PST) MIME-Version: 1.0 References: <20200128072740.21272-1-frextrite@gmail.com> <20200128114818.GA17943@redhat.com> In-Reply-To: <20200128114818.GA17943@redhat.com> From: Jann Horn Date: Tue, 28 Jan 2020 13:19:56 +0100 Message-ID: Subject: Re: [PATCH] cred: Use RCU primitives to access RCU pointers To: Oleg Nesterov Cc: Amol Grover , David Howells , Shakeel Butt , James Morris , Kees Cook , Thomas Gleixner , kernel list , linux-kernel-mentees@lists.linuxfoundation.org, Joel Fernandes , Madhuparna Bhowmik , "Paul E . McKenney" , Casey Schaufler Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 28, 2020 at 12:48 PM Oleg Nesterov wrote: > On 01/28, Jann Horn wrote: > > On Tue, Jan 28, 2020 at 8:28 AM Amol Grover wrote: > > > task_struct.cred and task_struct.real_cred are annotated by __rcu, > > > > task_struct.cred doesn't actually have RCU semantics though, see > > commit d7852fbd0f0423937fa287a598bfde188bb68c22. For task_struct.cred, > > it would probably be more correct to remove the __rcu annotation? > > Yes, but get_task_cred() assumes it has RCU semantics... Oh, huh. AFAICS get_task_cred() makes no sense semantically, and I think it ought to be deleted. There are the following users at the moment: rdtgroup_task_write_permission() - uses it for acting on a task as object, should be using objective credentials instead. __cgroup1_procs_write() - same thing. task_state() - should also be using objective credentials instead, you wouldn't want a task to show up as belonging to root in there just because it's in the middle of some overlayfs filesystem method or something like that. apparmor_getprocattr() - same thing as for task_state() rpcauth_bind_root_cred() - should also be using objective credentials instead, if init is in overlayfs or whatever, you probably wouldn't want that to have an effect here prepare_kernel_cred() - most callers pass NULL and don't hit this codepath, and those that don't pass NULL use `current`, so there can be no concurrent modification. Maybe this could be rewritten to something like this: if (daemon) { BUG_ON(daemon != current); old = get_current_cred(); } else { ... } or maybe it could just use the objective creds, it shouldn't matter here, I think. > To be honest I didn't know we have this helper. Same here. > Can't it race with revert_creds() in > do_faccessat() ? Yeah, I think you can probably trigger use-after-free reads with that. I also remember seeing something fishy in Smack at some point that had similar issues... smack_file_send_sigiotask() does smk_of_task(smack_cred(tsk->cred)), which looks very wrong.