Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp5856724rwb; Mon, 5 Dec 2022 05:10:02 -0800 (PST) X-Google-Smtp-Source: AA0mqf6ZzHXrNKezQi5UBoaCBp5QN5oex/QZbGB3rmTQ0k8u0A7Lic0yOyrvR4mlUrABkBtRO7zz X-Received: by 2002:a17:903:cc:b0:189:7100:bbd1 with SMTP id x12-20020a17090300cc00b001897100bbd1mr47084848plc.115.1670245802135; Mon, 05 Dec 2022 05:10:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670245802; cv=none; d=google.com; s=arc-20160816; b=eZvImgQqIU93UealICyc0rCYPK+ZFYkqLD1c5GMeorhepN5mtDmRuOgSj1yCpqwJcg WPMpqdJZ94NH5g+L/Z0YVdPLcTgV+kPczEpiBAzpPEqujF2pKcpWXown1ubmtx5wjS8s CAQxMdty/8qte4kMkBY4d1im4AF9rj0fFW7a6mb/RZQgI/uExn5IP/rz2uoIT2x7H3Hq MIWkuy7CTtxnldIEL436FCYWA170vFK9yaA42TxbdVWmLrEv/ikdtJk9T8zeAaI8SJdC sMxIhEWGexe3De6cgnkH+0hVtkJeU2E2Hv9evgGPGMDp9yPiEkKuImBpqRdDeglFzZLd d3PA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:in-reply-to:date:subject :cc:to:from:user-agent:references:dkim-signature; bh=y5IIAaK5GHpJZ5+16Lx4zcAJ1Wy5UCihf6KWPQXtanQ=; b=dTf5TnauljAG0Bv9fbVM0W9h2yPwQ7z/UVOawChUOr08eZXStqEheGsqcuusuYbJLy HBWwWCW106DcNNyq7osIIWqQYC3rqBzY6dKNqnJJh5ZXTIXYoeg0mdScKfoo9DR56SSF 5bqas6TvzzFlUba95YDv7ahFc/BgpK8o/LUfDzrZDGm3j49+wAbQ3OihUdFCRSKfNQg2 anY3uHEY/wfdCIZCl5n0lWEYfXv9dpD9/1V65To57qu1BwrQ1hHSWcO2k5kJgTa9N3Ih w2BRj+ak/TmeGKwmWMQLUv/QTuB4q9CCIAWAO4fT9y4emYw3MC2iPGOhxXI0/Tm9aYil 976A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=JtdZf54x; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n3-20020a6546c3000000b004788ef3025asi7662738pgr.438.2022.12.05.05.09.50; Mon, 05 Dec 2022 05:10:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=JtdZf54x; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231654AbiLELoo (ORCPT + 82 others); Mon, 5 Dec 2022 06:44:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57254 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231436AbiLELoB (ORCPT ); Mon, 5 Dec 2022 06:44:01 -0500 Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B440FB7CB for ; Mon, 5 Dec 2022 03:44:00 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id s7so10533691plk.5 for ; Mon, 05 Dec 2022 03:44:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:from:to:cc:subject:date:message-id:reply-to; bh=y5IIAaK5GHpJZ5+16Lx4zcAJ1Wy5UCihf6KWPQXtanQ=; b=JtdZf54xBzD3314emrXQNCLSqGuo0iRVwzKHGdQqkvkj6x8/QczJrMkyZSzPSt5yEV 1aQsG5IyzGUnat5KpBwmolzw3iMT7SKrUMJo8H5jKpXVuYbGrW0/i5o/BZo6AX29J5Mu E4IEaeCFVqLG9+uJgfuiez/gIBvbU2iBtszMvuuJdx9OPY7DXb1M71/ioq5jyYh0lqv3 7xLxqq3hq2uBl2QzLh+Awk4YkD2XAfipBmp85iLyw79r+SHahRgYD6Ih+PTIYq2cJPil e5zYOOcsO/5/wpMcc4jpwWP6hvUX/k6oLKOMMsnG0XNY+XoEuszBo/+AHIZxpwx2qtQ9 /9sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=y5IIAaK5GHpJZ5+16Lx4zcAJ1Wy5UCihf6KWPQXtanQ=; b=4v4r+WE9DCLbJUVbHK3Dhqlk6pUUpvCkhhv82TV8RGeuivNriciwQBpbNAazNTnmBi wLhREDcnNlUK4+L8sKQzmmgjZrCNsSQmVjXnv4VXH7btm8eKyvPfNR8iOWK9zYHmT0AA ip1KEqQwMubIbBqM3Hl1ub9BnIFPgYPrRakAZogQtfHlHzC8WupDd7Zp7uMs2Vr1d7Ul J6boy/M89DPcwgxjlEU2liGHnpvhVwTT1V28c/EgOsVoRCMIXK4Bs4k6lHUi5PHd/23x RtbedIYwtsofXHcW+VTgOzekymsUTrvboWoh9HZFpWFt0C+wDBt5sGcd2GiQibgWZgjq 3FKA== X-Gm-Message-State: ANoB5pmNsOzgLkAUCEuyuakJB9/mkR2Ygs23sNNSmfxLfhp7dcV26J+Z O832nkY6AtjjQMj4A9U12vs= X-Received: by 2002:a17:90b:2d82:b0:219:c8d5:27d7 with SMTP id sj2-20020a17090b2d8200b00219c8d527d7mr6343913pjb.141.1670240640152; Mon, 05 Dec 2022 03:44:00 -0800 (PST) Received: from MBP ([39.170.101.209]) by smtp.gmail.com with ESMTPSA id a24-20020aa795b8000000b00575d06e53edsm8521233pfk.149.2022.12.05.03.43.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Dec 2022 03:43:57 -0800 (PST) References: <20221115140233.21981-1-schspa@gmail.com> User-agent: mu4e 1.8.10; emacs 28.2 From: Schspa Shi To: mcgrof@kernel.org Cc: linux-kernel@vger.kernel.org, Schspa Shi , syzbot+10d19d528d9755d9af22@syzkaller.appspotmail.com, syzbot+70d5d5d83d03db2c813d@syzkaller.appspotmail.com, syzbot+83cb0411d0fcf0a30fc1@syzkaller.appspotmail.com Subject: Re: [PATCH] umh: fix UAF when the process is being killed Date: Mon, 05 Dec 2022 19:38:21 +0800 In-reply-to: <20221115140233.21981-1-schspa@gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Schspa Shi writes: > When the process is killed, wait_for_completion_state will return with > -ERESTARTSYS, and the completion variable in the stack will be freed. > If the user-mode thread is complete at the same time, there will be a UAF. > > Please refer to the following scenarios. > T1 T2 > ------------------------------------------------------------------ > call_usermodehelper_exec > call_usermodehelper_exec_async > << do something >> > umh_complete(sub_info); > comp = xchg(&sub_info->complete, NULL); > /* we got the completion */ > << context switch >> > > << Being killed >> > retval = wait_for_completion_state(sub_info->complete, state); > if (!retval) > goto wait_done; > > if (wait & UMH_KILLABLE) { > /* umh_complete() will see NULL and free sub_info */ > if (xchg(&sub_info->complete, NULL)) > goto unlock; > << we can't got the completion >> > } > .... > unlock: > helper_unlock(); > return retval; > } > > /** > * the completion variable in stack is end of life cycle. > * and maybe freed due to process is recycled. > */ > --------UAF here---------- > if (comp) > complete(comp); > > To fix it, we can put the completion variable in the subprocess_info > variable. > > Reported-by: syzbot+10d19d528d9755d9af22@syzkaller.appspotmail.com > Reported-by: syzbot+70d5d5d83d03db2c813d@syzkaller.appspotmail.com > Reported-by: syzbot+83cb0411d0fcf0a30fc1@syzkaller.appspotmail.com > > Signed-off-by: Schspa Shi > --- > include/linux/umh.h | 1 + > kernel/umh.c | 6 +++--- > 2 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/include/linux/umh.h b/include/linux/umh.h > index 5d1f6129b847..801f7efbc825 100644 > --- a/include/linux/umh.h > +++ b/include/linux/umh.h > @@ -20,6 +20,7 @@ struct file; > struct subprocess_info { > struct work_struct work; > struct completion *complete; > + struct completion done; > const char *path; > char **argv; > char **envp; > diff --git a/kernel/umh.c b/kernel/umh.c > index 850631518665..3ed39956c777 100644 > --- a/kernel/umh.c > +++ b/kernel/umh.c > @@ -380,6 +380,7 @@ struct subprocess_info *call_usermodehelper_setup(const char *path, char **argv, > sub_info->cleanup = cleanup; > sub_info->init = init; > sub_info->data = data; > + init_completion(&sub_info->done); > out: > return sub_info; > } > @@ -405,7 +406,6 @@ EXPORT_SYMBOL(call_usermodehelper_setup); > int call_usermodehelper_exec(struct subprocess_info *sub_info, int wait) > { > unsigned int state = TASK_UNINTERRUPTIBLE; > - DECLARE_COMPLETION_ONSTACK(done); > int retval = 0; > > if (!sub_info->path) { > @@ -431,7 +431,7 @@ int call_usermodehelper_exec(struct subprocess_info *sub_info, int wait) > * This makes it possible to use umh_complete to free > * the data structure in case of UMH_NO_WAIT. > */ > - sub_info->complete = (wait == UMH_NO_WAIT) ? NULL : &done; > + sub_info->complete = (wait == UMH_NO_WAIT) ? NULL : &sub_info->done; > sub_info->wait = wait; > > queue_work(system_unbound_wq, &sub_info->work); > @@ -444,7 +444,7 @@ int call_usermodehelper_exec(struct subprocess_info *sub_info, int wait) > if (wait & UMH_FREEZABLE) > state |= TASK_FREEZABLE; > > - retval = wait_for_completion_state(&done, state); > + retval = wait_for_completion_state(sub_info->complete, state); > if (!retval) > goto wait_done; Hi Luis Chamberlain: Could you help to review this patch? I'm not sure why we define the amount of completion here on the stack. But this UAF can be fixed by moving the completion variable to the heap. -- BRs Schspa Shi