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-next>] [day] [month] [year] [list]
Message-ID: <496E43F4.24792.158F9B@ceggers.gmx.de>
Date:	Wed, 14 Jan 2009 19:58:44 +0100
From:	"Christian Eggers" <ceggers@....de>
To:	linux-kernel@...r.kernel.org
Subject: Buffer allocation for USB transfers

In different drivers I've found several methods for allocating buffers 
transfered with usb_control_msg() or usb_submit_urb():

- usb_stor_msg_common() in "drivers/usb/storage/transport.c" uses buffers 
allocated with usb_buffer_alloc(). These buffers are used with 
URB_NO_xxx_DMA_MAP in urb->transfer_flags.

- asix_read_cmd() in "drivers/net/usb/asix.c" uses kmalloc(GFP_KERNEL).

- mcs7830_get_reg() in "drivers/net/usb/mcs7830.c" uses buffers from 
the stack.

At least the latter does not work on my SH-4 platform. It seems that other 
variables on the stack are overwritten after calling usb_control_msg(), probably as 
result of incorrect alignment.

For some reason the second example (kmalloc()) doesn't seem to cause problems (on 
my platform) but is there are guarantee that kmalloc() 
without GFP_DMA does always return a DMA capable buffer?

Shall all buffers used for usb_control_msg() and usb_submit_urb() be 
allocated with usb_buffer_alloc()? It seems that usb_control_msg() doesn't 
offer a way to set the URB_NO_xxx_DMA_MAP in urb->transfer_flags so that 
usb_buffer_alloc() can not be used here???

regards
Christian Eggers

Please CC to ceggers@....de

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