Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4657613imm; Mon, 30 Jul 2018 20:09:07 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcE4PrgtvmkKtKqkXUfRcl8eV2faCkYTZTkQl3YQESJuRenRsYLtS1zugBRnH/t7SSIlwzm X-Received: by 2002:a17:902:76c7:: with SMTP id j7-v6mr13926783plt.275.1533006547828; Mon, 30 Jul 2018 20:09:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533006547; cv=none; d=google.com; s=arc-20160816; b=TalHBLnv17Rnn/TIAQJxrWly2yHs+Z2TckP+k9SxzBq+KyE6UhL1XvdHhJea3trN0m rklD168vrEVBjs5I08X/ItpYsauJXWj6NVB5X+duVgdZsbV0Jeic+F1nrtrj1ZoqGl53 wA4dvWZNuxoeywSCD/s+xNhZ2tZeMGpe6fcFHlCNpna75cI8OCkvdXKlEC4LsEIJx+tZ zAmxB9l6kH6d7gjgB3PfZf5VUobBuYz3LsUwfBIOSNR+mxB7PgMYsn1tH/FW+thM4Lvh TGnQA6W1aKZiIoKzQB7A5MCY02BEksMwvKLaDgUwNgqaBn53fm1q9fGBMWYXBPDfEJ93 s2eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=ekqUsTmLCPbih+eZbTitDIaTteawLXewlO0AMaxcriM=; b=OzBhnDMWoHTXhSrY4/jEqZ0nZ7VMmGKtephPLbbhSD0Y0fxAIxBEv6+UDRDm9jwEsG 4Qpjuh0gHkz1YCI2KMfs81cjvQWsajYRo3THNLSJhBkm+OaQjMCFp9ESRoJDP6vJFoo8 WXimsZd5N0BiXS0OhEOsExtnvlINLHyLe1IpeKZWuLqsTEbzrV8sO8e1fRDXU3lv7ZDa 8mQMhmuocWxzVKppTHEPgGiNIMnv7ZBjRyHMxDbad4Ta7HPE64q8GZx/2y0P3a6hUVAf MTPYpLT6Opw2Fssp5Ltos9vQfpvPnUPccOBe9iG4gxDJzv1CJPFAIy8T2QIDwWVqBxYS dNxA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g85-v6si859304pfa.37.2018.07.30.20.08.53; Mon, 30 Jul 2018 20:09:07 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727255AbeGaEpb (ORCPT + 99 others); Tue, 31 Jul 2018 00:45:31 -0400 Received: from mga05.intel.com ([192.55.52.43]:49219 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725853AbeGaEpb (ORCPT ); Tue, 31 Jul 2018 00:45:31 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jul 2018 20:07:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,425,1526367600"; d="scan'208";a="249749831" Received: from linux.intel.com ([10.54.29.200]) by fmsmga005.fm.intel.com with ESMTP; 30 Jul 2018 20:07:29 -0700 Received: from dazhang1-ssd.sh.intel.com (dazhang1-ssd.sh.intel.com [10.239.48.78]) by linux.intel.com (Postfix) with ESMTP id 6C787580335; Mon, 30 Jul 2018 20:07:27 -0700 (PDT) From: Zhang Yi To: linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org, dan.j.williams@intel.com, jack@suse.cz, zwisler@kernel.org, dave.jiang@intel.com, yu.c.zhang@intel.com Cc: yi.z.zhang@intel.com, Zhang Yi Subject: [RFC PATCH 1/1] device-dax: check for vma range while dax_mmap. Date: Tue, 31 Jul 2018 19:46:06 +0800 Message-Id: X-Mailer: git-send-email 2.7.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org It should be prevent user map an illegal vma range which larger than dax device phiscal resourse, as we don't have swap logic while page faulting in dax device. Applications, especailly qemu, map the /dev/dax for virtual nvdimm's backend device, we defined the v-nvdimm label area at the end of mapped rang. By using an illegal size that exceeds the physical resource of /dev/dax, then it will triger qemu a signal fault while accessing these label area. Signed-off-by: Zhang Yi --- drivers/dax/device.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/drivers/dax/device.c b/drivers/dax/device.c index aff2c15..c9a50cd 100644 --- a/drivers/dax/device.c +++ b/drivers/dax/device.c @@ -177,6 +177,32 @@ static const struct attribute_group *dax_attribute_groups[] = { NULL, }; +static int check_vma_range(struct dev_dax *dev_dax, struct vm_area_struct *vma, + const char *func) +{ + struct device *dev = &dev_dax->dev; + struct resource *res; + unsigned long size; + int ret, i; + + if (!dax_alive(dev_dax->dax_dev)) + return -ENXIO; + + size = vma->vm_end - vma->vm_start + (vma->vm_pgoff << PAGE_SHIFT); + ret = -EINVAL; + for (i = 0; i < dev_dax->num_resources; i++) { + res = &dev_dax->res[i]; + if (size > resource_size(res)) { + dev_info(dev, "%s: %s: fail, vma range is overflow\n", + current->comm, func); + ret = -EINVAL; + continue; + } else + return 0; + } + return ret; +} + static int check_vma(struct dev_dax *dev_dax, struct vm_area_struct *vma, const char *func) { @@ -465,6 +491,8 @@ static int dax_mmap(struct file *filp, struct vm_area_struct *vma) */ id = dax_read_lock(); rc = check_vma(dev_dax, vma, __func__); + if (!rc) + rc |= check_vma_range(dev_dax, vma, __func__); dax_read_unlock(id); if (rc) return rc; -- 2.7.4