linux-kernel - Re: [PATCH 0/6] get rid of on-stack dma buffers

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:	Mon, 21 Mar 2011 15:26:43 -0400
From:	Andy Walls <awalls@...metrocast.net>
To:	Florian Mickler <florian@...kler.org>, mchehab@...radead.org
CC:	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	js@...uxtv.org, tskd2@...oo.co.jp, liplianin@...by,
	g.marco@...enet.de, aet@...terburn.org, pb@...uxtv.org,
	mkrufky@...uxtv.org, nick@...k-andrew.net, max@...eto.com,
	janne-dvb@...nau.be
Subject: Re: [PATCH 0/6] get rid of on-stack dma buffers

Florian Mickler <florian@...kler.org> wrote:

>Hi all!
>
>These patches get rid of on-stack dma buffers for some of the dvb-usb
>drivers. 
>I do not own the hardware, so these are only compile tested. I would 
>appreciate testing and review.
>They were previously sent to the list, but some error on my side
>prevented (some of?) them from beeing delivered to all parties (the
>lists).
>
>These changes are motivated by 
>https://bugzilla.kernel.org/show_bug.cgi?id=15977 .
>
>The patches which got tested already were submitted to Mauro (and
>lkml/linux-media) yesterday seperately. Those fix this same issue for
>ec168,
>ce6230, au6610 and lmedm04. 
>
>A fix for vp702x has been submitted seperately for review on the list.
>I have
>similiar fixes like the vp702x-fix for dib0700 (overlooked some
>on-stack
>buffers in there in my original submission as well) and gp8psk, but I
>am
>holding them back 'till I got time to recheck those and getting some
>feedback
>on vp702x.
>
>Please review and test.
>
>Regards,
>Flo
>
>Florian Mickler (6):
>  [media] a800: get rid of on-stack dma buffers
>  [media v2] vp7045: get rid of on-stack dma buffers
>  [media] friio: get rid of on-stack dma buffers
>  [media] dw2102: get rid of on-stack dma buffer
>  [media] m920x: get rid of on-stack dma buffers
>  [media] opera1: get rid of on-stack dma buffer
>
> drivers/media/dvb/dvb-usb/a800.c   |   17 ++++++++++---
> drivers/media/dvb/dvb-usb/dw2102.c |   10 ++++++-
> drivers/media/dvb/dvb-usb/friio.c  |   23 ++++++++++++++---
> drivers/media/dvb/dvb-usb/m920x.c  |   33 ++++++++++++++++--------
> drivers/media/dvb/dvb-usb/opera1.c |   31 +++++++++++++++--------
>drivers/media/dvb/dvb-usb/vp7045.c |   47
>++++++++++++++++++++++++++----------
> 6 files changed, 116 insertions(+), 45 deletions(-)
>
>-- 
>1.7.4.1
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media"
>in
>the body of a message to majordomo@...r.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Florian,

For all of these, what happens when the USB call times out and you kfree() the buffer?  Can the USB DMA actually complete after this kfree(), possibly corrupting space that has been reallocated off the heap, since the kfree()?

This is the scenario for which I assume allocating off the stack is bad.  

Do these changes simply make corruption less noticable since heap gets corrupted vs stack?

Regards,
Andy
--
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/