Message ID | 20221102025123.1117184-1-liushixin2@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp3336747wru; Tue, 1 Nov 2022 19:04:33 -0700 (PDT) X-Google-Smtp-Source: AMsMyM624AXEkreswYdSNwNOsrGrggi5P30q4jkl4PkSZfrmMbWY/YPqs0X2XdlC+Sl6dZfqHXMq X-Received: by 2002:a17:902:dac4:b0:186:c372:732a with SMTP id q4-20020a170902dac400b00186c372732amr22699803plx.174.1667354673582; Tue, 01 Nov 2022 19:04:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667354673; cv=none; d=google.com; s=arc-20160816; b=OjiwGuAF3UkXoWSO4v2dxEpozdjaqg2NS0Zc8XeRNFRqGlMEykllrhVab9MTg2BXWP y0xBcq7xRFZWcusd3Lky3dZ3SX7g+/2sWEMWfEDWbdK+pwb+UchMn+WczpOwf/J1igNs DUBruyd8h0RY+E+NV0PPyvavIBK2mftViGTkhy1VcBGyYLEmHr09V3pmHHIZOeycJnFU 3uTmH5C2bA0sy4VZgGpzSDx2jTo5gK3xtaLD9Bhx4/CvueWVIrKNrz0Rs94CS8D/DUwp dAF/fnicb+GMVC5GmbfKuI40S6kc2cRZxHiY6q6Y5yj0kDtjoIJ6V0YvksuQEUs/NwY9 P7aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=owvYrwP9h6E7Kiu91RKBWwKVfzzjoMSKPvncW6vKtg8=; b=jfIrvUgOYq8WNYZ9frzUUgImYXNaMDpTLGPngWVbENd15Mel6N89QBDUIw9JbYCa6y ULfPRmtyLdBsnnpNFwrBu2DiVUcPHaXPGMarMeMDlsw5Mw94V1L/drjIUB/svcoMbjmw 95r46/0bjktFiL+98Td7t//zQOyNVvyo8SsbZKFAew5xJGbxc5OxCe9mbc3hzrs9mX9Y 8cH+/z2yORrq6KV7HM2sCaS+6g2q/NTcdDAZ8jidyr+6qUfhNnDVEdzF6hBNIFdveZjq zdbfZe+OZOOrk6HlYHdV8RqN6RJWozLLNw2kecN1marz8RZKpHuF+Nw5sRwjIFNmmd/y pZYQ== 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:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bx8-20020a056a00428800b0056de69b0c78si2153251pfb.286.2022.11.01.19.04.21; Tue, 01 Nov 2022 19:04:33 -0700 (PDT) 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; 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=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230019AbiKBCDO (ORCPT <rfc822;rua109.linux@gmail.com> + 99 others); Tue, 1 Nov 2022 22:03:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33874 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229817AbiKBCDM (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 1 Nov 2022 22:03:12 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 95BF712ACA; Tue, 1 Nov 2022 19:03:11 -0700 (PDT) Received: from dggpemm500022.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4N295c4l47zRntx; Wed, 2 Nov 2022 09:58:12 +0800 (CST) Received: from dggpemm100009.china.huawei.com (7.185.36.113) by dggpemm500022.china.huawei.com (7.185.36.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Wed, 2 Nov 2022 10:03:09 +0800 Received: from huawei.com (10.175.113.32) by dggpemm100009.china.huawei.com (7.185.36.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Wed, 2 Nov 2022 10:03:09 +0800 From: Liu Shixin <liushixin2@huawei.com> To: Alexander Viro <viro@zeniv.linux.org.uk>, Eric Biederman <ebiederm@xmission.com>, Kees Cook <keescook@chromium.org> CC: <linux-fsdevel@vger.kernel.org>, <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>, Liu Shixin <liushixin2@huawei.com> Subject: [PATCH] binfmt_misc: fix shift-out-of-bounds in check_special_flags Date: Wed, 2 Nov 2022 10:51:23 +0800 Message-ID: <20221102025123.1117184-1-liushixin2@huawei.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.113.32] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemm100009.china.huawei.com (7.185.36.113) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1748348093758956816?= X-GMAIL-MSGID: =?utf-8?q?1748348093758956816?= |
Series |
binfmt_misc: fix shift-out-of-bounds in check_special_flags
|
|
Commit Message
Liu Shixin
Nov. 2, 2022, 2:51 a.m. UTC
UBSAN reported a shift-out-of-bounds warning:
left shift of 1 by 31 places cannot be represented in type 'int'
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106
ubsan_epilogue+0xa/0x44 lib/ubsan.c:151
__ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322
check_special_flags fs/binfmt_misc.c:241 [inline]
create_entry fs/binfmt_misc.c:456 [inline]
bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654
vfs_write+0x11e/0x580 fs/read_write.c:582
ksys_write+0xcf/0x120 fs/read_write.c:637
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x4194e1
Since the type of Node's flags is unsigned long, we should define these
macros with same type too.
Signed-off-by: Liu Shixin <liushixin2@huawei.com>
---
fs/binfmt_misc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Comments
On Wed, Nov 02, 2022 at 10:51:23AM +0800, Liu Shixin wrote: > UBSAN reported a shift-out-of-bounds warning: > > left shift of 1 by 31 places cannot be represented in type 'int' > Call Trace: > <TASK> > __dump_stack lib/dump_stack.c:88 [inline] > dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106 > ubsan_epilogue+0xa/0x44 lib/ubsan.c:151 > __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322 > check_special_flags fs/binfmt_misc.c:241 [inline] > create_entry fs/binfmt_misc.c:456 [inline] > bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654 > vfs_write+0x11e/0x580 fs/read_write.c:582 > ksys_write+0xcf/0x120 fs/read_write.c:637 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > RIP: 0033:0x4194e1 > > Since the type of Node's flags is unsigned long, we should define these > macros with same type too. We are limited to 32 bits anyway. More interesting question here is what's the point of having those bits that high anyway?
On Sat, Nov 19, 2022 at 05:29:22AM +0000, Al Viro wrote: > On Wed, Nov 02, 2022 at 10:51:23AM +0800, Liu Shixin wrote: > > UBSAN reported a shift-out-of-bounds warning: > > > > left shift of 1 by 31 places cannot be represented in type 'int' > > Call Trace: > > <TASK> > > __dump_stack lib/dump_stack.c:88 [inline] > > dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106 > > ubsan_epilogue+0xa/0x44 lib/ubsan.c:151 > > __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322 > > check_special_flags fs/binfmt_misc.c:241 [inline] > > create_entry fs/binfmt_misc.c:456 [inline] > > bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654 > > vfs_write+0x11e/0x580 fs/read_write.c:582 > > ksys_write+0xcf/0x120 fs/read_write.c:637 > > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > > do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80 > > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > RIP: 0033:0x4194e1 > > > > Since the type of Node's flags is unsigned long, we should define these > > macros with same type too. > > We are limited to 32 bits anyway. More interesting question here is what's > the point of having those bits that high anyway? Hm, looks like it was designed to avoid the enum just before the defines: enum {Enabled, Magic}; #define MISC_FMT_PRESERVE_ARGV0 (1 << 31) #define MISC_FMT_OPEN_BINARY (1 << 30) #define MISC_FMT_CREDENTIALS (1 << 29) #define MISC_FMT_OPEN_FILE (1 << 28) But both appear to be entirely internally defined bits. I think these can all just be part of the enum, and we can quit mixing "&" tests and test_bit() calls: ... if (e->flags & MISC_FMT_OPEN_FILE) *dp++ = 'F'; *dp++ = '\n'; if (!test_bit(Magic, &e->flags)) { sprintf(dp, "extension .%s\n", e->magic); ...
On Wed, 2 Nov 2022 10:51:23 +0800, Liu Shixin wrote: > UBSAN reported a shift-out-of-bounds warning: > > left shift of 1 by 31 places cannot be represented in type 'int' > Call Trace: > <TASK> > __dump_stack lib/dump_stack.c:88 [inline] > dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106 > ubsan_epilogue+0xa/0x44 lib/ubsan.c:151 > __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322 > check_special_flags fs/binfmt_misc.c:241 [inline] > create_entry fs/binfmt_misc.c:456 [inline] > bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654 > vfs_write+0x11e/0x580 fs/read_write.c:582 > ksys_write+0xcf/0x120 fs/read_write.c:637 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > RIP: 0033:0x4194e1 > > [...] Applied to for-next/execve, thanks! [1/1] binfmt_misc: fix shift-out-of-bounds in check_special_flags https://git.kernel.org/kees/c/6a46bf558803
diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c index e1eae7ea823a..bb202ad369d5 100644 --- a/fs/binfmt_misc.c +++ b/fs/binfmt_misc.c @@ -44,10 +44,10 @@ static LIST_HEAD(entries); static int enabled = 1; enum {Enabled, Magic}; -#define MISC_FMT_PRESERVE_ARGV0 (1 << 31) -#define MISC_FMT_OPEN_BINARY (1 << 30) -#define MISC_FMT_CREDENTIALS (1 << 29) -#define MISC_FMT_OPEN_FILE (1 << 28) +#define MISC_FMT_PRESERVE_ARGV0 (1UL << 31) +#define MISC_FMT_OPEN_BINARY (1UL << 30) +#define MISC_FMT_CREDENTIALS (1UL << 29) +#define MISC_FMT_OPEN_FILE (1UL << 28) typedef struct { struct list_head list;