Received-SPF: pass (google.com: domain of linux-kernel+bounces-143182-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Fri, 12 Apr 2024 14:11:49 -0400
From: Alan Stern <stern@rowland.harvard.edu>
To: Sam Sun <samsun1006219@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
  Greg KH <gregkh@linuxfoundation.org>, swboyd@chromium.org,
  ricardo@marliere.net, hkallweit1@gmail.com, heikki.krogerus@linux.intel.com,
  mathias.nyman@linux.intel.com, royluo@google.com,
  syzkaller-bugs@googlegroups.com, xrivendell7@gmail.com
Subject: Re: [Linux kernel bug] general protection fault in disable_store
Message-ID: <69a6f4c9-6470-40d1-99f1-aaf532497d02@rowland.harvard.edu>
References: <CAEkJfYON+ry7xPx=AiLR9jzUNT+i_Va68ACajOC3HoacOfL1ig@mail.gmail.com>
 <92fe8e95-bc01-4d7d-9678-8cfc55cc4a7b@rowland.harvard.edu>
 <CAEkJfYORHKO16xT3DCS04JFzkquz6oZ5CdC2USJ5-c0WihAMXg@mail.gmail.com>
 <45e246ab-01e8-40b7-8ede-b47957df0d7b@rowland.harvard.edu>
 <CAEkJfYMjO+vMBGPcaLa51gjeKxFAJBrSa0t_iJUtauQD3DaK8w@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAEkJfYMjO+vMBGPcaLa51gjeKxFAJBrSa0t_iJUtauQD3DaK8w@mail.gmail.com>

On Sat, Apr 13, 2024 at 12:26:07AM +0800, Sam Sun wrote:
> On Fri, Apr 12, 2024 at 10:40 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> > I suspect the usb_hub_to_struct_hub() call is racing with the
> > spinlock-protected region in hub_disconnect() (in hub.c).
> >
> > > If there is any other thing I could help, please let me know.
> >
> > Try the patch below.  It should eliminate that race, which hopefully
> > will fix the problem.

> I applied this patch and tried to execute several times, no more
> kernel core dump in my environment. I think this bug is fixed by the
> patch. But I do have one more question about it. Since it is a data
> race bug, it has reproducibility issues originally. How can I confirm
> if a racy bug is fixed by test? This kind of bug might still have a
> race window but is harder to trigger. Just curious, not for this
> patch. I think this patch eliminates the racy window.

If you don't what what is racing, then testing cannot prove that a race 
is eliminated.  However, if you do know where a race occurs then it's 
easy to see how mutual exclusion can prevent the race from happening.

In this case the bug might have had a different cause, something other 
than a race between usb_hub_to_struct_hub() and hub_disconnect().  If 
that's so then testing this patch would not be a definite proof that the 
bug is gone.  But if that race _is_ the cause of the bug then this patch 
will fix it -- you can see that just by reading the code with no need 
for testing.

Besides, the patch is needed in any case because that race certainly 
_can_ occur.  And maybe not only on this pathway.

May I add your "Reported-and-tested-by:" to the patch?

Alan Stern