netdev - Re: [PATCH] ethtool: Use kcalloc instead of kmalloc for ethtool_get

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]

Date:	Wed, 14 Oct 2015 21:36:19 +0100
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Joe Perches <joe@...ches.com>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	David Miller <davem@...emloft.net>
Cc:	Jacob Keller <jacob.e.keller@...el.com>, netdev@...r.kernel.org,
	nhorman@...hat.com, sassmann@...hat.com, jogreene@...hat.com,
	Bruce Allan <bruce.w.allan@...el.com>
Subject: Re: [PATCH] ethtool: Use kcalloc instead of kmalloc for
 ethtool_get_strings

On Wed, 2015-10-14 at 01:09 -0700, Joe Perches wrote:
> It seems that kernel memory can leak into userspace by a
> kmalloc, ethtool_get_strings, then copy_to_user sequence.
> 
> Avoid this by using kcalloc to zero fill the copied buffer.
> 
> Signed-off-by: Joe Perches <joe@...ches.com>
> ---
> 
> stable too...
> 
> On Tue, 2015-10-13 at 23:59 -0700, Jeff Kirsher wrote:
> > From: Jacob Keller <jacob.e.keller@...el.com>
> []
> > diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
> []
> > @@ -206,13 +206,13 @@ static void fm10k_get_stat_strings(struct net_device *dev, u8 *data)
> >  > > 	> > }
> >  
> >  > > 	> > for (i = 0; i < interface->hw.mac.max_queues; i++) {
> > -> > 	> > 	> > sprintf(p, "tx_queue_%u_packets", i);
> > +> > 	> > 	> > snprintf(p, ETH_GSTRING_LEN, "tx_queue_%u_packets", i);
> 
> It seems these need a memset after the snprintf to zero fill
> bytes after the string terminating \0 to avoid leaking
> contents of any unset bytes.

Right.  It used to be that all drivers were memcpy()ing from a static
array which had all the necessary zero bytes, but now there are a bunch
of them using s{,n}printf() or otherwise dynamically generating names
for statistics or tests.  And I don't think there's any snprintf()-
alike function that will fix that.

At least these drivers aren't zero-padding all strings: bnx2x, bnad,
i40e, i40evf, igb, ixgbe, liquidio, mlx4_en, mlx5e, nicvf, qlcnic, sfc,
vxge.

Acked-by: Ben Hutchings <ben@...adent.org.uk>

Ben.

> It'd probably be better to allocate a zeroed buffer instead.
> 
> >  		p += ETH_GSTRING_LEN;
> > -		sprintf(p, "tx_queue_%u_bytes", i);
> > +> > 	> > 	> > snprintf(p, ETH_GSTRING_LEN, "tx_queue_%u_bytes", i);
> 
> so...
> 
>  net/core/ethtool.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index b495ab1..29edf74 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -1284,7 +1284,7 @@ static int ethtool_get_strings(struct net_device *dev, void __user *useraddr)
>  
>  	gstrings.len = ret;
>  
> -	data = kmalloc(gstrings.len * ETH_GSTRING_LEN, GFP_USER);
> +	data = kcalloc(gstrings.len, ETH_GSTRING_LEN, GFP_USER);
>  	if (!data)
>  		return -ENOMEM;
>  
> 
> 
-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had thought.
... I realized that a large part of my life from then on was going to be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949

Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)