linux-kernel - Re: [PATCH] gve: Fix a possible invalid memory access

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+FuTSftgpOGxAxRE5u9o6gT_exaLtC2JkBz=iq21qe+tTTomA@mail.gmail.com>
Date:   Sun, 24 Oct 2021 09:51:35 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Christophe JAILLET <christophe.jaillet@...adoo.fr>
Cc:     jeroendb@...gle.com, csully@...gle.com, awogbemila@...gle.com,
        davem@...emloft.net, kuba@...nel.org, bcf@...gle.com,
        gustavoars@...nel.org, edumazet@...gle.com, jfraker@...gle.com,
        yangchun@...gle.com, xliutaox@...gle.com, sagis@...gle.com,
        lrizzo@...gle.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] gve: Fix a possible invalid memory access

On Sun, Oct 24, 2021 at 7:52 AM Christophe JAILLET
<christophe.jaillet@...adoo.fr> 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.


>
> 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 <christophe.jaillet@...adoo.fr>
> ---
> 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
>