lkml.org 
[lkml]   [2021]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] gve: Fix a possible invalid memory access
On Sun, Oct 24, 2021 at 10:58 AM Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
>
> Le 24/10/2021 à 15:51, Willem de Bruijn a écrit :
> > 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 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.

\
 
 \ /
  Last update: 2021-10-24 17:38    [W:0.049 / U:1.756 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site