linux-kernel - Re: [PATCH] option: Do not try to bind to ADB interfaces

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:   Mon, 23 Jul 2018 18:37:31 +0200
From:   Romain Izard <romain.izard.pro@...il.com>
To:     Lars Melin <larsm17@...il.com>
Cc:     Johan Hovold <johan@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>
Subject: Re: [PATCH] option: Do not try to bind to ADB interfaces

2018-07-23 17:15 GMT+02:00 Lars Melin <larsm17@...il.com>:
> On 7/23/2018 21:02, Romain Izard wrote:
>>
>> Some modems now use the Android Debug Bridge to provide a debugging
>> interface, and some phones can also export serial ports managed by the
>> "option" driver.
>>
>> The ADB daemon running in userspace tries to use USB interfaces with
>> bDeviceClass=0xFF, bDeviceSubClass=0x42, bDeviceProtocol=1
>>
>> Prevent the option driver from binding to those interfaces, as they
>> will not be serial ports.
>
>
> You are assuming that an interface with these attributes are always a
> ADB interface - that is wrong. Vendor specific class (0xff) is not
> standardized to be something specific.

Yes. And the option driver binds to all the vendor-specific interfaces for many
devices, assuming all the vendor-specific interfaces are serial ports, unless
they are blacklisted.

>
>> This can fix issues like:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781256
>>
>
> You are trying to solve a 4++ years old bug report where it was assumed that
> the option driver was the culprit. The device in question, a Qualcomm modem
> with vid/pid 05c6:9025 has never been included in option.

While I'm not going to investigate why the 3.16 kernel did it, in the bug
report the logs indicated that 05c6:9025 was bound to the option driver. But I
did not try to solve this issue directly, I reported it as it led me to the
solution for a similar problem that I encountered last week.

A vendor for an SDK based on a modem was using an old Ubuntu 16.04, and
everything was working correctly. But on my 18.04, and on an up-to-date 16.04
LTS, it was impossible to use ADB with the vendor's SDK.

As ADB has many other failure modes, it took a lot of time to see the source of
the problem. The option driver in the old Ubuntu did not know about the modem's
vid/pid, so the driver was not bound by default and the ADB interface was free.
But the modem was added in the stable branch of the kernel, so the driver was
greedily binding to all interfaces that were not blacklisted. As a result, it
was not possible to use ADB as long as the interface was bound to the option
driver.

One of the reasons for the problem, of course, was the reuse by the modem
manufacturer of the same vid/pid for the standard version of the modem and for
the SDK version.

I see my change as a useful heuristic. ADB is a quite common protocol, using
one of the 65536 vendor subclass/protocol combinations. As you can see in
https://github.com/apkudo/adbusbini more than 3000 vendors have been spotted
using it in the wild, including more than half of those mentioned in the option
driver.

And on the other hand, I don't expect any existing modem to use 0xff,0x42,0x01
for its serial port interface, and a USB facedancer would not gain anything by
doing so.

Best regards,
-- 
Romain Izard