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: <20240815000352.squzue3q646bfmmx@synopsys.com>
Date: Thu, 15 Aug 2024 00:04:05 +0000
From: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To: Selvarasu Ganesan <selvarasu.g@...sung.com>
CC: Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        "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 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

BR,
Thinh