stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/1] usb: xhci: fix possible wild pointer
@ 2016-12-02  2:29 Lu Baolu
  2016-12-02  4:18 ` Baolin Wang
  2016-12-02 13:39 ` Mathias Nyman
  0 siblings, 2 replies; 6+ messages in thread
From: Lu Baolu @ 2016-12-02  2:29 UTC (permalink / raw)
  To: Mathias Nyman; +Cc: linux-usb, linux-kernel, Lu Baolu, stable

handle_cmd_completion() frees a command structure which might
be still referenced by xhci->current_cmd. This might cause
problem when xhci->current_cmd is accessed after that.

A real-life case could be like this. The host takes a very long
time to respond to a command, and the command timer is fired at
the same time when the command completion event arrives. The
command completion handler frees xhci->current_cmd before the
timer function can grab xhci->lock. Afterward, timer function
grabs the lock and go ahead with checking and setting members
of xhci->current_cmd.

Cc: <stable@vger.kernel.org> # v3.16+
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
---
 drivers/usb/host/xhci-ring.c | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index bdf6b13..13e05f6 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1267,14 +1267,16 @@ void xhci_handle_command_timeout(unsigned long data)
 	bool second_timeout = false;
 	xhci = (struct xhci_hcd *) data;
 
-	/* mark this command to be cancelled */
 	spin_lock_irqsave(&xhci->lock, flags);
-	if (xhci->current_cmd) {
-		if (xhci->current_cmd->status == COMP_CMD_ABORT)
-			second_timeout = true;
-		xhci->current_cmd->status = COMP_CMD_ABORT;
+	if (!xhci->current_cmd) {
+		spin_unlock_irqrestore(&xhci->lock, flags);
+		return;
 	}
 
+	if (xhci->current_cmd->status == COMP_CMD_ABORT)
+		second_timeout = true;
+	xhci->current_cmd->status = COMP_CMD_ABORT;
+
 	/* Make sure command ring is running before aborting it */
 	hw_ring_state = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
 	if ((xhci->cmd_ring_state & CMD_RING_STATE_RUNNING) &&
@@ -1422,6 +1424,10 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
 		xhci->current_cmd = list_entry(cmd->cmd_list.next,
 					       struct xhci_command, cmd_list);
 		mod_timer(&xhci->cmd_timer, jiffies + XHCI_CMD_DEFAULT_TIMEOUT);
+	} else if (xhci->current_cmd == cmd) {
+		xhci->current_cmd = NULL;
+	} else {
+		xhci_warn(xhci, "WARN current_cmd doesn't match command\n");
 	}
 
 event_handled:
-- 
2.1.4


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH 1/1] usb: xhci: fix possible wild pointer
  2016-12-02  2:29 [PATCH 1/1] usb: xhci: fix possible wild pointer Lu Baolu
