usb: mtu3: fix NULL pointer dereference

Some pointers are dereferenced before successful checks.

Reported-by: Markus Elfring <redacted>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
v2: nothing changed, but abandon another patch
---
 drivers/usb/mtu3/mtu3_gadget.c | 25 ++++++++++++++++++-------
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3_gadget.c b/drivers/usb/mtu3/mtu3_gadget.c
index f93732e..1689ca8 100644
--- a/drivers/usb/mtu3/mtu3_gadget.c
+++ b/drivers/usb/mtu3/mtu3_gadget.c

@@ -332,14 +332,21 @@ static int mtu3_gadget_queue(struct usb_ep *ep,
 
 static int mtu3_gadget_dequeue(struct usb_ep *ep, struct usb_request *req)
 {
-	struct mtu3_ep *mep = to_mtu3_ep(ep);
-	struct mtu3_request *mreq = to_mtu3_request(req);
+	struct mtu3_ep *mep;
+	struct mtu3_request *mreq;
 	struct mtu3_request *r;
+	struct mtu3 *mtu;
 	unsigned long flags;
 	int ret = 0;
-	struct mtu3 *mtu = mep->mtu;
 
-	if (!ep || !req || mreq->mep != mep)
+	if (!ep || !req)
+		return -EINVAL;
+
+	mep = to_mtu3_ep(ep);
+	mtu = mep->mtu;
+
+	mreq = to_mtu3_request(req);
+	if (mreq->mep != mep)
 		return -EINVAL;
 
 	dev_dbg(mtu->dev, "%s : req=%p\n", __func__, req);

@@ -373,8 +380,8 @@ static int mtu3_gadget_dequeue(struct usb_ep *ep, struct usb_request *req)
  */
 static int mtu3_gadget_ep_set_halt(struct usb_ep *ep, int value)
 {
-	struct mtu3_ep *mep = to_mtu3_ep(ep);
-	struct mtu3 *mtu = mep->mtu;
+	struct mtu3_ep *mep;
+	struct mtu3 *mtu;
 	struct mtu3_request *mreq;
 	unsigned long flags;
 	int ret = 0;

@@ -382,6 +389,9 @@ static int mtu3_gadget_ep_set_halt(struct usb_ep *ep, int value)
 	if (!ep)
 		return -EINVAL;
 
+	mep = to_mtu3_ep(ep);
+	mtu = mep->mtu;
+
 	dev_dbg(mtu->dev, "%s : %s...", __func__, ep->name);
 
 	spin_lock_irqsave(&mtu->lock, flags);

@@ -422,11 +432,12 @@ static int mtu3_gadget_ep_set_halt(struct usb_ep *ep, int value)
 /* Sets the halt feature with the clear requests ignored */
 static int mtu3_gadget_ep_set_wedge(struct usb_ep *ep)
 {
-	struct mtu3_ep *mep = to_mtu3_ep(ep);
+	struct mtu3_ep *mep;
 
 	if (!ep)
 		return -EINVAL;
 
+	mep = to_mtu3_ep(ep);
 	mep->wedged = 1;
 
 	return usb_ep_set_halt(ep);

-- 
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Some pointers are dereferenced before successful checks.

I propose to reconsider and improve also this change description.

* Would a null pointer dereference be possible only with the variables “mep”
  and “mreq” in the implementation of the function “mtu3_gadget_dequeue”?
  (Can it make sense to split the patch according to this detail?)

* How do you think about to convert any more variable initialisations
  to later assignments?

* Will it become helpful to add the tag “Fixes” to the commit message?


…

---
v2: nothing changed, but abandon another patch

Are there chances to take any previous patch review comments better into account
(besides the shown reduction of update steps)?

---
 drivers/usb/mtu3/mtu3_gadget.c | 25 ++++++++++++++++++-------

I suggest to replace the triple dashes before this diffstat by a blank line.

Regards,
Markus

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

On Tue, Jun 30, 2020 at 03:42:22PM +0800, Chunfeng Yun wrote:

How will either of those ever be NULL?  The kernel will not call this
function with either of them being NULL, right?

Same here, how can that ever happen?

Again, same here.

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

On Wed, 2020-07-01 at 13:58 +0200, Greg Kroah-Hartman wrote:

On Tue, Jun 30, 2020 at 03:42:22PM +0800, Chunfeng Yun wrote:

quoted

Some pointers are dereferenced before successful checks.

Reported-by: Markus Elfring <redacted>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
v2: nothing changed, but abandon another patch
---
 drivers/usb/mtu3/mtu3_gadget.c | 25 ++++++++++++++++++-------
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3_gadget.c b/drivers/usb/mtu3/mtu3_gadget.c
index f93732e..1689ca8 100644
--- a/drivers/usb/mtu3/mtu3_gadget.c
+++ b/drivers/usb/mtu3/mtu3_gadget.c

@@ -332,14 +332,21 @@ static int mtu3_gadget_queue(struct usb_ep *ep,
 
 static int mtu3_gadget_dequeue(struct usb_ep *ep, struct usb_request *req)
 {
-	struct mtu3_ep *mep = to_mtu3_ep(ep);
-	struct mtu3_request *mreq = to_mtu3_request(req);
+	struct mtu3_ep *mep;
+	struct mtu3_request *mreq;
 	struct mtu3_request *r;
+	struct mtu3 *mtu;
 	unsigned long flags;
 	int ret = 0;
-	struct mtu3 *mtu = mep->mtu;
 
-	if (!ep || !req || mreq->mep != mep)
+	if (!ep || !req)
+		return -EINVAL;

How will either of those ever be NULL?  The kernel will not call this
function with either of them being NULL, right?

Yes, I find all class drivers already ensure they are not NULL.

quoted

+
+	mep = to_mtu3_ep(ep);
+	mtu = mep->mtu;
+
+	mreq = to_mtu3_request(req);
+	if (mreq->mep != mep)
 		return -EINVAL;
 
 	dev_dbg(mtu->dev, "%s : req=%p\n", __func__, req);

@@ -373,8 +380,8 @@ static int mtu3_gadget_dequeue(struct usb_ep *ep, struct usb_request *req)
  */
 static int mtu3_gadget_ep_set_halt(struct usb_ep *ep, int value)
 {
-	struct mtu3_ep *mep = to_mtu3_ep(ep);
-	struct mtu3 *mtu = mep->mtu;
+	struct mtu3_ep *mep;
+	struct mtu3 *mtu;
 	struct mtu3_request *mreq;
 	unsigned long flags;
 	int ret = 0;

@@ -382,6 +389,9 @@ static int mtu3_gadget_ep_set_halt(struct usb_ep *ep, int value)
 	if (!ep)
 		return -EINVAL;

Same here, how can that ever happen?

Maybe when the class driver has something wrong:)

You mean it's better to remove these unnecessary checks?

Thanks

quoted

 
+	mep = to_mtu3_ep(ep);
+	mtu = mep->mtu;
+
 	dev_dbg(mtu->dev, "%s : %s...", __func__, ep->name);
 
 	spin_lock_irqsave(&mtu->lock, flags);

@@ -422,11 +432,12 @@ static int mtu3_gadget_ep_set_halt(struct usb_ep *ep, int value)
 /* Sets the halt feature with the clear requests ignored */
 static int mtu3_gadget_ep_set_wedge(struct usb_ep *ep)
 {
-	struct mtu3_ep *mep = to_mtu3_ep(ep);
+	struct mtu3_ep *mep;
 
 	if (!ep)
 		return -EINVAL;

Again, same here.

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Chunfeng Yun [off-list ref] writes:

Some pointers are dereferenced before successful checks.

Reported-by: Markus Elfring <redacted>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>

do you need a Fixes tag here? Perhaps a Cc stable too?

-- 
balbi

Hi,

Chunfeng Yun [off-list ref] writes:

quoted

quoted

@@ -373,8 +380,8 @@ static int mtu3_gadget_dequeue(struct usb_ep *ep, struct usb_request *req)
  */
 static int mtu3_gadget_ep_set_halt(struct usb_ep *ep, int value)
 {
-	struct mtu3_ep *mep = to_mtu3_ep(ep);
-	struct mtu3 *mtu = mep->mtu;
+	struct mtu3_ep *mep;
+	struct mtu3 *mtu;
 	struct mtu3_request *mreq;
 	unsigned long flags;
 	int ret = 0;

@@ -382,6 +389,9 @@ static int mtu3_gadget_ep_set_halt(struct usb_ep *ep, int value)
 	if (!ep)
 		return -EINVAL;

Same here, how can that ever happen?

Maybe when the class driver has something wrong:)

You mean it's better to remove these unnecessary checks?

if we need those checks, I'd rather have them at a central location,
such as udc/core.c. But, as Greg mentioned, the kernel doesn't call
these with NULL pointers.

-- 
balbi

On Thu, 2020-07-09 at 09:40 +0300, Felipe Balbi wrote:

Chunfeng Yun [off-list ref] writes:

quoted

Some pointers are dereferenced before successful checks.

Reported-by: Markus Elfring <redacted>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>

do you need a Fixes tag here? Perhaps a Cc stable too?

It will not cause somes issues, I think no need add it.

According to Greg's comment, I guess he means no need check these
pointers at all, so I'll send a new version to remove checks.

Thank you

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel