[PATCH] Fix stack corruption on some architectures

[PATCH] Fix stack corruption on some architectures

[Daniel Gimpelevich]

There is no need to get an interface specification if we know it's the
wrong one; trivial change. The big thing, though, was explained in the
#mipslinux IRC channel: 
[Mon 2013-08-19 12:28:21 PM PDT] <headless> guys, are you sure it's not "DMA off stack" case?
[Mon 2013-08-19 12:28:35 PM PDT] <headless> it's a known stack corruptor on non-coherent arches
[Mon 2013-08-19 12:31:48 PM PDT] <DonkeyHotei> headless: for usb/ehci?
[Mon 2013-08-19 12:34:11 PM PDT] <DonkeyHotei> headless: explain
[Mon 2013-08-19 12:35:38 PM PDT] <headless> usb_control_msg() (or other such func) should not use buffer on stack. DMA from/to stack is prohibited
[Mon 2013-08-19 12:35:58 PM PDT] <headless> and EHCI uses DMA on control xfers (as well as all the others)

Signed-off-by: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
---
 drivers/net/usb/hso.c |   15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index cba1d46..86292e6 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -2816,13 +2816,16 @@ exit:
 static int hso_get_config_data(struct usb_interface *interface)
 {
 	struct usb_device *usbdev = interface_to_usbdev(interface);
-	u8 config_data[17];
+	u8 *config_data = kmalloc(17, GFP_KERNEL);
 	u32 if_num = interface->altsetting->desc.bInterfaceNumber;
 	s32 result;
 
+	if (!config_data)
+		return -ENOMEM;
 	if (usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0),
 			    0x86, 0xC0, 0, 0, config_data, 17,
 			    USB_CTRL_SET_TIMEOUT) != 0x11) {
+		kfree(config_data);
 		return -EIO;
 	}
 
@@ -2873,6 +2876,7 @@ static int hso_get_config_data(struct usb_interface *interface)
 	if (config_data[16] & 0x1)
 		result |= HSO_INFO_CRC_BUG;
 
+	kfree(config_data);
 	return result;
 }
 
@@ -2886,6 +2890,11 @@ static int hso_probe(struct usb_interface *interface,
 	struct hso_shared_int *shared_int;
 	struct hso_device *tmp_dev = NULL;
 
+	if (interface->cur_altsetting->desc.bInterfaceClass != 0xFF) {
+		dev_err(&interface->dev, "Not our interface\n");
+		return -ENODEV;
+	}
+
 	if_num = interface->altsetting->desc.bInterfaceNumber;
 
 	/* Get the interface/port specification from either driver_info or from
@@ -2895,10 +2904,6 @@ static int hso_probe(struct usb_interface *interface,
 	else
 		port_spec = hso_get_config_data(interface);
 
-	if (interface->cur_altsetting->desc.bInterfaceClass != 0xFF) {
-		dev_err(&interface->dev, "Not our interface\n");
-		return -ENODEV;
-	}
 	/* Check if we need to switch to alt interfaces prior to port
 	 * configuration */
 	if (interface->num_altsetting > 1)
-- 
1.7.9.5

Re: [PATCH] Fix stack corruption on some architectures

[Greg Kroah-Hartman]

On Mon, Aug 19, 2013 at 01:37:27PM -0700, Daniel Gimpelevich wrote:
> There is no need to get an interface specification if we know it's the
> wrong one; trivial change. The big thing, though, was explained in the
> #mipslinux IRC channel: 
> [Mon 2013-08-19 12:28:21 PM PDT] <headless> guys, are you sure it's not "DMA off stack" case?
> [Mon 2013-08-19 12:28:35 PM PDT] <headless> it's a known stack corruptor on non-coherent arches
> [Mon 2013-08-19 12:31:48 PM PDT] <DonkeyHotei> headless: for usb/ehci?
> [Mon 2013-08-19 12:34:11 PM PDT] <DonkeyHotei> headless: explain
> [Mon 2013-08-19 12:35:38 PM PDT] <headless> usb_control_msg() (or other such func) should not use buffer on stack. DMA from/to stack is prohibited
> [Mon 2013-08-19 12:35:58 PM PDT] <headless> and EHCI uses DMA on control xfers (as well as all the others)
> 
> Signed-off-by: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>


Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH] Fix stack corruption on some architectures

[Sergei Shtylyov]

Hello.

On 08/20/2013 12:37 AM, Daniel Gimpelevich wrote:

> There is no need to get an interface specification if we know it's the
> wrong one; trivial change.

    Is it related to stack corruption? If not, it's asking to be in a separate 
patch.

> The big thing, though, was explained in the
> #mipslinux IRC channel:
> [Mon 2013-08-19 12:28:21 PM PDT] <headless> guys, are you sure it's not "DMA off stack" case?
> [Mon 2013-08-19 12:28:35 PM PDT] <headless> it's a known stack corruptor on non-coherent arches
> [Mon 2013-08-19 12:31:48 PM PDT] <DonkeyHotei> headless: for usb/ehci?
> [Mon 2013-08-19 12:34:11 PM PDT] <DonkeyHotei> headless: explain
> [Mon 2013-08-19 12:35:38 PM PDT] <headless> usb_control_msg() (or other such func) should not use buffer on stack. DMA from/to stack is prohibited
> [Mon 2013-08-19 12:35:58 PM PDT] <headless> and EHCI uses DMA on control xfers (as well as all the others)

    That headless was me. :-)

> Signed-off-by: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>

WBR, Sergei

Re: [PATCH] Fix stack corruption on some architectures

[Daniel Gimpelevich]

On Tue, 2013-08-20 at 02:31 +0400, Sergei Shtylyov wrote: 
> Hello.
> 
> On 08/20/2013 12:37 AM, Daniel Gimpelevich wrote:
> 
> > There is no need to get an interface specification if we know it's the
> > wrong one; trivial change.
> 
>     Is it related to stack corruption? If not, it's asking to be in a separate 
> patch.

Perhaps, but I'll leave that up to the maintainer(s). You should be
credited as co-author of the patch.

Re: [PATCH] Fix stack corruption on some architectures

[David Miller]

Please submit this with a more appropriate subject line.

After '[PATCH] ' there should be a subsystem or driver name
prefix, followed up a semicolon.  Here it could be "hso: ",
so something like:

[PATCH] hso: Fix stack corruption on some architectures.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fix stack corruption on some architectures

[Daniel Gimpelevich]

On Tue, 2013-08-20 at 23:29 -0700, David Miller wrote: 
> Please submit this with a more appropriate subject line.
> 
> After '[PATCH] ' there should be a subsystem or driver name
> prefix, followed up a semicolon.  Here it could be "hso: ",
> so something like:
> 
> [PATCH] hso: Fix stack corruption on some architectures.

Resent.