@ 2016-12-02  4:18 ` Baolin Wang
  2016-12-02  4:40   ` Lu Baolu
  2016-12-02 13:39 ` Mathias Nyman
  1 sibling, 1 reply; 6+ messages in thread
From: Baolin Wang @ 2016-12-02  4:18 UTC (permalink / raw)
  To: Lu Baolu; +Cc: Mathias Nyman, USB, LKML, stable

On 2 December 2016 at 10:29, Lu Baolu <baolu.lu@linux.intel.com> wrote:
> handle_cmd_completion() frees a command structure which might
> be still referenced by xhci->current_cmd. This might cause
> problem when xhci->current_cmd is accessed after that.
>
> A real-life case could be like this. The host takes a very long
> time to respond to a command, and the command timer is fired at
> the same time when the command completion event arrives. The
> command completion handler frees xhci->current_cmd before the
> timer function can grab xhci->lock. Afterward, timer function
> grabs the lock and go ahead with checking and setting members
> of xhci->current_cmd.
>
> Cc: <stable@vger.kernel.org> # v3.16+
> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>

Nice catch. I was also curious where set xhci->current_cmd to be NULL
when current command is freed.
Tested-by: Baolin Wang <baolin.wang@linaro.org>

> ---
>  drivers/usb/host/xhci-ring.c | 16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index bdf6b13..13e05f6 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -1267,14 +1267,16 @@ void xhci_handle_command_timeout(unsigned long data)
>         bool second_timeout = false;
>         xhci = (struct xhci_hcd *) data;
>
> -       /* mark this command to be cancelled */
>         spin_lock_irqsave(&xhci->lock, flags);
> -       if (xhci->current_cmd) {
> -               if (xhci->current_cmd->status == COMP_CMD_ABORT)
> -                       second_timeout = true;
> -               xhci->current_cmd->status = COMP_CMD_ABORT;
> +       if (!xhci->current_cmd) {
> +               spin_unlock_irqrestore(&xhci->lock, flags);
> +               return;
>         }
>
> +       if (xhci->current_cmd->status == COMP_CMD_ABORT)
> +               second_timeout = true;
> +       xhci->current_cmd->status = COMP_CMD_ABORT;
> +
>         /* Make sure command ring is running before aborting it */
>         hw_ring_state = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
>         if ((xhci->cmd_ring_state & CMD_RING_STATE_RUNNING) &&
> @@ -1422,6 +1424,10 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
>                 xhci->current_cmd = list_entry(cmd->cmd_list.next,
>                                                struct xhci_command, cmd_list);
>                 mod_timer(&xhci->cmd_timer, jiffies + XHCI_CMD_DEFAULT_TIMEOUT);
> +       } else if (xhci->current_cmd == cmd) {
> +               xhci->current_cmd = NULL;
> +       } else {
> +               xhci_warn(xhci, "WARN current_cmd doesn't match command\n");
>         }
>
>  event_handled:
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Baolin.wang
Best Regards

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 1/1] usb: xhci: fix possible wild pointer
  2016-12-02  4:18 ` Baolin Wang
@ 2016-12-02  4:40   ` Lu Baolu
  2016-12-02  4:48     ` Baolin Wang
  0 siblings, 1 reply; 6+ messages in thread
From: Lu Baolu @ 2016-12-02  4:40 UTC (permalink / raw)
  To: Baolin Wang; +Cc: Mathias Nyman, USB, LKML, stable

Hi,

On 12/02/2016 12:18 PM, Baolin Wang wrote:
> On 2 December 2016 at 10:29, Lu Baolu <baolu.lu@linux.intel.com> wrote:
>> handle_cmd_completion() frees a command structure which might
>> be still referenced by xhci->current_cmd. This might cause
>> problem when xhci->current_cmd is accessed after that.
>>
>> A real-life case could be like this. The host takes a very long
>> time to respond to a command, and the command timer is fired at
>> the same time when the command completion event arrives. The
>> command completion handler frees xhci->current_cmd before the
>> timer function can grab xhci->lock. Afterward, timer function
>> grabs the lock and go ahead with checking and setting members
>> of xhci->current_cmd.
>>
>> Cc: <stable@vger.kernel.org> # v3.16+
>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
> Nice catch. I was also curious where set xhci->current_cmd to be NULL
> when current command is freed.

Below code does:

    xhci->current_cmd = list_entry(cmd->cmd_list.next,
                                               struct xhci_command, cmd_list);
                mod_timer(&xhci->cmd_timer, jiffies + XHCI_CMD_DEFAULT_TIMEOUT);
+       } else if (xhci->current_cmd == cmd) {
+               xhci->current_cmd = NULL;
+       } else {
+               xhci_warn(xhci, "WARN current_cmd doesn't match command\n");
        }


Best regards,
Lu Baolu

