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

Date: Mon, 15 Apr 2024 10:42:41 +0200
From: Oliver Neukum <oneukum@...e.com>
To: Aleksander Morgado <aleksandermj@...omium.org>, 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



On 15.04.24 07:42, Aleksander Morgado wrote:

Hi,

> We are not aware of all the details involved in this patch,

I had gotten bug reports about resubmitting an active URB.

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

That is odd.

> Attached is an example output of mbimcli talking directly to the cdc-wdm port (i.e. without ModemManager or the mbim-proxy).

Could you provide a working example, that is with another chipset? And, most important, dmesg for both cases with
the log level set to maximum?

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

It looks like you are hitting the race later than my bug reporters, which means
that the submission works and we do not overwrite the buffer.
  
> 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.

Generally losing data is bad, so I cannot readily tell.
Please provide data for the working case.

	Regards
		Oliver