linux-kernel - Re: [PATCH] staging: lustre: Fix a spatch warning due to an assignment from kernel to user space

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:   Mon, 5 Dec 2016 23:52:00 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Quentin Lambert <lambert.quentin@...il.com>
Cc:     Oleg Drokin <oleg.drokin@...el.com>,
        Andreas Dilger <andreas.dilger@...el.com>,
        James Simmons <jsimmons@...radead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        lustre-devel@...ts.lustre.org, devel@...verdev.osuosl.org,
        linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] staging: lustre: Fix a spatch warning due to an
 assignment from kernel to user space

On Fri, Dec 02, 2016 at 06:33:32PM +0100, Quentin Lambert wrote:
> lnet_ipif_enumerate was assigning a pointer from kernel space to user
> space. This patch uses copy_to_user to properly do that assignment.

Put the exact warning message here.

> 
> Signed-off-by: Quentin Lambert <lambert.quentin@...il.com>
> ---
>  shouldn't we be using ifc_req instead of ifc_buf?
> 
>  drivers/staging/lustre/lnet/lnet/lib-socket.c |    8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> --- a/drivers/staging/lustre/lnet/lnet/lib-socket.c
> +++ b/drivers/staging/lustre/lnet/lnet/lib-socket.c
> @@ -181,7 +181,13 @@ lnet_ipif_enumerate(char ***namesp)
>  			goto out0;
>  		}
>  
> -		ifc.ifc_buf = (char *)ifr;
> +		rc = copy_to_user(ifc.ifc_buf, (char *)ifr,
> +				  nalloc * sizeof(*ifr));
> +		if (rc) {
> +			rc = -ENOMEM;
> +			goto out1;
> +		}


No idea what's going on here.  The original code is correct.

regards,
dan carpenter