> Tested-by: Baolin Wang <baolin.wang@linaro.org>
>
>> ---
>>  drivers/usb/host/xhci-ring.c | 16 +++++++++++-----
>>  1 file changed, 11 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
>> index bdf6b13..13e05f6 100644
>> --- a/drivers/usb/host/xhci-ring.c
>> +++ b/drivers/usb/host/xhci-ring.c
>> @@ -1267,14 +1267,16 @@ void xhci_handle_command_timeout(unsigned long data)
>>         bool second_timeout = false;
>>         xhci = (struct xhci_hcd *) data;
>>
>> -       /* mark this command to be cancelled */
>>         spin_lock_irqsave(&xhci->lock, flags);
>> -       if (xhci->current_cmd) {
>> -               if (xhci->current_cmd->status == COMP_CMD_ABORT)
>> -                       second_timeout = true;
>> -               xhci->current_cmd->status = COMP_CMD_ABORT;
>> +       if (!xhci->current_cmd) {
>> +               spin_unlock_irqrestore(&xhci->lock, flags);
>> +               return;
>>         }
>>
>> +       if (xhci->current_cmd->status == COMP_CMD_ABORT)
>> +               second_timeout = true;
>> +       xhci->current_cmd->status = COMP_CMD_ABORT;
>> +
>>         /* Make sure command ring is running before aborting it */
>>         hw_ring_state = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
>>         if ((xhci->cmd_ring_state & CMD_RING_STATE_RUNNING) &&
>> @@ -1422,6 +1424,10 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
>>                 xhci->current_cmd = list_entry(cmd->cmd_list.next,
>>                                                struct xhci_command, cmd_list);
>>                 mod_timer(&xhci->cmd_timer, jiffies + XHCI_CMD_DEFAULT_TIMEOUT);
>> +       } else if (xhci->current_cmd == cmd) {
>> +               xhci->current_cmd = NULL;
>> +       } else {
>> +               xhci_warn(xhci, "WARN current_cmd doesn't match command\n");
>>         }
>>
>>  event_handled:
>> --
>> 2.1.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 1/1] usb: xhci: fix possible wild pointer
  2016-12-02  4:40   ` Lu Baolu
@ 2016-12-02  4:48     ` Baolin Wang
  0 siblings, 0 replies; 6+ messages in thread
From: Baolin Wang @ 2016-12-02  4:48 UTC (permalink / raw)
  To: Lu Baolu; +Cc: Mathias Nyman, USB, LKML, stable

On 2 December 2016 at 12:40, Lu Baolu <baolu.lu@linux.intel.com> wrote:
> Hi,
>
> On 12/02/2016 12:18 PM, Baolin Wang wrote:
>> On 2 December 2016 at 10:29, Lu Baolu <baolu.lu@linux.intel.com> wrote:
>>> handle_cmd_completion() frees a command structure which might
>>> be still referenced by xhci->current_cmd. This might cause
>>> problem when xhci->current_cmd is accessed after that.
>>>
>>> A real-life case could be like this. The host takes a very long
>>> time to respond to a command, and the command timer is fired at
>>> the same time when the command completion event arrives. The
>>> command completion handler frees xhci->current_cmd before the
>>> timer function can grab xhci->lock. Afterward, timer function
>>> grabs the lock and go ahead with checking and setting members
>>> of xhci->current_cmd.
>>>
>>> Cc: <stable@vger.kernel.org> # v3.16+
>>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>> Nice catch. I was also curious where set xhci->current_cmd to be NULL
>> when current command is freed.
>
> Below code does:

Yes, I just means you did that, but the original code did not. Sorry
for confusing.

