From mboxrd@z Thu Jan 1 00:00:00 1970 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 70DB7C54FB9 for ; Thu, 16 Nov 2023 13:41:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Subject:To:From:Date:References: In-Reply-To:Message-Id:MIME-Version:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=V30rgCpT5AgDCixm/SRlkWSCFHSLrIp/p0xFt3akjZE=; b=u/M12PNKo6GfxqkwBI4HRauqUQ W1ju7DgjPiJPCV5QdOWrKjM5cGmZBK3m36gzfsdzy/dkn78DlMNfEJ7uWJ3nSNzUeET55fpFQt+jG ie+3NNxV7y2bIM5XqxIu0jAN8m1tq/9TzDfeApIp9EfOZSNjPaXvzpGMsn0PvtKsHQdb2ae6uS9wd 1gaceqcDf4TgZ5mhR8aT40E3bKLOPkvjaY5nreysbgHBlBCXHpYAYzUjuybbVeX4fJg2YuffyQP4k bJ8kl5tOR2onow55ExsYzVgAJ+3jPkr86Siok/l/DFjcVzMkmTwImoEC8bpLKruA4n6/FPWkrzQP2 Lpb/rUzg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r3cbn-003c3f-0d; Thu, 16 Nov 2023 13:40:39 +0000 Received: from wnew4-smtp.messagingengine.com ([64.147.123.18]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r3cbk-003c1r-0Q for linux-arm-kernel@lists.infradead.org; Thu, 16 Nov 2023 13:40:37 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.west.internal (Postfix) with ESMTP id 028C62B003FD; Thu, 16 Nov 2023 08:40:28 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute5.internal (MEProxy); Thu, 16 Nov 2023 08:40:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1700142028; x=1700149228; bh=bG IxYXyIqpwVy5KNp0/Neu8NcBlWmtLuVpGKn7FLZtU=; b=UPKuBEMnG4dw7Ly/WD mMC2A/V2z1/vEaQcg5A64GxUF1mmHL+a326KLazJOj7HVnRFKjU9P9qoPhg+PqXa /QtjNzlIdIt9LRXw/6cJosk7JsvpqEaelnK9v/AVuS1cCA7yGBC7SjWImqJF2Ebu Zjp+inuBCaJLIIRnJ1uaKzedqpGJ/+KGk0jmFEBZhFu5ILXBRIdvKIOGJIP1IMOt CbFJ5b5PekDOT5X+VrrQMIoNLaHE1ZLVXZceMa14Fh4WTF4HYiV5M4aOdC3N7RCg HpDu32sBIPBcuznQDmQwJ3fcoIaB0vqZ9kbBIaiKb/P2164bbloXuGH6rX4dC+hf HsfQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1700142028; x=1700149228; bh=bGIxYXyIqpwVy 5KNp0/Neu8NcBlWmtLuVpGKn7FLZtU=; b=09i7T7hxgV7kgBtnme+L86MuuGfu1 1fKUgkGi4+3QjafcPnlBHck4uobsyg+AVoSPocA0QrvGHBVBOjews4qbYHqqnNSy 7CELOkVB7SD0TIhtDxbnY9JiXr7rBWgToTW0q25n3thy7TpetzKJc3kfx4jt401M 6pNom/JNUeQpD5gCy5VQxxSQLXQzpzaK8P53poe1BXW6xNnM3Ywwfm8kuZGoyWY7 EO2QnW1qMZOscFjU8cm63cCsvduPFHNu9kqAQZU/+psyEP8PfOULHkjwhVVaaiFe XiaLF9u5/HOt8d/g3WJWdhuDNlT/hXc5tDw7lz1r7QYz6OBohe/IyN4Cg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudefkedgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdetrhhn ugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrghtth gvrhhnpeffgeffuddtvdehffefleethfejjeegvdelffejieegueetledvtedtudelgfdu gfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrh hnugesrghrnhgusgdruggv X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4E836B60089; Thu, 16 Nov 2023 08:40:27 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1108-g3a29173c6d-fm-20231031.005-g3a29173c MIME-Version: 1.0 Message-Id: In-Reply-To: <20231116074706.3448008-1-ruanjinjie@huawei.com> References: <20231116074706.3448008-1-ruanjinjie@huawei.com> Date: Thu, 16 Nov 2023 08:39:58 -0500 From: "Arnd Bergmann" To: "Ruan Jinjie" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, "Catalin Marinas" , "Will Deacon" , "Eric W. Biederman" , "Sam Ravnborg" , "Stafford Horne" , "Dinh Nguyen" , "Mark Rutland" Subject: Re: [PATCH] arm64: Fix 32-bit compatible userspace write size overflow error X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231116_054036_522908_66A1E29F X-CRM114-Status: GOOD ( 18.68 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Nov 16, 2023, at 02:47, Jinjie Ruan wrote: > For 32-bit compatible userspace program, write with size = -1 return not > -1 but unexpected other values, which is due to the __access_ok() check is > not right. The specified "addr + size" is greater than 32-bit limit and > should return -EFAULT, but TASK_SIZE_MAX still defined as UL(1) << VA_BITS > in U32 mode, which is much greater than "addr + size" and cannot catch the > overflow error. Thank you for the detailed analysis of the change in behavior that resulted from my patch. As far as I can tell, this is an intentional change that should have been documented as part of the patch submission. > assert(write(fd, wbuf, 3) == 3); > > ret = write (fd, wbuf, SIZE_MAX); > pinfo("ret=%d\n", ret); > pinfo("size_max=%d\n",SIZE_MAX); > assert(ret==-1); I think it is wrong to have an assert() here since the documentation for write() does not state what happens when the beginning of the buffer is addressable but the end is not. We were handling this inconsistently between architectures before my patch, which ensured we do the same thing on all compat architectures now. You can argue that this behavior is inconsistent with native 32-bit mode, but at the time we decided that this was not an important distinction. > Before applying this patch, userspace 32-bit program return 1112 if the > write size = -1 as below: > /root # ./test > [INFO][test.c][32][main]:ret=-1 > [INFO][test.c][33][main]:size_max=-1 > [INFO][test.c][36][main]:INFO: end > /root # ./test32 > [INFO][test.c][32][main]:ret=1112 > [INFO][test.c][33][main]:size_max=-1 > test32: test.c:34: main: Assertion `ret==-1' failed. > Aborted Here, the write() successfully gets 1112 bytes of data, which matches what you get for any other large size that does not overflow user address space in the kernel. > Fixes: 967747bbc084 ("uaccess: remove CONFIG_SET_FS") > > #define DEFAULT_MAP_WINDOW_64 (UL(1) << VA_BITS_MIN) > #define TASK_SIZE_64 (UL(1) << vabits_actual) > +#ifdef CONFIG_COMPAT > +#define TASK_SIZE_MAX (test_thread_flag(TIF_32BIT) ? \ > + UL(0x100000000) : (UL(1) << VA_BITS)) > +#else > #define TASK_SIZE_MAX (UL(1) << VA_BITS) > +#endif This adds back the cost for every user access that I was trying to save, and it makes arm64 behave differently from the other architectures. As far as I can tell, the current behavior was originally introduced on x86 with commit 9063c61fd5cb ("x86, 64-bit: Clean up user address masking"). Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel