Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220823182758.13401-1-khalid.masum.92@gmail.com>
 <20220823182758.13401-2-khalid.masum.92@gmail.com> <YwU2vp0FSR5dS/FX@rowland.harvard.edu>
 <CAABMjtH7q2evZ4R7FGC8m3a716ec9+e8+KdmrvnqB4_r6rF2Jg@mail.gmail.com> <YwY3yHB/Ia+cPa1L@rowland.harvard.edu>
In-Reply-To: <YwY3yHB/Ia+cPa1L@rowland.harvard.edu>
From:   Khalid Masum <khalid.masum.92@gmail.com>
Date:   Thu, 25 Aug 2022 00:07:21 +0600
Message-ID: <CAABMjtE96E78YgVe3Psba-5G+ELTXWFgGuUWWeb-o06iJHOi6w@mail.gmail.com>
Subject: Re: [PATCH 1/2] usb: ehci: Prevent possible modulo by zero
To:     Alan Stern <stern@rowland.harvard.edu>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-usb@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

> The usb_maxpacket() routine does a two-step computation.  First, it
> looks up the endpoint number in the pipe to get a usb_host_endpoint
> pointer, and then it uses the pointer to get the maxpacket value.
> Coverity complained that the lookup in the first step can fail, and that
> is in fact true: If there is an interface or configuration change before
> usb_maxpacket() is called, the endpoint number table can change and the
> lookup may fail.
>
> But it turns out the first step isn't needed here at all, since the
> endpoint pointer is already stored in the URB (by the code in

That makes sense. Thanks for explaining.
> usb_submit_urb() that I pointed out earlier).  So an appropriate way to
> fix the problem is to carry out just the second step:
>
> -       maxpacket = usb_maxpacket(urb->dev, urb->pipe);
> +       maxpacket = usb_endpoint_maxp(&urb->ep->desc);
>
> This holds for both of your patches.

Got you.
>
> Alan Stern

-- Khalid Masum