netdev - Re: [PATCH RESEND] dm9601: don't do usb transfers of data on stack

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, 11 Jul 2008 14:22:55 +0200
From:	Oliver Neukum <oliver@...kum.org>
To:	Peter Korsgaard <jacmet@...site.dk>
Cc:	jeff@...zik.org, netdev@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH RESEND] dm9601: don't do usb transfers of data on stack

Am Freitag 11 Juli 2008 14:17:58 schrieb Peter Korsgaard:
> >>>>> "Oliver" == Oliver Neukum <oliver@...kum.org> writes:
> 
>  >> dm_{read,write}_shared_word() were doing USB transfers of data on stack,
>  >> which isn't allowed. Fix it by using the usbnet->data area like in
>  >> dm9601_set_multicast().
> 
>  Oliver> You cannot do this. You've identified the bug correctly, but
>  Oliver> the fix is incorrect. Doing DMA on non coherent architectures
>  Oliver> means that any cacheline the buffer shares must not be
>  Oliver> touched while DMA may be running. If you embed the buffer
>  Oliver> into struct usbnet, how could you meet the guarantee?
> 
> Ahh. So kmalloc() / kfree() around the usb_control_msg isn dm_read /
> dm_write is the way to go?

The buffer should be allocated with kmalloc. That doesn't mean it has to
be allocated each time the function is called. If several drivers do this, the
best fix is to modify struct usbnet so that it contains only a pointer to the
buffer, not the buffer itself and modify drivers accordingly.

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