>
>     xhci->current_cmd = list_entry(cmd->cmd_list.next,
>                                                struct xhci_command, cmd_list);
>                 mod_timer(&xhci->cmd_timer, jiffies + XHCI_CMD_DEFAULT_TIMEOUT);
> +       } else if (xhci->current_cmd == cmd) {
> +               xhci->current_cmd = NULL;
> +       } else {
> +               xhci_warn(xhci, "WARN current_cmd doesn't match command\n");
>         }
>
>
> Best regards,
> Lu Baolu
>
>> Tested-by: Baolin Wang <baolin.wang@linaro.org>
>>
>>> ---
>>>  drivers/usb/host/xhci-ring.c | 16 +++++++++++-----
>>>  1 file changed, 11 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
>>> index bdf6b13..13e05f6 100644
>>> --- a/drivers/usb/host/xhci-ring.c
>>> +++ b/drivers/usb/host/xhci-ring.c
>>> @@ -1267,14 +1267,16 @@ void xhci_handle_command_timeout(unsigned long data)
>>>         bool second_timeout = false;
>>>         xhci = (struct xhci_hcd *) data;
>>>
>>> -       /* mark this command to be cancelled */
>>>         spin_lock_irqsave(&xhci->lock, flags);
>>> -       if (xhci->current_cmd) {
>>> -               if (xhci->current_cmd->status == COMP_CMD_ABORT)
>>> -                       second_timeout = true;
>>> -               xhci->current_cmd->status = COMP_CMD_ABORT;
>>> +       if (!xhci->current_cmd) {
>>> +               spin_unlock_irqrestore(&xhci->lock, flags);
>>> +               return;
>>>         }
>>>
>>> +       if (xhci->current_cmd->status == COMP_CMD_ABORT)
>>> +               second_timeout = true;
>>> +       xhci->current_cmd->status = COMP_CMD_ABORT;
>>> +
>>>         /* Make sure command ring is running before aborting it */
>>>         hw_ring_state = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
>>>         if ((xhci->cmd_ring_state & CMD_RING_STATE_RUNNING) &&
>>> @@ -1422,6 +1424,10 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
>>>                 xhci->current_cmd = list_entry(cmd->cmd_list.next,
>>>                                                struct xhci_command, cmd_list);
>>>                 mod_timer(&xhci->cmd_timer, jiffies + XHCI_CMD_DEFAULT_TIMEOUT);
>>> +       } else if (xhci->current_cmd == cmd) {
>>> +               xhci->current_cmd = NULL;
>>> +       } else {
>>> +               xhci_warn(xhci, "WARN current_cmd doesn't match command\n");
>>>         }
>>>
>>>  event_handled:
>>> --
>>> 2.1.4
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>



-- 
Baolin.wang
Best Regards

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 1/1] usb: xhci: fix possible wild pointer
  2016-12-02  2:29 [PATCH 1/1] usb: xhci: fix possible wild pointer Lu Baolu
  2016-12-02  4:18 ` Baolin Wang
@ 2016-12-02 13:39 ` Mathias Nyman
  2016-12-05  9:07   ` Lu Baolu
  1 sibling, 1 reply; 6+ messages in thread
From: Mathias Nyman @ 2016-12-02 13:39 UTC (permalink / raw)
  To: Lu Baolu; +Cc: linux-usb, linux-kernel, stable

On 02.12.2016 04:29, Lu Baolu wrote:
> handle_cmd_completion() frees a command structure which might
> be still referenced by xhci->current_cmd. This might cause
> problem when xhci->current_cmd is accessed after that.
>
> A real-life case could be like this. The host takes a very long
> time to respond to a command, and the command timer is fired at
> the same time when the command completion event arrives. The
> command completion handler frees xhci->current_cmd before the
> timer function can grab xhci->lock. Afterward, timer function
> grabs the lock and go ahead with checking and setting members
> of xhci->current_cmd.
>
> Cc: <stable@vger.kernel.org> # v3.16+
> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
> ---
>   drivers/usb/host/xhci-ring.c | 16 +++++++++++-----
>   1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index bdf6b13..13e05f6 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -1267,14 +1267,16 @@ void xhci_handle_command_timeout(unsigned long data)
>   	bool second_timeout = false;
>   	xhci = (struct xhci_hcd *) data;
>
> -	/* mark this command to be cancelled */
>   	spin_lock_irqsave(&xhci->lock, flags);
> -	if (xhci->current_cmd) {
> -		if (xhci->current_cmd->status == COMP_CMD_ABORT)
> -			second_timeout = true;
> -		xhci->current_cmd->status = COMP_CMD_ABORT;
> +	if (!xhci->current_cmd) {
> +		spin_unlock_irqrestore(&xhci->lock, flags);
> +		return;
>   	}
>
> +	if (xhci->current_cmd->status == COMP_CMD_ABORT)
> +		second_timeout = true;
> +	xhci->current_cmd->status = COMP_CMD_ABORT;
> +
>   	/* Make sure command ring is running before aborting it */
>   	hw_ring_state = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
>   	if ((xhci->cmd_ring_state & CMD_RING_STATE_RUNNING) &&
> @@ -1422,6 +1424,10 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
>   		xhci->current_cmd = list_entry(cmd->cmd_list.next,
>   					       struct xhci_command, cmd_list);
>   		mod_timer(&xhci->cmd_timer, jiffies + XHCI_CMD_DEFAULT_TIMEOUT);
> +	} else if (xhci->current_cmd == cmd) {
> +		xhci->current_cmd = NULL;
> +	} else {
> +		xhci_warn(xhci, "WARN current_cmd doesn't match command\n");
>   	}
>
>   event_handled:
>

Thanks,

I might do some tweaking to (or remove)  the warn message when applying if
that is ok

-Mathias

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 1/1] usb: xhci: fix possible wild pointer
  2016-12-02 13:39 ` Mathias Nyman
