linux-kernel - Re: Regression caused by "Bluetooth: Map sec

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:	Thu, 9 Jun 2011 17:33:45 +0900
From:	Johan Hedberg <johan.hedberg@...il.com>
To:	Waldemar.Rymarkiewicz@...to.com
Cc:	keithp@...thp.com, padovan@...fusion.mobi, marcel@...tmann.org,
	linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Regression caused by "Bluetooth: Map sec_level to link key
 requirements"

Hi,

On Thu, Jun 09, 2011, Waldemar.Rymarkiewicz@...to.com wrote:
> >Patch 13d39315c22b128f4796fc008b04914a7c32bb1a is causing a 
> >regression From 2.6.39. I cannot communicate with my Nokia 
> >N900 using either the SyncML or DUN RFCOMM services.  I get a 
> >connection reset error shortly after startup.
> >
> >I've reverted this patch on top of something past -rc2 (to be 
> >precise, I'm branching from ef2398019b305827ea7130ebaf7bf521b444530e).
> >With the following fix-up to make things build again, my 
> >bluetooth works again.
> 
> Logs from kernel and bluez would be much appreciated to see what happend.
> As I remember this was pretty well tested with BITE test by Johan.

The patch was not only fine but actually *needed* by the BITE. So
reverting it will make some qualification tests fail.

There's no DUN support in the N900 by default and the only package I'm
aware that provides it uses the command line rfcomm tool with high
security on the socket to block just-works SSP pairing (since the rfcomm
tool doesn't use the authorization framework to guarantee a user pop-up
dialog). The SyncML code I can't comment on since I haven't seen it.

So potentially this might be limited to high security sockets.
Speculating further, if the device connecting to the N900 has a pre-2.1
Bluetooth controller this could simply be about not having a 16-digit
PIN which high security services require. So could whoever is able to
reproduce the issue try repairing and entering a 16-digit PIN to see if
the problem goes away? And if this is in fact the case then the kernel
code is working exactly as it should; the only issue is that these
services should really be using medium security level instead of high.

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