linux-kernel - Re: [PATCH v2] usb: dwc3: core: Prevent USB core invalid event buffer address access

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]

Message-ID: <8526e46f-30f2-4f24-8874-624b66aa54b1@samsung.com>
Date: Thu, 15 Aug 2024 10:19:38 +0530
From: Selvarasu Ganesan <selvarasu.g@...sung.com>
To: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
Cc: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jh0801.jung@...sung.com" <jh0801.jung@...sung.com>, "dh10.jung@...sung.com"
	<dh10.jung@...sung.com>, "naushad@...sung.com" <naushad@...sung.com>,
	"akash.m5@...sung.com" <akash.m5@...sung.com>, "rc93.raju@...sung.com"
	<rc93.raju@...sung.com>, "taehyun.cho@...sung.com"
	<taehyun.cho@...sung.com>, "hongpooh.kim@...sung.com"
	<hongpooh.kim@...sung.com>, "eomji.oh@...sung.com" <eomji.oh@...sung.com>,
	"shijie.cai@...sung.com" <shijie.cai@...sung.com>, "stable@...r.kernel.org"
	<stable@...r.kernel.org>
Subject: Re: [PATCH v2] usb: dwc3: core: Prevent USB core invalid event
 buffer address access


On 8/15/2024 5:34 AM, Thinh Nguyen wrote:
> On Wed, Aug 14, 2024, Selvarasu Ganesan wrote:
>> On 8/14/2024 4:47 AM, Thinh Nguyen wrote:
>>> On Sat, Aug 10, 2024, Selvarasu Ganesan wrote:
>>>> On 8/10/2024 4:58 AM, Thinh Nguyen wrote:
>>>>> On Thu, Aug 08, 2024, Selvarasu Ganesan wrote:
>>>>>> This commit addresses an issue where the USB core could access an
>>>>>> invalid event buffer address during runtime suspend, potentially causing
>>>>>> SMMU faults and other memory issues. The problem arises from the
>>>>>> following sequence.
>>>>>>            1. In dwc3_gadget_suspend, there is a chance of a timeout when
>>>>>>            moving the USB core to the halt state after clearing the
>>>>>>            run/stop bit by software.
>>>>>>            2. In dwc3_core_exit, the event buffer is cleared regardless of
>>>>>>            the USB core's status, which may lead to an SMMU faults and
>>>>> This is a workaround to your specific setup behavior. Please document in
>>>>> the commit message which platforms are impacted.
>>>> Please correct me if i am wrong. I dont think this workaround only
>>>> applicable our specific setup. It could be a common issue across all
>>>> other vendor platforms, and it's required to must check the controller
>>>> status before clear the event buffers address.  What you think is it
>>>> really required to mention the platform details in commit message?
>>> How can it be a common issue, the suspend sequence hasn't completed in
>>> the dwc3 driver but yet the buffer is no longer accessible? Also, as you
>>> noted, we don't know the exact condition for the SMMU fault, and this
>>> isn't reproducible all the time.
>> Agree. Will update platform detail in next version.
>>>>>>            other memory issues. if the USB core tries to access the event
>>>>>>            buffer address.
>>>>>>
>>>>>> To prevent this issue, this commit ensures that the event buffer address
>>>>>> is not cleared by software  when the USB core is active during runtime
>>>>>> suspend by checking its status before clearing the buffer address.
>>>>>>
>>>>>> Cc: stable@...r.kernel.org
>>>>> We can keep the stable tag, but there's no issue with the commit below.
>>>> By mistaken I mentioned wrong commit ID. The correct commit id would be
>>>> 660e9bde74d69 ("usb: dwc3: remove num_event_buffers").
>>> The above commit isn't the issue either. If it is, then the problem
>>> should still exist prior to that.
>>
>> This issue still persists in older kernels (6.1.X) as well. We believed
>> that it could be a common issue due to the missing condition for
>> checking the controller status in the mentioned commit above. We require
>> this fix in all stable kernel for the Exynos platform. Is it fine to
>> only mention the "Cc" tag in this case?
> You can just Cc stable and indicate how far you want this to be
> backported. Make sure to note that this change resolves a hardware
> quirk.
>
> e.g.
> Cc: stable <stable@...nel.org> # 6.1.x

Sure. Thanks for the confirmation.
>
> BR,
> Thinh