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 <[email protected]>
---
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
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 <[email protected]>
> ---
> 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
--- On Sat, 11/6/10, Alan Stern <[email protected]> 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
On Sat, 6 Nov 2010, David Brownell wrote:
> --- On Sat, 11/6/10, Alan Stern <[email protected]> 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
--- On Sat, 11/6/10, Alan Stern <[email protected]> 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