[PATCH] usb: core: fix information leak to userland

[PATCH] usb: core: fix information leak to userland

[Vasiliy Kulikov]

Structure usbdevfs_connectinfo is copied to userland with padding byted
after "slow" field uninitialized.  It leads to leaking of contents of
kernel stack memory.

Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
---
 Compile tested.

 drivers/usb/core/devio.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index f1aaff6..045bb4b 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -965,10 +965,11 @@ static int proc_getdriver(struct dev_state *ps, void __user *arg)
 
 static int proc_connectinfo(struct dev_state *ps, void __user *arg)
 {
-	struct usbdevfs_connectinfo ci;
+	struct usbdevfs_connectinfo ci = {
+		.devnum = ps->dev->devnum,
+		.slow = ps->dev->speed = USB_SPEED_LOW
+	};
 
-	ci.devnum = ps->dev->devnum;
-	ci.slow = ps->dev->speed = USB_SPEED_LOW;
 	if (copy_to_user(arg, &ci, sizeof(ci)))
 		return -EFAULT;
 	return 0;
-- 
1.7.0.4

Re: [PATCH] usb: core: fix information leak to userland

[Alan Stern]

On Sat, 6 Nov 2010, Vasiliy Kulikov wrote:

> Structure usbdevfs_connectinfo is copied to userland with padding byted
> after "slow" field uninitialized.  It leads to leaking of contents of
> kernel stack memory.
> 
> Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
> ---
>  Compile tested.
> 
>  drivers/usb/core/devio.c |    7 ++++---
>  1 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> index f1aaff6..045bb4b 100644
> --- a/drivers/usb/core/devio.c
> +++ b/drivers/usb/core/devio.c
> @@ -965,10 +965,11 @@ static int proc_getdriver(struct dev_state *ps, void __user *arg)
>  
>  static int proc_connectinfo(struct dev_state *ps, void __user *arg)
>  {
> -	struct usbdevfs_connectinfo ci;
> +	struct usbdevfs_connectinfo ci = {
> +		.devnum = ps->dev->devnum,
> +		.slow = ps->dev->speed = USB_SPEED_LOW
> +	};
>  
> -	ci.devnum = ps->dev->devnum;
> -	ci.slow = ps->dev->speed = USB_SPEED_LOW;
>  	if (copy_to_user(arg, &ci, sizeof(ci)))
>  		return -EFAULT;
>  	return 0;

Are you sure that adding an initializer like this will zero out the 
padding bytes?  It might be safer just to call memset.  This is not 
exactly a hot path, after all.

Alan Stern

Re: [PATCH] usb: core: fix information leak to userland

[David Brownell]

--- On Sat, 11/6/10, Alan Stern <stern@rowland.harvard.edu> wrote:

> Are you sure that adding an initializer
> like this will zero out the 
> padding bytes?  It might be safer just to call
> memset.

ISTR the C standard says things get initted to
zero in this case too ... and that compilers will
as a rule use memset to do it.  One could look
at the generated code to make sure of that.

There's certainly a fair amount of code I've seen
that uses runtime initializers like that, to zero
memory.  I can't believe i's _all_ broken!  ;)

- Dave


--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: core: fix information leak to userland

[Alan Stern]

On Sat, 6 Nov 2010, David Brownell wrote:

> --- On Sat, 11/6/10, Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> > Are you sure that adding an initializer
> > like this will zero out the 
> > padding bytes?  It might be safer just to call
> > memset.
> 
> ISTR the C standard says things get initted to
> zero in this case too ... and that compilers will
> as a rule use memset to do it.  One could look
> at the generated code to make sure of that.

Unfortunately I don't have a copy of the C standard here to consult.  
However...  Although I'm perfectly willing to believe that the standard
requires fields in a structure to be initialized to 0 if they
aren't mentioned explicitly in the initializer, I'm considerably more
doubtful that it also requires padding to be initialized!

And I certainly wouldn't want to depend on compilers _always_ using 
memset to do this initialization.

> There's certainly a fair amount of code I've seen
> that uses runtime initializers like that, to zero
> memory.  I can't believe i's _all_ broken!  ;)

Zeroing memory that belongs to a declared field is different from 
zeroing padding bytes.  Maybe what you remember seeing is the first and 
not the second.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: core: fix information leak to userland

[David Brownell]

--- On Sat, 11/6/10, Alan Stern <stern@rowland.harvard.edu> wrote:


> > 
> 
> Unfortunately I don't have a copy of the C standard here to
> consult.  
> However...  Although I'm perfectly willing to believe
> that the standard
> requires fields in a structure to be initialized to 0 if
> they
> aren't mentioned explicitly in the initializer, I'm
> considerably more
> doubtful that it also requires padding to be initialized!

ISTR initialization-to-zero is the standard
behavior defined for all _memory_ that gets
initialized ... not just named fields ...
whether the init is "static", "bss", or not.
> 
> And I certainly wouldn't want to depend on compilers
> _always_ using 
> memset to do this initialization.

Of course not; just rely on init-to-zero, and
let the compiler worry about efficiency. In
some cases memset(); in others, the result
might be as if memset were inlined, so only
a few "write a zero at this address" type
instructions would be needed.
> 
> > There's certainly a fair amount of code I've seen
> > that uses runtime initializers like that, to zero
> > memory.  I can't believe i's _all_ broken! 
> ;)
> 
> Zeroing memory that belongs to a declared field is
> different from 
> zeroing padding bytes.  Maybe what you remember seeing
> is the first and 
> not the second.

I remember seeing both, and at one point looking
at the issue to verify that padding was treated
uniformly (like other memory).  Also, writing code
that relied on zero-initted padding.

- Dave

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html