[PATCH] gve: Fix a possible invalid memory access

It is spurious to allocate a bitmap for 'num_qpls' bits and record the
size of this bitmap with another value.

'qpl_map_size' is used in 'drivers/net/ethernet/google/gve/gve.h' with
'find_[first|next]_zero_bit()'.
So, it looks that memory after the allocated 'qpl_id_map' could be
scanned.

Remove the '* BITS_PER_BYTE' to have allocation and length be the same.

Fixes: f5cedc84a30d ("gve: Add transmit and receive support")
Signed-off-by: Christophe JAILLET <redacted>
---
This patch is completely speculative and un-tested!
You'll be warned.
---
 drivers/net/ethernet/google/gve/gve_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
index 7647cd05b1d2..19fe9e9b62f5 100644
--- a/drivers/net/ethernet/google/gve/gve_main.c
+++ b/drivers/net/ethernet/google/gve/gve_main.c

@@ -866,7 +866,7 @@ static int gve_alloc_qpls(struct gve_priv *priv)
 	}
 
 	priv->qpl_cfg.qpl_map_size = BITS_TO_LONGS(num_qpls) *
-				     sizeof(unsigned long) * BITS_PER_BYTE;
+				     sizeof(unsigned long);
 	priv->qpl_cfg.qpl_id_map = kvcalloc(BITS_TO_LONGS(num_qpls),
 					    sizeof(unsigned long), GFP_KERNEL);
 	if (!priv->qpl_cfg.qpl_id_map) {

-- 
2.30.2

On Sun, Oct 24, 2021 at 7:52 AM Christophe JAILLET
[off-list ref] wrote:

It is spurious to allocate a bitmap for 'num_qpls' bits and record the
size of this bitmap with another value.

'qpl_map_size' is used in 'drivers/net/ethernet/google/gve/gve.h' with
'find_[first|next]_zero_bit()'.
So, it looks that memory after the allocated 'qpl_id_map' could be
scanned.

find_first_zero_bit takes a length argument in bits:

    /**
     * find_first_zero_bit - find the first cleared bit in a memory region
     * @addr: The address to start the search at
     * @size: The maximum number of bits to search

qpl_map_size is passed to find_first_zero_bit.

It does seem roundabout to compute first the number of longs needed to
hold num_qpl bits

    BITS_TO_LONGS(num_qpls)

then again compute the number of bits in this buffer

    * sizeof(unsigned long) * BITS_PER_BYTE

Which will simply be num_qpls again.

But, removing BITS_PER_BYTE does not arrive at the right number.

Le 24/10/2021 à 15:51, Willem de Bruijn a écrit :

On Sun, Oct 24, 2021 at 7:52 AM Christophe JAILLET
[off-list ref] wrote:

quoted

It is spurious to allocate a bitmap for 'num_qpls' bits and record the
size of this bitmap with another value.

'qpl_map_size' is used in 'drivers/net/ethernet/google/gve/gve.h' with
'find_[first|next]_zero_bit()'.
So, it looks that memory after the allocated 'qpl_id_map' could be
scanned.

find_first_zero_bit takes a length argument in bits:

     /**
      * find_first_zero_bit - find the first cleared bit in a memory region
      * @addr: The address to start the search at
      * @size: The maximum number of bits to search

qpl_map_size is passed to find_first_zero_bit.

It does seem roundabout to compute first the number of longs needed to
hold num_qpl bits

     BITS_TO_LONGS(num_qpls)

then again compute the number of bits in this buffer

     * sizeof(unsigned long) * BITS_PER_BYTE

Which will simply be num_qpls again.

But, removing BITS_PER_BYTE does not arrive at the right number.

(* embarrassed *)

So obvious.
Thank you for taking time for the explanation on a so badly broken patch.

I apologize for the noise and the waste of time :(


BTW, why not just have 'priv->qpl_cfg.qpl_map_size = num_qpls;'?

CJ

quoted

Remove the '* BITS_PER_BYTE' to have allocation and length be the same.

Fixes: f5cedc84a30d ("gve: Add transmit and receive support")
Signed-off-by: Christophe JAILLET <redacted>
---
This patch is completely speculative and un-tested!
You'll be warned.
---
  drivers/net/ethernet/google/gve/gve_main.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
index 7647cd05b1d2..19fe9e9b62f5 100644
--- a/drivers/net/ethernet/google/gve/gve_main.c
+++ b/drivers/net/ethernet/google/gve/gve_main.c

@@ -866,7 +866,7 @@ static int gve_alloc_qpls(struct gve_priv *priv)
         }

         priv->qpl_cfg.qpl_map_size = BITS_TO_LONGS(num_qpls) *
-                                    sizeof(unsigned long) * BITS_PER_BYTE;
+                                    sizeof(unsigned long);
         priv->qpl_cfg.qpl_id_map = kvcalloc(BITS_TO_LONGS(num_qpls),
                                             sizeof(unsigned long), GFP_KERNEL);
         if (!priv->qpl_cfg.qpl_id_map) {
--

2.30.2

On Sun, Oct 24, 2021 at 10:58 AM Christophe JAILLET
[off-list ref] wrote:

Le 24/10/2021 à 15:51, Willem de Bruijn a écrit :

quoted

On Sun, Oct 24, 2021 at 7:52 AM Christophe JAILLET
[off-list ref] wrote:

quoted

It is spurious to allocate a bitmap for 'num_qpls' bits and record the
size of this bitmap with another value.

'qpl_map_size' is used in 'drivers/net/ethernet/google/gve/gve.h' with
'find_[first|next]_zero_bit()'.
So, it looks that memory after the allocated 'qpl_id_map' could be
scanned.

find_first_zero_bit takes a length argument in bits:

     /**
      * find_first_zero_bit - find the first cleared bit in a memory region
      * @addr: The address to start the search at
      * @size: The maximum number of bits to search

qpl_map_size is passed to find_first_zero_bit.

It does seem roundabout to compute first the number of longs needed to
hold num_qpl bits

     BITS_TO_LONGS(num_qpls)

then again compute the number of bits in this buffer

     * sizeof(unsigned long) * BITS_PER_BYTE

Which will simply be num_qpls again.

But, removing BITS_PER_BYTE does not arrive at the right number.

(* embarrassed *)

So obvious.
Thank you for taking time for the explanation on a so badly broken patch.

I apologize for the noise and the waste of time :(

No worries, it happens. Thanks for reviewing code.

BTW, why not just have 'priv->qpl_cfg.qpl_map_size = num_qpls;'?

Yes, that seems more straightforward to me too.