Messages in this thread | | | From | Willem de Bruijn <> | Date | Sun, 24 Oct 2021 11:36:41 -0400 | Subject | Re: [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.
| |