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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
