Received: by 2002:ac2:5a04:0:0:0:0:0 with SMTP id q4csp1075912lfn; Wed, 23 Feb 2022 18:25:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJwP/uvPDYtA+I7KQyx/8YfAuYLwg2CbOQ92ZLWAfJQD+iS7SOx/tio/tvEjiBXXPrRBqbRO X-Received: by 2002:a17:902:cccc:b0:14e:e89c:c669 with SMTP id z12-20020a170902cccc00b0014ee89cc669mr455749ple.58.1645669509636; Wed, 23 Feb 2022 18:25:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645669509; cv=none; d=google.com; s=arc-20160816; b=GDOOP7hJrBuLsDs2sT1YsN5gvJ84HpBQIfSb107s8bBFy7tJI7o8ze4vg7t9egGDxp 0IkZl1uYVpM28RwAT/gf5EjA/j1gZM5Pmo7C6epwhSBD13dYf30fw95KbUBJat3imy35 KAtUOQnKXHItHZsCldgw0+KRiGpaDDz2GpitdSkMgxJkFATfxGtnPey++TWD5Z3XrdWo WiTb9TRsd66zBtktxg7lCH8/Ny4JYlxn1od+797RPi1gpH/Gt5L86/JK/pUGk89lkLSm 62J1JzW9LT3hlbFXODJ39SQDheG6HayM7VDfXvjEJFxAnVq3mhl8LGPEGV/aCY3dUITk cYVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:mime-version:user-agent:message-id :in-reply-to:date:references:cc:to:from; bh=+DOtjgduzciWHo61jgvcuLaij8erVmSQaxFhqtjLPsM=; b=iS6c6Y/iooTk7DDJci4zJ7MnimDMUcDzL/8pePMPd62QRFXat/Azgz0PsFva5upLs8 oJSV5rIXPIACJTh27qmH2ApRFeWlGJgdIlD0kQtBUKM/TYdMaQkfwxyHfuiGlnv0UUCy dGiQo7gdITrZUjRpjuZ2W8p5VISStuK5lKcjRwoUxr5t31FaGE4rWd130jw935vq+mmz WdNc+nc48MK035beWPHktRcj2cprsBtFC6zoyMi9HcPuDPcDpyggSfo+X+O/Pkjc5DWg XkTFKm0+UJ2PE+I6PV8qmdPmnU4Fl9DX2bYnLB+NexMpk83kbfPkivAw3gnXmG1OEedU Fh3Q== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id e1si372892pja.124.2022.02.23.18.25.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Feb 2022 18:25:09 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 1836522C6CE; Wed, 23 Feb 2022 18:25:08 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230146AbiBXCZc (ORCPT + 99 others); Wed, 23 Feb 2022 21:25:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40216 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230100AbiBXCZa (ORCPT ); Wed, 23 Feb 2022 21:25:30 -0500 Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 61E3B22C6CE; Wed, 23 Feb 2022 18:25:02 -0800 (PST) Received: from in02.mta.xmission.com ([166.70.13.52]:38890) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1nN3oT-00ASE8-D0; Wed, 23 Feb 2022 19:25:01 -0700 Received: from ip68-227-174-4.om.om.cox.net ([68.227.174.4]:55894 helo=email.froward.int.ebiederm.org.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1nN3oS-004Cj9-JM; Wed, 23 Feb 2022 19:25:01 -0700 From: "Eric W. Biederman" To: Yun Levi Cc: Al Viro , Kees Cook , linux-fsdevel@vger.kernel.org, Linux Kernel Mailing List References: <20220223231752.52241-1-ppbuk5246@gmail.com> <878ru1umcu.fsf@email.froward.int.ebiederm.org> Date: Wed, 23 Feb 2022 20:24:54 -0600 In-Reply-To: (Yun Levi's message of "Thu, 24 Feb 2022 09:51:21 +0900") Message-ID: <87h78pknm1.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1nN3oS-004Cj9-JM;;;mid=<87h78pknm1.fsf@email.froward.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.174.4;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19Lg3tki/J1nTErPJ3vlLOPCxPazKPvyjQ= X-SA-Exim-Connect-IP: 68.227.174.4 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, 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-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Yun Levi X-Spam-Relay-Country: X-Spam-Timing: total 246 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 11 (4.4%), b_tie_ro: 9 (3.8%), parse: 0.75 (0.3%), extract_message_metadata: 2.6 (1.1%), get_uri_detail_list: 0.89 (0.4%), tests_pri_-1000: 3.4 (1.4%), tests_pri_-950: 1.15 (0.5%), tests_pri_-900: 0.97 (0.4%), tests_pri_-90: 53 (21.6%), check_bayes: 52 (21.1%), b_tokenize: 4.7 (1.9%), b_tok_get_all: 6 (2.5%), b_comp_prob: 1.81 (0.7%), b_tok_touch_all: 36 (14.7%), b_finish: 0.77 (0.3%), tests_pri_0: 156 (63.4%), check_dkim_signature: 0.47 (0.2%), check_dkim_adsp: 2.7 (1.1%), poll_dns_idle: 1.00 (0.4%), tests_pri_10: 2.0 (0.8%), tests_pri_500: 8 (3.2%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] fs/exec.c: Avoid a race in formats X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Yun Levi writes: >> Mostly of what has been happening with binary formats lately is code >> removal. >> >> So I humbly suggest the best defense against misuse by modules is to >> simply remove "EXPORT_SYMBOL(__register_binfmt)". > > It could be a solution. but that means the kernel doesn't allow > dynamic binfmt using modules too. > I think the best safe way to remove registered binfmt is ... > > unregister binfmt list first ---- (1) > synchronize_rcu_task(); > // tasklist stack-check... > unload module. > > But for this, there shouldn't happen in the above situation of (1). > If unregister_binfmt has this problem.. I think there is no way to > unload safely for dynamic registered binfmt via module. I took a quick look and unregistering in the module exit routine looks safe, as set_binfmt takes a module reference, and so prevents the module from being unloaded. If you can find a bug with existing in-kernel code that would be interesting. Otherwise you are making up assumptions that don't current match the code and saying the code is bugging with respect to assumptions that do not hold. The code in the kernel is practical not an implementation of some abstract that is robust for every possible use case. Eric