Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp4623857pxb; Tue, 25 Jan 2022 14:49:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJynDm+HGonR5uEqFKjnsdiIKDJbV+tt6/gdDWakWMQIrc0WwLXra+gM5c25Ixs7f0DDeOdy X-Received: by 2002:a63:7d43:: with SMTP id m3mr16523470pgn.301.1643150950751; Tue, 25 Jan 2022 14:49:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643150950; cv=none; d=google.com; s=arc-20160816; b=w1K1uws6gb2sHJq3PBeuo/mihpZLg3QbKXBHNjwt/uYtXE4T6UqeY2UJ3EHmEKr9T9 68MW+jebrUeE28JZ3TShIfpxX6D3lAVeKMFTh8XJwYN1LEhhF7Dscw+5C1kBd+nmAfVK M8gSJ3yP77qgYJaP1cv8UGvjnl21kOzOWsyk7dy2hqOcNFo7/NgvAW9P7uQ4UCCbteed 7H2Fq/lKDG1qLmANQJk0ha9xD6ae3pexPq2I9j7zX8ZkcKGlJeyjJtaFB9E4+ZsCLdbC r9L4/wnpq7vl0PI4oWobf6JXs3thPE4AcFWtstN9r7y19E4gG74eIScpw6vAEJyIT9vY 0dMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=XcpXYpKnMhxO86misGD3UorY9mrg7SOH6oSvt1Vnlz8=; b=FAt5Rp6Quk3HUXT51YZWgrql4JtEjhLTdEkvRTYTMhD/K8noVw5n+z2UNoNDmktogA 7fiklbFqgLrfnRZ8tK+8uD7+NvDaxDwyMjKis/d3WXI+vgHTVLdOgY1bwY4uFPJeO/ep 1Fmfe4uENSG9cRU9DGMYdes+RSPCDfzX0A2deGLIyUURAy/8R7gPQ1UlQ9LiXF4OCN8K 6WbbwFNB2J4212l83Ssmh53cW1HwrjhjBkhnG7O9amDNn28b/X1T/OmkWvSJ27uZq83m +a565fqSeTEcID8xUsVCld8ahcLJMcGv5JnpzNothiyvVhbjEN2MzBlKgEwCUcPLj40F tKoQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l17si9668131pls.155.2022.01.25.14.48.59; Tue, 25 Jan 2022 14:49:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357843AbiAYPfP (ORCPT + 99 others); Tue, 25 Jan 2022 10:35:15 -0500 Received: from foss.arm.com ([217.140.110.172]:50810 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356120AbiAYPc7 (ORCPT ); Tue, 25 Jan 2022 10:32:59 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4A113D6E; Tue, 25 Jan 2022 07:23:25 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.1.45]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D69FC3F793; Tue, 25 Jan 2022 07:23:23 -0800 (PST) Date: Tue, 25 Jan 2022 15:23:20 +0000 From: Mark Rutland To: Evgenii Stepanov Cc: Catalin Marinas , Will Deacon , Ard Biesheuvel , Robin Murphy , Jisheng Zhang , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: extable: fix null deref in load_unaligned_zeropad. Message-ID: References: <20220122023447.1480995-1-eugenis@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220122023447.1480995-1-eugenis@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 21, 2022 at 06:34:47PM -0800, Evgenii Stepanov wrote: > ex_handler_load_unaligned_zeropad extracts the source and data register > numbers from the wrong field of the exception table. Ouch. Did you find this by inspection, or did this show up in testing? Sorry about this. I think we should be a little more explicit as to exactly what goes wrong. How about: | In ex_handler_load_unaligned_zeropad() we erroneously extract the data and | addr register indices from ex->type rather than ex->data. As ex->type will | contain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4): | | * We'll always treat X0 as the address register, since EX_DATA_REG_ADDR is | extracted from bits [9:5]. Thus, we may attempt to dereference an arbitrary | address as X0 may hold an arbitary value. | | * We'll always treat X4 as the data register, since EX_DATA_REG_DATA is | extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary | behaviour within load_unaligned_zeropad() and its caller. | | Fix this by extracting both values from ex->data as originally intended. > Fixes: 753b3236 That should be expanded, e.g. Fixes: 753b32368705c396 ("arm64: extable: add load_unaligned_zeropad() handler") With those changes: Reviewed-by: Mark Rutland Thanks, Mark. > Signed-off-by: Evgenii Stepanov > --- > arch/arm64/mm/extable.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/mm/extable.c b/arch/arm64/mm/extable.c > index c0181e60cc98..489455309695 100644 > --- a/arch/arm64/mm/extable.c > +++ b/arch/arm64/mm/extable.c > @@ -40,8 +40,8 @@ static bool > ex_handler_load_unaligned_zeropad(const struct exception_table_entry *ex, > struct pt_regs *regs) > { > - int reg_data = FIELD_GET(EX_DATA_REG_DATA, ex->type); > - int reg_addr = FIELD_GET(EX_DATA_REG_ADDR, ex->type); > + int reg_data = FIELD_GET(EX_DATA_REG_DATA, ex->data); > + int reg_addr = FIELD_GET(EX_DATA_REG_ADDR, ex->data); > unsigned long data, addr, offset; > > addr = pt_regs_read_reg(regs, reg_addr); > -- > 2.35.0.rc0.227.g00780c9af4-goog >