linux-kernel - Re: [PATCH] usb: cdc-wdm: close race between read and workqueue

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-next>] [day] [month] [year] [list]

Message-ID: <385a3519-b45d-48c5-a6fd-a3fdb6bec92f@chromium.org>
Date: Mon, 15 Apr 2024 05:42:06 +0000
From: Aleksander Morgado <aleksandermj@...omium.org>
To: oneukum@...e.com, bjorn@...k.no
Cc: linux-usb@...r.kernel.org, gregkh@...uxfoundation.org,
 linux@...ck-us.net, linux-kernel@...r.kernel.org, ejcaruso@...omium.org
Subject: Re: [PATCH] usb: cdc-wdm: close race between read and workqueue

Hey Oliver & Bjørn,

On 3/14/24 11:50, Oliver Neukum wrote:
> wdm_read() cannot race with itself. However, in
> service_outstanding_interrupt() it can race with the
> workqueue, which can be triggered by error handling.
> 
> Hence we need to make sure that the WDM_RESPONDING
> flag is not just only set but tested.
> 
> Fixes: afba937e540c9 ("USB: CDC WDM driver")
> Signed-off-by: Oliver Neukum <oneukum@...e.com>

We are not aware of all the details involved in this patch, but we had 
to revert it in all the different ChromeOS kernel versions where we had 
it cherry-picked, because it broke the MBIM communication with the Intel 
XMM based Fibocomm L850 modem. Other modems shipped in Chromebooks like 
the QC based Fibocomm FM101 don't seem to be affected.

Attached is an example output of mbimcli talking directly to the cdc-wdm 
port (i.e. without ModemManager or the mbim-proxy). In the example, we 
are receiving a bunch of different messages from previous mbimcli runs. 
Looking at the timestamps, it looks as if we only receive a message 
right after we have sent one, e.g. after each "open request" we end up 
receiving responses for requests sent in earlier runs; or something 
along those lines.

Is this bad behavior of this specific modem chipset, and if so, how can 
we workaround it? If you need any additional information or help to test 
new patches, let us know.

Cheers!

-- 
Aleksander

View attachment "cdc-wdm-errors.txt" of type "text/plain" (15253 bytes)

Download attachment "OpenPGP_0xAECE0239C6606AD5.asc" of type "application/pgp-keys" (3140 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (841 bytes)