Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3231043pxk; Mon, 7 Sep 2020 07:04:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxW2hLJ6EnxFyv8NajqdaNoMFhP4LPaKzmdwKrcZ4cZ4FPu4XeCFO1+w2uxEELbipjes9qI X-Received: by 2002:a50:ce09:: with SMTP id y9mr21419672edi.91.1599487443662; Mon, 07 Sep 2020 07:04:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599487443; cv=none; d=google.com; s=arc-20160816; b=CZokDMAiGcodTZygrCXkvhMt0s63f2AeVqHuXodh3zSLElbKu1lRWc+pcK9k8LlF5N SCAicD9PjxponJl1+4ZF9EqE/hZwcBvf3vFoZURkEQDd+clvRde4z2omfYDycKgs56Wq JLc+lkCJkll8yWuJZ6EzBp0W3vQQ53AxI5i45qfERmRh+gzG0FpwxsKfTPCOBo747tuz KkJsMuomfpfAxlIoGwVTcW5bVlTzwJ7kVPlZEz/JOmjI1dJFNPGFgqPt5nBxtx9yLALl rB6MdqiyieeRZuooPA7B1QvxMnBjgLQ1gE9wXasVA+5apMkT7N+NoICummYXgIYcZ0O/ veuw== 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=o/MU6LekjsaqUPMHLvSGn4qT2Aidzx+zWyzeNtI6Aco=; b=C1ZDaUQsJofCyfckxozxaMMkna5JLRvP+ia4OG8CBdzxGsGPf9Z/NusudL6arTH0tW 0DAIMHaVu3rL/xIM7ZLhOU5mK0hleo0cKzw4Pe6VGRyyFuH/DyC70VZyJH1ZiujxjO0N GAjhf6C0T3GLHrcFjwnpGYH0d2ac/td/WyYQSUBXJdktCXCX8YNTh/CYgaRYw0Vxeazb I8FzCN9PVWzneJtCJ4gifOwgfo3wZXjvVSBPE/rifMtXqrGs/wii5Y8d4g89e9VuvKK/ LRbYJfsyEl5+rVerYc26MlSO6IpH6PEx0dqUTkbt6dpqBwsL4YHk58IKhsDrxaaOUsrC QtBQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20150623.gappssmtp.com header.s=20150623 header.b=ICxs3B8O; 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=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w14si9702109edx.50.2020.09.07.07.03.40; Mon, 07 Sep 2020 07:04:03 -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; dkim=pass header.i=@bytedance-com.20150623.gappssmtp.com header.s=20150623 header.b=ICxs3B8O; 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=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729585AbgIGOAI (ORCPT + 99 others); Mon, 7 Sep 2020 10:00:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37672 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729664AbgIGNyI (ORCPT ); Mon, 7 Sep 2020 09:54:08 -0400 Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3FACEC061757 for ; Mon, 7 Sep 2020 06:54:08 -0700 (PDT) Received: by mail-pg1-x544.google.com with SMTP id e33so8094399pgm.0 for ; Mon, 07 Sep 2020 06:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o/MU6LekjsaqUPMHLvSGn4qT2Aidzx+zWyzeNtI6Aco=; b=ICxs3B8OAbtbOLbp+251XaXRr0iyGaw3eqK8J4FmveMJZkALbMNg1m+VVl1Sxtzzy0 ft3UvY9HZkITHw2LLwHYNCEHe32aHO6fNIviyEPwIaVy9+X9remMsv1JrpsVPyV1p93Q 6Epxt4o1Az96XmxrQQn1c5csKJqg1oTjsJMm1RdOBp3Ous0F7vKiZH9ZI9VRFpmzbwSB g04Gqcy7a0+2u2q1GoL41sWeCNfnOgNIX34V85uambamouh+S8ZrKpzJK7gMIHTQcIsC 3HAjf3Sbxgm1wsKes8aDu9UxYgaXqGC44lRUEiGudO+L+fwWnUISb2Ktk8zdEekb4jDH ImNw== 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=o/MU6LekjsaqUPMHLvSGn4qT2Aidzx+zWyzeNtI6Aco=; b=qdZ9ivCU20zSObDHrrHlYFEiO+PC3tJRcY0nn5sCAnuEt7PTKsBXv/cY4I0zPKyFpW a45kFucTV3uEspq81dXP4xuCQByzYl7tfQiTM5xp6BERDwIyZccmGefMGNXhWSXG3nU9 FjPUmsVPqFkBx3r9Jt8BWuac/eL/SvRiSvqaekcuSdeOerEvvz6MU7U/1c1CMrmx9u93 rMPZgDOF8H5o++cgBfQIi4BIqqeJ3WYPr/Jf8fi8mWVJJiakItNgBBLGjRjO1k4d2cWy IZlfRIDX3S+Sh8dHE4llFptKB9Wjilxob2Srk8SO+9X1THULE9v/Zc5U2CuPUABPrbvX fNAw== X-Gm-Message-State: AOAM533lZ9ruMZy9ez5taDcST5l7cEPSrqahp0f+U+0IGMM8SzQhIr5L 2EmUd7fp3C+9l3xeHqcRtKQJE84/Gm6HMUf8796Q+w== X-Received: by 2002:a63:5515:: with SMTP id j21mr16351063pgb.31.1599486847735; Mon, 07 Sep 2020 06:54:07 -0700 (PDT) MIME-Version: 1.0 References: <20200828031928.43584-1-songmuchun@bytedance.com> <8c288fd4-2ef7-ca47-1f3b-e4167944b235@linux.com> In-Reply-To: <8c288fd4-2ef7-ca47-1f3b-e4167944b235@linux.com> From: Muchun Song Date: Mon, 7 Sep 2020 21:53:31 +0800 Message-ID: Subject: Re: [External] Re: [PATCH v2] stackleak: Fix a race between stack erasing sysctl handlers To: alex.popov@linux.com Cc: Kees Cook , Masami Hiramatsu , Steven Rostedt , miguel.ojeda.sandonis@gmail.com, LKML 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 Mon, Sep 7, 2020 at 7:24 PM Alexander Popov wrote: > > On 07.09.2020 05:54, Muchun Song wrote: > > Hi all, > > > > Any comments or suggestions? Thanks. > > > > On Fri, Aug 28, 2020 at 11:19 AM Muchun Song wrote: > >> > >> There is a race between the assignment of `table->data` and write value > >> to the pointer of `table->data` in the __do_proc_doulongvec_minmax() on > >> the other thread. > >> > >> CPU0: CPU1: > >> proc_sys_write > >> stack_erasing_sysctl proc_sys_call_handler > >> table->data = &state; stack_erasing_sysctl > >> table->data = &state; > >> proc_doulongvec_minmax > >> do_proc_doulongvec_minmax sysctl_head_finish > >> __do_proc_doulongvec_minmax unuse_table > >> i = table->data; > >> *i = val; // corrupt CPU1's stack > > Hello everyone! > > As I remember, I implemented stack_erasing_sysctl() very similar to other sysctl > handlers. Is that issue relevant for other handlers as well? Yeah, it's very similar. But the difference is that others use a global variable as the `table->data`, but here we use a local variable as the `table->data`. The local variable is allocated from the stack. So other thread could corrupt the stack like the diagram above. > > Muchun, could you elaborate how CPU1's stack is corrupted and how you detected > that? Thanks! Why did I find this problem? Because I solve another problem which is very similar to this issue. You can reference the following fix patch. Thanks. https://lkml.org/lkml/2020/8/22/105 > > Best regards, > Alexander > > >> Fix this by duplicating the `table`, and only update the duplicate of > >> it. > >> > >> Fixes: 964c9dff0091 ("stackleak: Allow runtime disabling of kernel stack erasing") > >> Signed-off-by: Muchun Song > >> --- > >> changelogs in v2: > >> 1. Add more details about how the race happened to the commit message. > >> > >> kernel/stackleak.c | 11 ++++++++--- > >> 1 file changed, 8 insertions(+), 3 deletions(-) > >> > >> diff --git a/kernel/stackleak.c b/kernel/stackleak.c > >> index a8fc9ae1d03d..fd95b87478ff 100644 > >> --- a/kernel/stackleak.c > >> +++ b/kernel/stackleak.c > >> @@ -25,10 +25,15 @@ int stack_erasing_sysctl(struct ctl_table *table, int write, > >> int ret = 0; > >> int state = !static_branch_unlikely(&stack_erasing_bypass); > >> int prev_state = state; > >> + struct ctl_table dup_table = *table; > >> > >> - table->data = &state; > >> - table->maxlen = sizeof(int); > >> - ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos); > >> + /* > >> + * In order to avoid races with __do_proc_doulongvec_minmax(), we > >> + * can duplicate the @table and alter the duplicate of it. > >> + */ > >> + dup_table.data = &state; > >> + dup_table.maxlen = sizeof(int); > >> + ret = proc_dointvec_minmax(&dup_table, write, buffer, lenp, ppos); > >> state = !!state; > >> if (ret || !write || state == prev_state) > >> return ret; > >> -- > >> 2.11.0 > >> > > > > > -- Yours, Muchun