netdev - Re: tty_register_device NULL pointer dereference in 2.6.31-rc4

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]

Message-ID: <a8e1da0907300215q3934da47g3676648e3b247af8@mail.gmail.com>
Date:	Thu, 30 Jul 2009 17:15:21 +0800
From:	Dave Young <hidave.darkstar@...il.com>
To:	Oliver Hartkopp <oliver@...tkopp.net>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Marcel Holtmann <marcel@...tmann.org>,
	Linux Netdev List <netdev@...r.kernel.org>,
	linux-bluetooth@...r.kernel.org
Subject: Re: tty_register_device NULL pointer dereference in 2.6.31-rc4

On Wed, Jul 29, 2009 at 10:00 PM, Oliver Hartkopp<oliver@...tkopp.net> wrote:
> Dave Young wrote:
>> On Mon, Jul 27, 2009 at 01:39:03PM +0200, Oliver Hartkopp wrote:
>>> Oliver Hartkopp wrote:
>>>> Dave Young wrote:
>>>>> On Sat, Jul 25, 2009 at 01:10:46PM +0100, Alan Cox wrote:
>>>>>>>> tty_register_device appears to have been called with a NULL pointer. Not
>>>>>>>> sure why however.
>>>>>>> if that is the pointer for the struct device, then that used to be fine
>>>>>>> in the past. Not all RFCOMM device have a parent when they are created.
>>>>>> The tty layer doesn't care about the struct device really. Nothing there
>>>>>> has changed. The NULL passed appears to be the driver argument.
>>>>> Agree with you, because in rfcomm_init, rfcomm thread run before tty initilized, the following patch may fix the problem.
>>>>> oliver, could you verify it it fix your problem?
>>>> Hi Dave,
>>>>
>>>> i get this problem really seldom on my Laptop and i did not manage to get a
>>>> reproducible Oops of that problem.
>>>>
>>>> Anyway the code you are pointing to seems to have a problem and your added
>>>> error handling looks good to me - even if i don't know if the initializations
>>>> can be reordered in that way.
>>>>
>>>> I'll try your patch, but it could take a *long* time to prove it right ;-)
>>>>
>>> Just FYI:
>>>
>>> Your patch compiled, the system booted without problems and nothing is broken
>>> so far. I checked the BT, WLAN and BT dial-up with success. So it looks good
>>> to me.
>>
>> Thanks for the testing. Marcel, could you take a look?
>
> Hi Dave,
>
> i got it again - even with your patch (that's why it's 2.6.31-rc4-dirty in the
> attached screenshot).

Weird, the oops occurs between sock init and tty init routines. Could
you tell your bluez version and your configuration?

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