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
| ||
|
Message-ID: <f14bbf8a-2070-650f-3f26-bd45aad48b88@wanadoo.fr> Date: Sun, 24 Oct 2021 16:57:49 +0200 From: Christophe JAILLET <christophe.jaillet@...adoo.fr> To: Willem de Bruijn <willemdebruijn.kernel@...il.com> 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 Le 24/10/2021 à 15:51, Willem de Bruijn a écrit : > 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. (* 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 > > >> >> 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 >> >
Powered by blists - more mailing lists