linux-kernel - Re: USB transfer_buffer allocations on 64bit systems

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 14 Apr 2010 18:21:05 +0100
From:	Pedro Ribeiro <pedrib@...il.com>
To:	Daniel Mack <daniel@...aq.de>
Cc:	Alan Stern <stern@...land.harvard.edu>, linux-usb@...r.kernel.org,
	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, Greg KH <gregkh@...e.de>,
	alsa-devel@...a-project.org
Subject: Re: USB transfer_buffer allocations on 64bit systems

On 14 April 2010 17:36, Daniel Mack <daniel@...aq.de> wrote:
> On Wed, Apr 14, 2010 at 10:08:47AM -0400, Alan Stern wrote:
>> On Wed, 14 Apr 2010, Pedro Ribeiro wrote:
>> > On 14 April 2010 11:09, Daniel Mack <daniel@...aq.de> wrote:
>> > > Thanks! So the only thing I can do for now is submit exactly this patch.
>> > > At least, it helps you and it shouldn't break anything. The question
>> > > remains whether this type of memory should be used for all
>> > > transfer_buffers.
>> > >
>> >
>> > Is there any chance you could push this to -stable? I don't care
>> > because I always use the latest kernel, but the next Debian stable and
>> > Ubuntu LTS are going to use 2.6.32.
>>
>> No!  Please don't do it: Don't submit the patch and _certainly_ don't
>> submit it to -stable.  It doesn't fix anything; it only works around a
>> bug, and at the moment we don't even know if the bug is in the kernel
>> or in Pedro's hardware (and even though it affects two different
>> systems of his, nobody else has reported a similar problem).  Papering
>> over it will only remove the incentive to fix it properly.
>
> No worries - I agree. But unfortunately, I'm out of ideas now, and my
> initial thoughts about what might cause the trouble were abviously not
> able to explain the issue. Does anyone see further steps of tracking
> this issue down?
>
> Thanks,
> Daniel
>

Well if this is a dirty / dangerous hack, what about your first patch?
I've been testing it for days and has given me no problems.

The best way to trigger the issue is to connect a dib0700 based DVB
adapter. All you need is to connect it. Since it polls for the remote
control every 50 msec, it causes a constant interference. Beware that
on 2.6.34 this behaviour has been corrected. Other DVB adapters may
trigger the same issue if they also poll constatly for the rc.

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