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:	Tue, 21 Feb 2012 17:24:24 -0500
From:	Jeff Garzik <jeff@...zik.org>
To:	Holger Macht <holger@...ac.de>
CC:	Hugh Dickins <hughd@...gle.com>, Hillf Danton <dhillf@...il.com>,
	Matthew Garrett <mjg@...hat.com>,
	Jeff Garzik <jgarzik@...hat.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: linux-next: dock_link_device is oopsy

On 02/18/2012 02:57 PM, Holger Macht wrote:
> On Sa 18. Feb - 10:46:04, Hugh Dickins wrote:
>> On Sat, 18 Feb 2012, Holger Macht wrote:
>>> How about that one?
>>
>> It's more broken than that.  Here's my attempt.  It boots on the
>> systems with dock_station_count 0, and it boots on my laptop with
>> dock_station_count 2; but I don't actually have any docking station,
>> so it still doesn't test very much (dock is 0 after the loop).
>
> Well, there doesn't have to actually exist a physical dock station (or
> bay device) for dock_station_count to be>  0. It just tells that the
> ACPI objects are present and thus the system is capable of it.
>
> So does this function actually also break on your laptop and you're
> getting the oops there, too?
>
>> I have no idea if what goes on in the loop is correct, but it looks
>> to me as if (as predicted) there's further breakage, that it would
>> have been writing beyond the end of what it allocated if I did have
>> a docking station.
>>
>> Hugh
>>
>> [PATCH] dock: fix bootup oops and other dock_link breakage
>>
>> dock_link_device() and dock_unlink_device() should bail out early
>> to avoid oops on zero-length kmalloc() when dock_station_count is 0.
>>
>> But isn't there an off-by-one in that kmalloc() length anyway?
>> An extra NULL appended at the end suggests so.
>>
>> Rework the ordering with gotos on failure to fix several issues.
>>
>> And presumably dock_unlink_device() should be presenting the same
>> interface as dock_link_device(), with NULL returned when none found.
>>
>> Signed-off-by: Hugh Dickins<hughd@...gle.com>
>
> Fine with me.

So, just to be clear, the preferred patch is Hugh's, and I should drop 
your earlier proposed fix found in this thread?

And what about that warning?

Need to fix up linux-next or temporarily drop this patchset from linux-next.

	Jeff




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