lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200802153930.5271-1-baijiaju@tsinghua.edu.cn>
Date:   Sun,  2 Aug 2020 23:39:30 +0800
From:   Jia-Ju Bai <baijiaju@...nghua.edu.cn>
To:     linux-net-drivers@...arflare.com, ecree@...arflare.com,
        mhabets@...arflare.com, davem@...emloft.net, kuba@...nel.org
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jia-Ju Bai <baijiaju@...nghua.edu.cn>
Subject: [PATCH] net: sfc: fix possible buffer overflow caused by bad DMA value in efx_siena_sriov_vfdi()

In efx_siena_sriov_vfdi():
  req = vf->buf.addr;

Because "vf->buf.addr" is mapped to coherent DMA (allocated in
efx_nic_alloc_buffer()), "req" is also mapped to DMA.

Then "req->op" is accessed in this function:
  if (req->op < VFDI_OP_LIMIT && vfdi_ops[req->op] != NULL) {
    rc = vfdi_ops[req->op](vf);

Because "req" is mapped to DMA, its data can be modified at any time by
malicious or malfunctioning hardware. In this case, the check 
"if (req->op < VFDI_OP_LIMIT)" can be passed, and then "req->op" can be
modified to cause buffer overflow when the driver accesses
"vfdi_ops[req->op]".

To fix this problem, "req->op" is assigned to a local variable, and then
the driver accesses this variable instead of "req->op".

Signed-off-by: Jia-Ju Bai <baijiaju@...nghua.edu.cn>
---
 drivers/net/ethernet/sfc/siena_sriov.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/sfc/siena_sriov.c b/drivers/net/ethernet/sfc/siena_sriov.c
index 83dcfcae3d4b..21a8482cbb3b 100644
--- a/drivers/net/ethernet/sfc/siena_sriov.c
+++ b/drivers/net/ethernet/sfc/siena_sriov.c
@@ -875,6 +875,7 @@ static void efx_siena_sriov_vfdi(struct work_struct *work)
 	struct vfdi_req *req = vf->buf.addr;
 	struct efx_memcpy_req copy[2];
 	int rc;
+	u32 op = req->op;
 
 	/* Copy this page into the local address space */
 	memset(copy, '\0', sizeof(copy));
@@ -894,17 +895,17 @@ static void efx_siena_sriov_vfdi(struct work_struct *work)
 		return;
 	}
 
-	if (req->op < VFDI_OP_LIMIT && vfdi_ops[req->op] != NULL) {
-		rc = vfdi_ops[req->op](vf);
+	if (op < VFDI_OP_LIMIT && vfdi_ops[op] != NULL) {
+		rc = vfdi_ops[op](vf);
 		if (rc == 0) {
 			netif_dbg(efx, hw, efx->net_dev,
 				  "vfdi request %d from %s ok\n",
-				  req->op, vf->pci_name);
+				  op, vf->pci_name);
 		}
 	} else {
 		netif_dbg(efx, hw, efx->net_dev,
 			  "ERROR: Unrecognised request %d from VF %s addr "
-			  "%llx\n", req->op, vf->pci_name,
+			  "%llx\n", op, vf->pci_name,
 			  (unsigned long long)vf->req_addr);
 		rc = VFDI_RC_EOPNOTSUPP;
 	}
-- 
2.17.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