Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5539325pxb; Wed, 26 Jan 2022 14:30:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJwF38qxaDW/g8ZehuSNb/9EGGdAcCXJROTn+jKyxNSYjKXmNoRAUKDUsWSipMgWbCbCnMtE X-Received: by 2002:a17:907:1b21:: with SMTP id mp33mr666222ejc.523.1643236248566; Wed, 26 Jan 2022 14:30:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643236248; cv=none; d=google.com; s=arc-20160816; b=yR+jeDUuSreF8v50d2DqknfCjA3Z8Zph+sgDW9XPxeVWrYhnCKzwBCwYXz9xULWe5n QGzPIMUMsRQ4QClVEd8nIk4PA/1IwAdEmfoofmfIOLbxMvcNYxhzmwAqh8fVpLvot1m/ 66Lg2kRTTHiEpYfqlQizLNnxuAgXYA0BPXJhf05NtqENs/tdY+Uy8rr0rUKWA9sfDKPV 9+XzXHDUKHbRZK9L1F0xEiB9d0lk1CjVFSQBBIV96JcIwstcE5vTOUmM/un43Qr7CkcV jq0PrkhEjPQaHjro5Qx6+Jtx94NkZU+r8xjKQ1AlsoeVMEZaGxZrGl+F1BiX2m7XDmJ6 YcGA== 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 :references:in-reply-to:message-id:date:subject:cc:to:from; bh=qxGOUFAAYnkhNsns3BINTuxkVSX5fBPtw6To2jvzsZU=; b=NEVXitsM03WakkmQE+mkl+pRWHWPxzfoxyIFjAkyTbZW3F+NNjNOgLzfz5fQmo3q4j p0H5QdbxuCDspNnc3FdvfXmyTe0P/ojiLSJAkY8hOO4eASL8wCoyDb3Fg+vZIC2q92xu kaoHQtIOrGoBxN70cQbVlWef1eRXW275NLnnuPwyLh9tdcMtbJwbk+6JKbPmFoDoOu4i iiIRqlhClvQX1xtSBuipK+j+c/PWEHGeXnPRpwQV4hVspt8dW1JK2C62p6TO3uPKJrkB modDkHg6WNnim3zXbVHqIiV0ZRdpLn0fQmwaPD96XkaaMiPIf+VSA3lykwfXtNgVNWw7 Phlg== 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 hz6si302412ejc.880.2022.01.26.14.30.23; Wed, 26 Jan 2022 14:30:48 -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 S244322AbiAZS5a (ORCPT + 99 others); Wed, 26 Jan 2022 13:57:30 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:48890 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240700AbiAZS52 (ORCPT ); Wed, 26 Jan 2022 13:57:28 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B16E4B81FB3; Wed, 26 Jan 2022 18:57:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 84D5AC340E3; Wed, 26 Jan 2022 18:57:24 +0000 (UTC) From: Catalin Marinas To: Robin Murphy , Ard Biesheuvel , Mark Rutland , Will Deacon , Jisheng Zhang , Evgenii Stepanov Cc: stable@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2] arm64: extable: fix load_unaligned_zeropad() reg indices Date: Wed, 26 Jan 2022 18:57:21 +0000 Message-Id: <164322343553.819367.16239308759447224919.b4-ty@arm.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20220125182217.2605202-1-eugenis@google.com> References: <20220125182217.2605202-1-eugenis@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 25 Jan 2022 10:22:17 -0800, Evgenii Stepanov wrote: > 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 arbitrary 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. > > [...] Applied to arm64 (for-next/fixes), thanks! [1/1] arm64: extable: fix load_unaligned_zeropad() reg indices https://git.kernel.org/arm64/c/afa1bf69aac3 -- Catalin