Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp1066062pxm; Wed, 23 Feb 2022 17:13:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJyTvUXIHgPkTFrHI0x8mqJ93HPAs0Vv9ZX2XWgFp8CI0gtCbv10sXUeIMAcEt7pmKMO5uS1 X-Received: by 2002:a05:6a00:1ac6:b0:4bd:140:626c with SMTP id f6-20020a056a001ac600b004bd0140626cmr491085pfv.7.1645665207875; Wed, 23 Feb 2022 17:13:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645665207; cv=none; d=google.com; s=arc-20160816; b=jnotHM4Bce/6DcDP0ik5so916+aho0kRlwc1GYuMFmdHH9WyG8goBHuvqKllOnAqGH FRgHXXPZbVFBqrlqKVqSLhAbPdTjJwZe1A1d+KKOb1HQYzb3vkwOoNHKYOKey9C2cthX i/tAY4sz9SR8XSdzekM/yBtDS+HCKIC2zEBHI80wHf5bjD8/LU3bttjJd7xeEZcwnQB9 RzQgV2BDBdNzDfxDa9ZPsKuXw/zWqi6wU8dlyqHJzvUlOD55tobUpGjgYpQmk2+KUaHB SVGgxYAxwK21ijHdqe+B46XKWdtvzXwKpn+sUE5iG9sj4coKpkGP4eqA7Wj7I7oEpGnN mEfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=djoY2wGo8Bskf3+H2QGMHgodNIrrUDznDojPM3Z5KCM=; b=s4KlUng1GIxfGNUF+sM/mSDQ7nV1HS+OTIhLJgPWhj4puRNtWibZTBgLTKLP8qifCh M79XtzjLxFVKly4yaUAAUlh8lfAxGO+GSBqcrs+8/punbEm7bKXlliizQSrSSo0RH0ek mmkJbLHcUbItMXm7+4VxbK/yBfcLPvYfiip5C4JMoc1el+fLwF/jeqahdjyErs9c1fwY 72WFnrUYmPN62rBvl5W57oHzcCQG8pEeM0Rougrn+dzlU5XQmxcERyrHSO8ApBcVIfym NHIcJEVJXgsbe1UEo2VNXrXavO5xnMF9GCh9jQFhxiKdeXpDx7Ug+uZs82LfODQKOtXU CPqQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=TEiq5QkD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id w1si1157167plq.193.2022.02.23.17.13.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Feb 2022 17:13:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=TEiq5QkD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 596E5163D49; Wed, 23 Feb 2022 17:00:09 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245117AbiBXAAl (ORCPT + 99 others); Wed, 23 Feb 2022 19:00:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53028 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233871AbiBXAAk (ORCPT ); Wed, 23 Feb 2022 19:00:40 -0500 Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7DFD45E147; Wed, 23 Feb 2022 16:00:11 -0800 (PST) Received: by mail-yb1-xb2d.google.com with SMTP id u12so537605ybd.7; Wed, 23 Feb 2022 16:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=djoY2wGo8Bskf3+H2QGMHgodNIrrUDznDojPM3Z5KCM=; b=TEiq5QkD0Pl37RTkVTqlCRlV6YKVYsYu/wCcfutLS/EB/bm3giMtsgoQNr6gve8ZKH V8lTH8chQAbx2axZpZYQNfuHNHRtw1Sl4svvF0R4GQUf7rJolYr5p5e7aUggdiL4RNSK hkBwe0uKkG4qhoig+dOWUPaQ2XshdD1yuo7F6v7M/hKYVL0koIOtPWDCBcZgDp5c+2Ae 8POjP+u57Mdq+3f4UIRugZ+CBrSRe0bLZYRGyznvmVzhVIb/kXf3/oFzzhv0Z8AwSwFb NTYXSI4AiMA+ZgviOXY+n4BqR0PIi90KOkIHl+fhzksVjX2jiWccIjI6ijQMa6ZoPSrP XipQ== 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=djoY2wGo8Bskf3+H2QGMHgodNIrrUDznDojPM3Z5KCM=; b=nSaUJ5oUPCrP2V7NPkLcuAyCvE64qZoQqZjwZtqtVfVTNcJLm1G3u4+e2e84jtKTjD jbLsuHcqI2LxKd1pPa1GEfF79MwwT27WKVieYNeXmaQtlHLPkotXn6bs2BVASx49NYx6 qSfnrWPOzRNoLJQYmjzTwpa/NALoqOom5fzbARnA+CtOkQ6zcKq2uZdhsi6MuVkEjJC9 BkvLMoGw0f9Xch5e7c/197he3Z4fKFftuMs74tRugSRn4ejeTaj6qst46SDmB1W9D9Fd zMSmuy5iMf64AptokkwlHisriMKc3R4AYT/8ZxgzBl98erkpUw6HwE8fIjV0+2L99yia YVsw== X-Gm-Message-State: AOAM530vIA5/p7nF1jAHdw65xmkSFuU4BrwKNk3Sh/0JGxDkfTaezRnk 5VoEXEGECVb01c8ZzJLHVZdM8PFz8wlozNQAAqk= X-Received: by 2002:a5b:489:0:b0:623:a73e:3818 with SMTP id n9-20020a5b0489000000b00623a73e3818mr171822ybp.358.1645660810561; Wed, 23 Feb 2022 16:00:10 -0800 (PST) MIME-Version: 1.0 References: <20220223231752.52241-1-ppbuk5246@gmail.com> In-Reply-To: From: Yun Levi Date: Thu, 24 Feb 2022 08:59:59 +0900 Message-ID: Subject: Re: [PATCH] fs/exec.c: Avoid a race in formats To: Al Viro Cc: Kees Cook , ebiederm@xmission.com, linux-fsdevel@vger.kernel.org, Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 On Thu, Feb 24, 2022 at 8:24 AM Al Viro wrote: > > On Thu, Feb 24, 2022 at 08:17:52AM +0900, Levi Yun wrote: > > Suppose a module registers its own binfmt (custom) and formats is like: > > > > +---------+ +----------+ +---------+ > > | custom | -> | format1 | -> | format2 | > > +---------+ +----------+ +---------+ > > > > and try to call unregister_binfmt with custom NOT in __exit stage. > > Explain, please. Why would anyone do that? And how would such > module decide when it's safe to e.g. dismantle data structures > used by methods of that binfmt, etc.? > Could you give more detailed example? I think if someone wants to control their own binfmt via "ioctl" not on time on LOAD. For example, someone wants to control exec (notification, allow/disallow and etc..) and want to enable and disable own's control exec via binfmt reg / unreg In that situation, While the module is loaded, binfmt is still live and can be reused by reg/unreg to enable/disable his exec' control. module can decide it's safe to unload by tracing the stack and confirming whether some tasks in the custom binfmt's function after it unregisters its own binfmt. > Because it looks like papering over an inherently unsafe use of binfmt interfaces.. I think the above example it's quite a trick and stupid. it's quite unsafe to use as you mention. But, misuse allows that situation to happen without any warning. As a robustness, I just try to avoid above situation But, I think it's better to restrict unregister binfmt unregister only when there is no module usage.