drivers/net/ethernet/nvidia/forcedeth.c saved_config_space[size] access patch

drivers/net/ethernet/nvidia/forcedeth.c saved_config_space[size] access patch

[Marc Weber]

[-- Attachment #1: Type: text/plain, Size: 1196 bytes --]

  1) VER3 and _MAX are of same size:
  #define NV_PCI_REGSZ_VER3       0x604
  #define NV_PCI_REGSZ_MAX        0x604


  2) It looks like there is a case where VER3 get's assigned to
      register_size:

  if (id->driver_data &
  (DEV_HAS_VLAN|DEV_HAS_MSI_X|DEV_HAS_POWER_CNTRL|DEV_HAS_STATISTICS_V2|DEV_HAS_STATISTICS_V
                  np->register_size = NV_PCI_REGSZ_VER3;

  3) the definition of saved_config_space is MAX divided by 4 (size of u32)
  struct fe_priv {
    [...]
    u32 saved_config_space[NV_PCI_REGSZ_MAX/4]

  4) This doesn't stop loop at [size-1]:
    Thus there is the risk that it overrides the field after
    saved_config_space. If that's desired behaviour at least a comment
    is missing IMHO:

  for (i = 0; i <= np->register_size/sizeof(u32); i++)
     np->saved_config_space[i] = readl(base + i*sizeof(u32));

  Such for loop is used twice in forcedeth.c

Patch againstn 4de9ad9bc08 (Fri Sep 6 11:14:33) attached fixing both
using < instead of <=.

If you think I've hit a small bug just fix and commit.
I don't care much about my ownership of this patch.

I didn't test this patch because I don't have the hardware and I think
its a trivial case.

Marc Weber

[-- Attachment #2: 0001-forcedepth-fix-possible-out-of-bounds-access.patch --]
[-- Type: application/octet-stream, Size: 1205 bytes --]

From 27cb3ef2e0797597b64773098ae0e4d1680c55cf Mon Sep 17 00:00:00 2001
From: Marc Weber <marc-oweber@gmx.de>
Date: Sun, 8 Sep 2013 23:35:28 +0200
Subject: [PATCH] forcedepth: fix possible out of bounds access

---
 drivers/net/ethernet/nvidia/forcedeth.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/nvidia/forcedeth.c b/drivers/net/ethernet/nvidia/forcedeth.c
index 098b96d..d08f6ef 100644
--- a/drivers/net/ethernet/nvidia/forcedeth.c
+++ b/drivers/net/ethernet/nvidia/forcedeth.c
@@ -6106,7 +6106,7 @@ static int nv_suspend(struct device *device)
 	netif_device_detach(dev);
 
 	/* save non-pci configuration space */
-	for (i = 0; i <= np->register_size/sizeof(u32); i++)
+	for (i = 0; i < np->register_size/sizeof(u32); i++)
 		np->saved_config_space[i] = readl(base + i*sizeof(u32));
 
 	return 0;
@@ -6121,7 +6121,7 @@ static int nv_resume(struct device *device)
 	int i, rc = 0;
 
 	/* restore non-pci configuration space */
-	for (i = 0; i <= np->register_size/sizeof(u32); i++)
+	for (i = 0; i < np->register_size/sizeof(u32); i++)
 		writel(np->saved_config_space[i], base+i*sizeof(u32));
 
 	if (np->driver_data & DEV_NEED_MSI_FIX)
-- 
1.8.3.4

Re: drivers/net/ethernet/nvidia/forcedeth.c saved_config_space[size] access patch

[Sergei Shtylyov]

Hello.

On 09/09/2013 03:39 AM, Marc Weber wrote:

>    1) VER3 and _MAX are of same size:
>    #define NV_PCI_REGSZ_VER3       0x604
>    #define NV_PCI_REGSZ_MAX        0x604


>    2) It looks like there is a case where VER3 get's assigned to
>        register_size:

>    if (id->driver_data &
>    (DEV_HAS_VLAN|DEV_HAS_MSI_X|DEV_HAS_POWER_CNTRL|DEV_HAS_STATISTICS_V2|DEV_HAS_STATISTICS_V
>                    np->register_size = NV_PCI_REGSZ_VER3;

>    3) the definition of saved_config_space is MAX divided by 4 (size of u32)
>    struct fe_priv {
>      [...]
>      u32 saved_config_space[NV_PCI_REGSZ_MAX/4]

>    4) This doesn't stop loop at [size-1]:
>      Thus there is the risk that it overrides the field after
>      saved_config_space. If that's desired behaviour at least a comment
>      is missing IMHO:

>    for (i = 0; i <= np->register_size/sizeof(u32); i++)
>       np->saved_config_space[i] = readl(base + i*sizeof(u32));

>    Such for loop is used twice in forcedeth.c

> Patch againstn 4de9ad9bc08 (Fri Sep 6 11:14:33) attached fixing both
> using < instead of <=.

> If you think I've hit a small bug just fix and commit.
> I don't care much about my ownership of this patch.

> I didn't test this patch because I don't have the hardware and I think
> its a trivial case.

    Don't attach the patches, send them inline instead. And please mark the 
mails with patches with [PATCH] in the subject.

> Marc Weber

WBR, Sergei