Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8D3EC433F5 for ; Wed, 12 Jan 2022 17:49:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355787AbiALRtT (ORCPT ); Wed, 12 Jan 2022 12:49:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37476 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344086AbiALRtN (ORCPT ); Wed, 12 Jan 2022 12:49:13 -0500 Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE365C06173F for ; Wed, 12 Jan 2022 09:49:12 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id c190so2409383qkg.9 for ; Wed, 12 Jan 2022 09:49:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FGEfHWlf9UMI6v4enCzCD7r7seKvBt4wr+xOvzAydtg=; b=WbGG70yB5ix1xJm1WZIdyIccnKWNDVsMGBobYnUvRJtVGwRDFABrhR3HRodaO2H2gT o+mvzdaj9LW0ogQ/fZRLZ/G14ELweRvxby5HD2yygkGanrwyi0saa1PLA/b2HANEP9wP uVBQAarQx5wX6tUlOrtGMc8zeFxL6B2vOiWjnaC9BUVZle/bRqhOpgFK7qozPGiliRpF KQaDAmpG3GhdrpqiN7KljC2pW8M/Z/6NhEvocoQhtnW+0wIJ3qYItndrv8QOCrbR/Jxa UB+N+Y+r+k/dW13lG7nxHXxFVvAgkFh1FoS5a/O9Z9S/tPGYbuQ9WwEOG5hY/jGGrlg2 U5EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FGEfHWlf9UMI6v4enCzCD7r7seKvBt4wr+xOvzAydtg=; b=eapshznX/pS5/nG5UeFeCh0qKmI9i66NFj6redO+M676R3HOHy/7WDjsOhw4MCvUym 23qCYuvTs8/nLOj4oSqDVW0VbYmwT+qwELofcmcC9uDv9id45wmIA24j1gCLPfG2cN5h ESdJ3xptwa/vXWeu9U2N3OT9iZ0LWyu0pe4Tx89H0JR2y66E0X5P1NzybFmUtGP/hd3i huuF+X5+iOvJUfyWK80I/9zzKg8G3guTbfaWdhJdqCUW1utigWYymBjJ/SByysc3uYDR DollXBq1FqqggRX17ziMZgtiLjCYzBHI2tg1HzXEObdZhSr9zOJKmsuyN2X3QVMQIx6s yZmg== X-Gm-Message-State: AOAM532wXej0o69fYHPjJ/XlInqylN744VGJYcRdi3bLo5nXmi++gpA8 YhqQMvKNIwDzIn77a5hWUyv6sNYOk3WqZjphIju+kQ== X-Google-Smtp-Source: ABdhPJxfN2XJ4LOiyU4hogddx6yOZvk/BIWqCAvRPuDRWYY6wyEn2p4yI9Sa7X55t3Lg1CYmOJU4b8GfjXSbXBZJY5g= X-Received: by 2002:a25:7807:: with SMTP id t7mr1066672ybc.488.1642009751595; Wed, 12 Jan 2022 09:49:11 -0800 (PST) MIME-Version: 1.0 References: <20220111232309.1786347-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 12 Jan 2022 09:49:00 -0800 Message-ID: Subject: Re: [PATCH v3 1/1] psi: Fix uaf issue when psi trigger is destroyed while being polled To: Johannes Weiner Cc: Linus Torvalds , Eric Biggers , Tejun Heo , Zefan Li , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Benjamin Segall , Mel Gorman , Daniel Bristot de Oliveira , Jonathan Corbet , "open list:DOCUMENTATION" , LKML , cgroups mailinglist , stable , kernel-team , syzbot Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 12, 2022 at 9:43 AM Suren Baghdasaryan wrote: > > ) > > On Wed, Jan 12, 2022 at 6:40 AM Johannes Weiner wrote: > > > > On Tue, Jan 11, 2022 at 03:23:09PM -0800, Suren Baghdasaryan wrote: > > > With write operation on psi files replacing old trigger with a new one, > > > the lifetime of its waitqueue is totally arbitrary. Overwriting an > > > existing trigger causes its waitqueue to be freed and pending poll() > > > will stumble on trigger->event_wait which was destroyed. > > > Fix this by disallowing to redefine an existing psi trigger. If a write > > > operation is used on a file descriptor with an already existing psi > > > trigger, the operation will fail with EBUSY error. > > > Also bypass a check for psi_disabled in the psi_trigger_destroy as the > > > flag can be flipped after the trigger is created, leading to a memory > > > leak. > > > > > > Fixes: 0e94682b73bf ("psi: introduce psi monitor") > > > Cc: stable@vger.kernel.org > > > Reported-by: syzbot+cdb5dd11c97cc532efad@syzkaller.appspotmail.com > > > Analyzed-by: Eric Biggers > > > Suggested-by: Linus Torvalds > > > Signed-off-by: Suren Baghdasaryan > > > > Acked-by: Johannes Weiner > > Hmm. kernel test robot notified me of new (which are not really new) > warnings but I don't think this patch specifically introduced them: > > kernel/sched/psi.c:1112:21: warning: no previous prototype for > function 'psi_trigger_create' [-Wmissing-prototypes] > struct psi_trigger *psi_trigger_create(struct psi_group *group, > ^ > kernel/sched/psi.c:1112:1: note: declare 'static' if the function > is not intended to be used outside of this translation unit > struct psi_trigger *psi_trigger_create(struct psi_group *group, > ^ > static > >> kernel/sched/psi.c:1182:6: warning: no previous prototype for function 'psi_trigger_destroy' [-Wmissing-prototypes] > void psi_trigger_destroy(struct psi_trigger *t) > ^ > kernel/sched/psi.c:1182:1: note: declare 'static' if the function > is not intended to be used outside of this translation unit > void psi_trigger_destroy(struct psi_trigger *t) > ^ > static > kernel/sched/psi.c:1249:10: warning: no previous prototype for > function 'psi_trigger_poll' [-Wmissing-prototypes] > __poll_t psi_trigger_poll(void **trigger_ptr, > ^ > kernel/sched/psi.c:1249:1: note: declare 'static' if the function > is not intended to be used outside of this translation unit > __poll_t psi_trigger_poll(void **trigger_ptr, > ^ > > This happens with the following config: > > CONFIG_CGROUPS=n > CONFIG_PSI=y > > With cgroups disabled these functions are defined as non-static but > are not defined in the header > (https://elixir.bootlin.com/linux/latest/source/include/linux/psi.h#L28) > since the only external user cgroup.c is disabled. The cleanest way to > fix these I think is by doing smth like this in psi.c: > > struct psi_trigger *_psi_trigger_create(struct psi_group *group, char > *buf, size_t nbytes, enum psi_res res) > { > // original psi_trigger_create code > } > > #ifdef CONFIG_CGROUPS > > struct psi_trigger *psi_trigger_create(struct psi_group *group, char > *buf, size_t nbytes, enum psi_res res) > { > return _psi_trigger_create(group, buf, nbytes, res); > } > > #else > > static struct psi_trigger *psi_trigger_create(struct psi_group *group, > char *buf, size_t nbytes, enum psi_res res) > { > return _psi_trigger_create(group, buf, nbytes, res); > } > > #endif Actually this would be enough: static struct psi_trigger *_psi_trigger_create(struct psi_group *group, char *buf, size_t nbytes, enum psi_res res) { // original psi_trigger_create code } #ifdef CONFIG_CGROUPS struct psi_trigger *psi_trigger_create(struct psi_group *group, char *buf, size_t nbytes, enum psi_res res) { return _psi_trigger_create(group, buf, nbytes, res); } #endif and locally we use _psi_trigger_create(). > > Two questions: > 1. Is this even worth fixing? > 2. If so, I would like to do that as a separate patch (these warnings > are unrelated to the changes in this patch). Would that be ok? > Thanks, > Suren.