linux-kernel - Re: [ 34/77] xen/blkback: Dont trust the handle from the frontend.

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:	Fri, 01 Mar 2013 22:12:24 +0100
From:	Paul Bolle <pebolle@...cali.nl>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	Jan Beulich <jbeulich@...e.com>,
	Ian Campbell <ian.campbell@...rix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: Re: [ 34/77] xen/blkback: Dont trust the handle from the frontend.

On Fri, 2013-03-01 at 11:44 -0800, Greg Kroah-Hartman wrote:
> 3.8-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> 
> commit 01c681d4c70d64cb72142a2823f27c4146a02e63 upstream.
> 
> The 'handle' is the device that the request is from. For the life-time
> of the ring we copy it from a request to a response so that the frontend
> is not surprised by it. But we do not need it - when we start processing
> I/Os we have our own 'struct phys_req' which has only most essential
> information about the request. In fact the 'vbd_translate' ends up
> over-writing the preq.dev with a value from the backend.

Unless that call to vb_translate() fails, doesn't it? Wouldn't preq.dev
still contain random data in that case?

> This assignment of preq.dev with the 'handle' value is superfluous
> so lets not do it.
> 
> Acked-by: Jan Beulich <jbeulich@...e.com>
> Acked-by: Ian Campbell <ian.campbell@...rix.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> 
> ---
>  drivers/block/xen-blkback/blkback.c |    1 -
>  1 file changed, 1 deletion(-)
> 
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -879,7 +879,6 @@ static int dispatch_rw_block_io(struct x
>  		goto fail_response;
>  	}
>  
> -	preq.dev           = req->u.rw.handle;
>  	preq.sector_number = req->u.rw.sector_number;
>  	preq.nr_sects      = 0;
>  

This introduces a new GCC warning in the stable 3.8.y tree:
    drivers/block/xen-blkback/blkback.c: In function 'dispatch_rw_block_io':
    drivers/block/xen-blkback/blkback.c:904:3: warning: 'preq.dev' may be used uninitialized in this function [-Wuninitialized]

It does look GCC is right here. But I'm totally new to the code in
question, so I'll just ask whether this can really go in stable as is.


Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/