linux-kernel - Re: [V4.1] Regression: Bluetooth mouse not working.

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:	Fri, 17 Apr 2015 14:26:04 -0700
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jörg Otte <jrg.otte@...il.com>,
	"Gustavo F. Padovan" <gustavo@...ovan.org>,
	Johan Hedberg <johan.hedberg@...il.com>,
	"bluez mailin list (linux-bluetooth@...r.kernel.org)" 
	<linux-bluetooth@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [V4.1] Regression: Bluetooth mouse not working.

Hi Linus,

>> accepting all flags regardless was an oversight on my part in the first place. What this patch tried to do is to limit it to what userspace is currently actually using. My mistake was to look only at BlueZ 5.x userspace and not at BlueZ 4.x userspace.
> 
> So what about anybody else? Android doesn't use BlueZ, afaik. Any
> other direct accesses?

this interface is for bluetoothd (Bluetooth userspace daemon) since you need to do a lot of initial setup before you can hand this over to the kernel to drive HID. On Android this was never used. And even BlueZ for Android (replacement for Bluedroid) is not using it today either.

Google Fiber (their set-top boxes) actually moved this all over to /dev/uhid now since it gives them better re-connect experience for their remotes.

> If we already know that BlueZ 4.x did something else, what makes you
> so sure that this now covers all cases?

I am certain since nothing else than bluetoothd ever used this interface.

> The thing is, the bluetooth code has clearly never cared about these
> bits before. Is there any real reason to think that people haven't
> passed in garbage? Do we even know that those flags were *initialized*
> at all by user space in all use cases?
> 
> So I'm ok with trying to fix things up, but I have to say that if the
> fixed-up case also causes problems (because there was some other case
> that you didn't think of), I'm going to be pissed off, and I'm going
> to expect you to *jump* on it, and revert the whole thing.

The reason why I starting cleaning this up is because there is an overlay with internal and external flags mixed together. This is clearly a bug, but sadly that also can open up security issues since we clearly do not want userspace allowing messing with internal flags. That is actually worse.

My viewpoint is the reverting the whole patch is actually not helping here either. So either we take the patch that I just send around to fix the breakage that I caused with BlueZ 4.x userspace. Or an as alternative we keep allowing userspace to provide whatever flags it wants, but clear all unknown ones before using them in the HIDP logic. My intent was to make this old code less vulnerable.

Is one of these options acceptable for you compared to reverting the whole patch?

Regards

Marcel

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