@ 2016-12-05  9:07   ` Lu Baolu
  0 siblings, 0 replies; 6+ messages in thread
From: Lu Baolu @ 2016-12-05  9:07 UTC (permalink / raw)
  To: Mathias Nyman; +Cc: linux-usb, linux-kernel, stable

Hi,

On 12/02/2016 09:39 PM, Mathias Nyman wrote:
> On 02.12.2016 04:29, Lu Baolu wrote:
>> handle_cmd_completion() frees a command structure which might
>> be still referenced by xhci->current_cmd. This might cause
>> problem when xhci->current_cmd is accessed after that.
>>
>> A real-life case could be like this. The host takes a very long
>> time to respond to a command, and the command timer is fired at
>> the same time when the command completion event arrives. The
>> command completion handler frees xhci->current_cmd before the
>> timer function can grab xhci->lock. Afterward, timer function
>> grabs the lock and go ahead with checking and setting members
>> of xhci->current_cmd.
>>
>> Cc: <stable@vger.kernel.org> # v3.16+
>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>> ---
>>   drivers/usb/host/xhci-ring.c | 16 +++++++++++-----
>>   1 file changed, 11 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
>> index bdf6b13..13e05f6 100644
>> --- a/drivers/usb/host/xhci-ring.c
>> +++ b/drivers/usb/host/xhci-ring.c
>> @@ -1267,14 +1267,16 @@ void xhci_handle_command_timeout(unsigned long data)
>>       bool second_timeout = false;
>>       xhci = (struct xhci_hcd *) data;
>>
>> -    /* mark this command to be cancelled */
>>       spin_lock_irqsave(&xhci->lock, flags);
>> -    if (xhci->current_cmd) {
>> -        if (xhci->current_cmd->status == COMP_CMD_ABORT)
>> -            second_timeout = true;
>> -        xhci->current_cmd->status = COMP_CMD_ABORT;
>> +    if (!xhci->current_cmd) {
>> +        spin_unlock_irqrestore(&xhci->lock, flags);
>> +        return;
>>       }
>>
>> +    if (xhci->current_cmd->status == COMP_CMD_ABORT)
>> +        second_timeout = true;
>> +    xhci->current_cmd->status = COMP_CMD_ABORT;
>> +
>>       /* Make sure command ring is running before aborting it */
>>       hw_ring_state = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
>>       if ((xhci->cmd_ring_state & CMD_RING_STATE_RUNNING) &&
>> @@ -1422,6 +1424,10 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
>>           xhci->current_cmd = list_entry(cmd->cmd_list.next,
>>                              struct xhci_command, cmd_list);
>>           mod_timer(&xhci->cmd_timer, jiffies + XHCI_CMD_DEFAULT_TIMEOUT);
>> +    } else if (xhci->current_cmd == cmd) {
>> +        xhci->current_cmd = NULL;
>> +    } else {
>> +        xhci_warn(xhci, "WARN current_cmd doesn't match command\n");
>>       }
>>
>>   event_handled:
>>
>
> Thanks,
>
> I might do some tweaking to (or remove)  the warn message when applying if
> that is ok

Sure.

>
> -Mathias
>

Best regards,
Lu Baolu

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2016-12-05  9:37 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-12-02  2:29 [PATCH 1/1] usb: xhci: fix possible wild pointer Lu Baolu
2016-12-02  4:18 ` Baolin Wang
2016-12-02  4:40   ` Lu Baolu
2016-12-02  4:48     ` Baolin Wang
2016-12-02 13:39 ` Mathias Nyman
2016-12-05  9:07   ` Lu Baolu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).