Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <fb712f802228ab4319891983164bf45e90d529e7.1635076200.git.christophe.jaillet@wanadoo.fr>
 <CA+FuTSftgpOGxAxRE5u9o6gT_exaLtC2JkBz=iq21qe+tTTomA@mail.gmail.com> <f14bbf8a-2070-650f-3f26-bd45aad48b88@wanadoo.fr>
In-Reply-To: <f14bbf8a-2070-650f-3f26-bd45aad48b88@wanadoo.fr>
From:   Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date:   Sun, 24 Oct 2021 11:36:41 -0400
Message-ID: <CAF=yD-K+ZwjCZ3j3vELjYT5spE3RB2KBxg-Q2YK0f++PXjnEsw@mail.gmail.com>
Subject: Re: [PATCH] gve: Fix a possible invalid memory access
To:     Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc:     jeroendb@google.com, Catherine Sullivan <csully@google.com>,
        awogbemila@google.com, David Miller <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Bailey Forrest <bcf@google.com>,
        "Gustavo A . R . Silva" <gustavoars@kernel.org>,
        Eric Dumazet <edumazet@google.com>,
        John Fraker <jfraker@google.com>, yangchun@google.com,
        xliutaox@google.com, Sagi Shahar <sagis@google.com>,
        Luigi Rizzo <lrizzo@google.com>,
        Network Development <netdev@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        kernel-janitors@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sun, Oct 24, 2021 at 10:58 AM Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
>
> Le 24/10/2021 =C3=A0 15:51, Willem de Bruijn a =C3=A9crit :
> > On Sun, Oct 24, 2021 at 7:52 AM Christophe JAILLET
> > <christophe.jaillet@wanadoo.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 re=
gion
> >       * @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 =3D num_qpls;'?

Yes, that seems more straightforward to me too.