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 65696CD1292 for ; Thu, 4 Apr 2024 07:40:42 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4EiWJc3NHnN5DRZG9YGLdjOrGnpFVxJEf7AWofEbKIU=; b=IxvtAUmvMs7Nr6 n89mECnaPnOgNKf26S1wi4bOnO16oX+M90NdkVnr3VzmUOVZ26PqaoUmqq34Up6aGlvRyRpT2Kr8s wzSxG8PS8Sizx8JVrweXcQLL7zkG55XedQWYMNDIxz4ATR9C4EEr0kCLKtxD1qEPAMH8+IBXRmWnP JOo0LZGF9ymSzV3vdMplNMWfxNzwi3BquhCmT6Xf/lpEX2iYp/PozP7YAJVbY+bdSUrCMkAwcA4oe ZZSQL8CS115plqHut1SkKTg/2GCsfNzhHV7xymLsq0d+XKz6ESpDy/tWedIpwAHbGytRURqGAoRuh f4Vdofk5FAcVD2YbI9Ag==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rsHi9-00000001fwc-3SFM; Thu, 04 Apr 2024 07:40:37 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rsHi6-00000001fvc-1X7f for linux-riscv@lists.infradead.org; Thu, 04 Apr 2024 07:40:36 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id F0D2D61218; Thu, 4 Apr 2024 07:40:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2D7D7C433F1; Thu, 4 Apr 2024 07:40:30 +0000 (UTC) Message-ID: Date: Thu, 4 Apr 2024 17:40:28 +1000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] binfmt_flat: Fix corruption when not offsetting data start Content-Language: en-US To: Stefan O'Rear , linux-mm@kvack.org, linux-riscv@lists.infradead.org Cc: Eric Biederman , Kees Cook , Damien Le Moal , Waldemar Brodkorb References: <20240326032037.2478816-1-sorear@fastmail.com> From: Greg Ungerer In-Reply-To: <20240326032037.2478816-1-sorear@fastmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240404_004034_591390_AEC15298 X-CRM114-Status: GOOD ( 18.28 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org Hi Stefan, On 26/3/24 13:20, Stefan O'Rear wrote: > Commit 04d82a6d0881 ("binfmt_flat: allow not offsetting data start") > introduced a RISC-V specific variant of the FLAT format which does not > allocate any space for the (obsolescent) array of shared library > pointers. However, it did not disable the code which initializes the > array, resulting in the corruption of sizeof(long) bytes before the DATA > segment, generally the end of the TEXT segment. > > Use CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard initialization the > shared library pointer region so that it will only be initialized if > space is reserved for it. > > Fixes: 04d82a6d0881 ("binfmt_flat: allow not offsetting data start") > Signed-off-by: Stefan O'Rear > Tested-by: Waldemar Brodkorb > --- > fs/binfmt_flat.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c > index c26545d71d39..70c2b68988f4 100644 > --- a/fs/binfmt_flat.c > +++ b/fs/binfmt_flat.c > @@ -879,6 +879,7 @@ static int load_flat_binary(struct linux_binprm *bprm) > if (res < 0) > return res; > > +#ifndef CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET > /* Update data segment pointers for all libraries */ > for (i = 0; i < MAX_SHARED_LIBS; i++) { ^^^^^^^^^^^^^^^ It may be cleaner (ie no # conditional required) if this was changed to DATA_START_OFFSET_WORDS. So becoming: for (i = 0; i < DATA_START_OFFSET_WORDS; i++) { My only concern is does this make it less clear what the code is doing? Regards Greg > if (!libinfo.lib_list[i].loaded) > @@ -893,6 +894,7 @@ static int load_flat_binary(struct linux_binprm *bprm) > return -EFAULT; > } > } > +#endif > > set_binfmt(&flat_format); > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D569CCD1284 for ; Thu, 4 Apr 2024 07:40:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 518A86B0083; Thu, 4 Apr 2024 03:40:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C6EA6B0087; Thu, 4 Apr 2024 03:40:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B58A6B0088; Thu, 4 Apr 2024 03:40:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 20D746B0083 for ; Thu, 4 Apr 2024 03:40:36 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D62C9A153E for ; Thu, 4 Apr 2024 07:40:35 +0000 (UTC) X-FDA: 81971052030.16.6A841B3 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf18.hostedemail.com (Postfix) with ESMTP id 1CAA31C0014 for ; Thu, 4 Apr 2024 07:40:33 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of "SRS0=rcyI=LJ=linux-m68k.org=gerg@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=rcyI=LJ=linux-m68k.org=gerg@kernel.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712216434; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FEYdE4k+0e1Wyv6j27ho0cyXaWFUZhZDyITmPez+z3U=; b=L4TMac90Oi1dj3WL1RQGetwuhk3TqrNHP7K6gXwquKUibDx7QLhtvzLfv0oqSJrB8aHWv0 YhNfGQyVR526UJBxTqdurIdiMfMVM5fslXwVutEHJGNh4cXbKkEjUup8o+ry5G7F1pY2La KNPRJoaE2Ui6TD4eF3wW1NreIvI/vTQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712216434; a=rsa-sha256; cv=none; b=qhk6Xk+qkhfTD3PGDSv0+37gIpWFn3WHZeos9QyGZxkO78rVfC9fOgog8LliUMAHYq/RsT mpWuwl6gJT7ZI+y8o4H57bXVFm5VQzzyPNyO9t/TYu13qU8Qrdxh33VrLjtkbSinXvd/p6 z8Tx88XrpG+ml56i02Kzz4rNWuIH47k= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of "SRS0=rcyI=LJ=linux-m68k.org=gerg@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=rcyI=LJ=linux-m68k.org=gerg@kernel.org"; dmarc=none Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id F0D2D61218; Thu, 4 Apr 2024 07:40:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2D7D7C433F1; Thu, 4 Apr 2024 07:40:30 +0000 (UTC) Message-ID: Date: Thu, 4 Apr 2024 17:40:28 +1000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] binfmt_flat: Fix corruption when not offsetting data start Content-Language: en-US To: Stefan O'Rear , linux-mm@kvack.org, linux-riscv@lists.infradead.org Cc: Eric Biederman , Kees Cook , Damien Le Moal , Waldemar Brodkorb References: <20240326032037.2478816-1-sorear@fastmail.com> From: Greg Ungerer In-Reply-To: <20240326032037.2478816-1-sorear@fastmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: exrade9c949zx6gdurox5mn6cmuiwdse X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 1CAA31C0014 X-Rspam-User: X-HE-Tag: 1712216433-150269 X-HE-Meta: U2FsdGVkX1/5huYrJUnCyOft/uY8LNbbum2/wSkXH/M0r2MfS05pxnDvwUMD6Q5Y8w/VgZcj/z5qLpKy4Vf2Zt19gPd76MIjuh7Q5eM/TNztfdOrkku4i52nXcfe9MwfuZCsucueklgxpVjwdXBKPJI7XOEgaj3hO0Ky+GWiX6O3EbjRIQGLZubAR4FiWNP5jDcocrqf9jGCSIXMc5lBVsqAJ2xGL2x9/J9KyGNZDB9lK0DxyC5eLoD5nUnIIT5MdKdy6njywOaGrZpQywrHw0n84nveAWR10HTWI7vOpio/LbqGsWkqcBh8g78Z4VZW5sMw1b22VeQKCLQu3l6wFM5GiUYinwbfu/E2eqGQOhnTz0Ngw4N6H/OAo+vXlu5QWljH7ZeFxX9pQsq5XXsA2RuwAlUiQnauYeOqFeyprY7Hky7u6bIMIJQ0y48XxxLnhkSpN7ab3nSSMV2NVFzx/3edsR7jKI3clYFxog6PUmz5QzkYOKIYH0UNBU3hy6gX8VWX9CV919y5j9nVomqemozvqWdaVdAuYWoaBclBukq7sJ8fWQncFfnEyFpK9H4EoewUCIrA4yW2e50y+/To+k9MCoFXY5qCR3K1aycRWTt2XfIC0EEGTLjue8v0lfWAYawA7+xYSZTbpNPoBmybeFd/B2bDoy3kbdKqUhJthrZu2cBsgBxRByGmryB4dNacyrp4KqEJ+VrAQ+yfJIxn1mp89EkFef3V4FrB1gQ9jla+9tWR63vQ7H2evIxOcycZI9Ti0b1qUwu/0F+KdK469ppH3lVBZshtSCIZC9l69J1LvMz1gclFLOs8vGr8NAevfl+3xNVXZErQbCMVQ0xNWQjc+D4n7ydr4CRO4B0AfP4O+NQrsc2opXZ5lgIPbkUBSxroDbyomUhRK/3MtJ7vPbbVKPU8rbYmeWqynKqyJaLbCrWTQMsni9G/XwX5Rf8r6ofX/HgIVaJ2+vRpFnw va57d7di Gx9L5Np5QIq3znGvtN5CXxYATFtGFj7K2ta86N8U0xZMZj4WIDUWJS4CKrn2F156YsfPqg1Fmt7UJlypU42EM3Ml8vRTl+NHvHEMN9TNOUi0vKxVMa/OVV8s+AveDEdcghciXCrA8AL1U8VFzLLfFd+XIfKT1WCL/4pGJQ1oTgeGMFs9HEEfSLTudiW0kt0EmUBF10xjlKEyFZUOzyQrkxu/efRiCAFqNTr85rfZ1l8vphfMehlb9F1oVmHIN4sGqUe8i/nDmox76lpJHyJh/HMVpeX9xsionjmCB5vl0qD9aGJKq/QMqKeqTwGZigSz0jdK7s+0YSn1HQN9EuC/vqFMjd4YxNXMj/MEozSsAjwyvF//ZPDbZCYg+VMaL5mQKY8iUdz5qjnGIC7vILiNSHHhfqSJ5BI2ZG6bYZexJwtOY31qMTkoJL4vHOlhV4lmcfjh72D5TNe639AMPgQDJEnkOWgnY53cahy0OTAWPuleJcRVAHDGaBXPfuA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Stefan, On 26/3/24 13:20, Stefan O'Rear wrote: > Commit 04d82a6d0881 ("binfmt_flat: allow not offsetting data start") > introduced a RISC-V specific variant of the FLAT format which does not > allocate any space for the (obsolescent) array of shared library > pointers. However, it did not disable the code which initializes the > array, resulting in the corruption of sizeof(long) bytes before the DATA > segment, generally the end of the TEXT segment. > > Use CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard initialization the > shared library pointer region so that it will only be initialized if > space is reserved for it. > > Fixes: 04d82a6d0881 ("binfmt_flat: allow not offsetting data start") > Signed-off-by: Stefan O'Rear > Tested-by: Waldemar Brodkorb > --- > fs/binfmt_flat.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c > index c26545d71d39..70c2b68988f4 100644 > --- a/fs/binfmt_flat.c > +++ b/fs/binfmt_flat.c > @@ -879,6 +879,7 @@ static int load_flat_binary(struct linux_binprm *bprm) > if (res < 0) > return res; > > +#ifndef CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET > /* Update data segment pointers for all libraries */ > for (i = 0; i < MAX_SHARED_LIBS; i++) { ^^^^^^^^^^^^^^^ It may be cleaner (ie no # conditional required) if this was changed to DATA_START_OFFSET_WORDS. So becoming: for (i = 0; i < DATA_START_OFFSET_WORDS; i++) { My only concern is does this make it less clear what the code is doing? Regards Greg > if (!libinfo.lib_list[i].loaded) > @@ -893,6 +894,7 @@ static int load_flat_binary(struct linux_binprm *bprm) > return -EFAULT; > } > } > +#endif > > set_binfmt(&flat_format); >