Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp105985ybb; Tue, 24 Mar 2020 17:38:32 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvkVCZPQzrRpdiBftV0Cf5A5OcyK1djYQMXeEZYOLsXn3+MMP2SRbR3/UlxIIjzALBQxPNr X-Received: by 2002:a4a:d794:: with SMTP id c20mr327668oou.77.1585096712829; Tue, 24 Mar 2020 17:38:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585096712; cv=none; d=google.com; s=arc-20160816; b=gAKPNllO8UH3Xx1rwVMWvbrlVyTiGixLbHB7vg37PHOwwA/vPcpPzdt5FaluJggluh DwFXdxZx4XNALfXuUdmV1sf/T5FGxTbAOvYdChssYd66z+ibXvrOh0C+Z55CCqse9L0I 3uSauBECS8LU6IneubITA3ijTiXvv1TjUQ4DlkTnYNCro8eFmtM7T6c7FhE3a/s8xAhD DNWyEvDh41/smgH3ZYBqSiwXGHicbAMoTZZMrQ2/TpCYEGkWAzgzkc4FGMuCcqjxrACa StbichPSav/6UfyuiESBn8QJf4JqDN3m4onhF0PYShFLP5PkIJsxRetWq+A/Gxe0ico2 jRew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:to:from; bh=cCH3cGXnJcAUuZwUw87qYi/Qk09kzzA6jQOaeYhWdV8=; b=MoCZbegPvBkyLpcmMan8DCuCWfgzH6DmPRYQqRIlpiq4cKp9iUEsC9LcbTTgFOPR4B yTW5vi1cDupI6qJRcRqEaG0RfPc53lNOJ0xuJ36W9Eb1QAIo8OVPwmHDRAwj1vHHoHwU FZvAx87be+a3SjeZi2WYy5qfoCeksiSPqwzU0jfQapRXpHYfWo3fE4Gel6yLZRFmTn7q oEuXzMPhlogdde4t39sy7oOKQBk3rDYc9AmMnCbA9fRb6xbdy8nDNm/2P5sT2FeK+2DV mfq/QrrhEKebOYormFIk3s4aDVQPD/lcXz/7WRXml2wXb/ziWEj5VT1UnWqKAhqcenGt CRzQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p9si4273996oti.202.2020.03.24.17.38.17; Tue, 24 Mar 2020 17:38:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727229AbgCYAhu (ORCPT + 99 others); Tue, 24 Mar 2020 20:37:50 -0400 Received: from mta01.start.ca ([162.250.196.97]:55166 "EHLO mta01.start.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727099AbgCYAht (ORCPT ); Tue, 24 Mar 2020 20:37:49 -0400 X-Greylist: delayed 506 seconds by postgrey-1.27 at vger.kernel.org; Tue, 24 Mar 2020 20:37:49 EDT Received: from mta01.start.ca (localhost [127.0.0.1]) by mta01.start.ca (Postfix) with ESMTP id 7F76D4266E; Tue, 24 Mar 2020 20:29:21 -0400 (EDT) Received: from localhost (dhcp-24-53-240-163.cable.user.start.ca [24.53.240.163]) by mta01.start.ca (Postfix) with ESMTPS id 5527941F7F; Tue, 24 Mar 2020 20:29:18 -0400 (EDT) From: Nick Bowler To: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH] nvme: Fix NVME_IOCTL_ADMIN_CMD compat address handling. Date: Tue, 24 Mar 2020 20:28:48 -0400 Message-Id: <20200325002847.2140-1-nbowler@draconx.ca> X-Mailer: git-send-email 2.24.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On a real 32-bit kernel, the upper bits of userspace addresses passed to NVME_IOCTL_ADMIN_CMD via the nvme_passthru_cmd structure are silently ignored by the nvme driver. However on a 64-bit kernel running a compat task, these upper bits are not ignored and are in fact required to be zero for the ioctl to work. Unfortunately, this difference matters. 32-bit smartctl submits garbage in these upper bits because it seems the pointer value it puts into the nvme_passthru_cmd structure is sign extended. This works fine on a real 32-bit kernel but fails on a 64-bit one because (at least on my setup) the addresses smartctl uses are consistently above 2G. For example: # smartctl -x /dev/nvme0n1p1 smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.5.11] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org Read NVMe Identify Controller failed: NVME_IOCTL_ADMIN_CMD: Bad address Since changing 32-bit kernels to actually check all of the submitted address bits now would break existing userspace, this patch fixes the problem by explicitly zeroing the upper bits in the compat case. This enables 32-bit smartctl to work on a 64-bit kernel. Signed-off-by: Nick Bowler --- drivers/nvme/host/core.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index a4d8c90ee7cc..afb7b76d1d8a 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -6,6 +6,7 @@ #include #include +#include #include #include #include @@ -1412,6 +1413,16 @@ static int nvme_user_cmd(struct nvme_ctrl *ctrl, struct nvme_ns *ns, if (cmd.timeout_ms) timeout = msecs_to_jiffies(cmd.timeout_ms); + if (in_compat_syscall()) { + /* + * On real 32-bit kernels this implementation ignores the + * upper bits of address fields so we must replicate that + * behaviour in the compat case. + */ + cmd.addr = (compat_uptr_t)cmd.addr; + cmd.metadata = (compat_uptr_t)cmd.metadata; + } + effects = nvme_passthru_start(ctrl, ns, cmd.opcode); status = nvme_submit_user_cmd(ns ? ns->queue : ctrl->admin_q, &c, (void __user *)(uintptr_t)cmd.addr, cmd.data_len, -- 2.24.1