2020-03-18 03:06:39

by 李桃

[permalink] [raw]
Subject: [PATCH] usb: gadget: serial: Fixed KASAN null-ptr-deref in tty_wakeup

The port->port.tty maybe reset as NULL, If gs_close() was invoked
unexpectedly during running gserial_connect().

BUG: KASAN: null-ptr-deref in tty_wakeup+0x1c/0x84
Call trace:
[<0000000095c3c837>] dump_backtrace+0x0/0x6d4
[<0000000047726bb8>] show_stack+0x18/0x20
[<00000000bedb4c1e>] --dump_stack+0x20/0x28
[<00000000722f2e2a>] dump_stack+0x84/0xb0
[<00000000325683d4>] kasan_report_error+0x178/0x1e4
[<0000000053079998>] kasan_report_error+0x0/0x1e4
[<00000000b6d33afa>] --asan_load8+0x150/0x15c
[<00000000188745b8>] tty_wakeup+0x1c/0x84
[<0000000064f6dd21>] gs_start_io+0xd0/0x11c
[<0000000063d67b6c>] gserial_connect+0x15c/0x1b0
[<00000000faf7c0f9>] dm_set_alt+0xa8/0x190
[<000000008deb1909>] composite_setup+0xde4/0x1edc
[<00000000792ee16d>] android_setup+0x210/0x294
[<00000000ab32ef30>] dwc3_ep0_delegate_req+0x48/0x68
[<0000000054e26fd2>] dwc3_ep0_interrupt+0xf2c/0x16fc
[<0000000050cb2262>] dwc3_interrupt+0x464/0x1f44
[<00000000fdcaa6e9>] --handle_irq_event_percpu+0x184/0x398
[<000000003b24ff56>] handle_irq_event_percpu+0xa0/0x134
[<00000000aedda5ee>] handle_irq_event+0x60/0xa0
[<000000005f51a570>] handle_fasteoi_irq+0x23c/0x31c
[<000000008db2608d>] generic_handle_irq+0x70/0xa4
[<00000000098683fc>] --handle_domain_irq+0x84/0xe0
[<000000008ed23b46>] gic_handle_irq+0x98/0xb8

Signed-off-by: Li Tao <[email protected]>
---
drivers/usb/gadget/function/u_serial.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/u_serial.c b/drivers/usb/gadget/function/u_serial.c
index 8167d379e115..3c109a8f9ec4 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -565,7 +565,8 @@ static int gs_start_io(struct gs_port *port)
gs_start_tx(port);
/* Unblock any pending writes into our circular buffer, in case
* we didn't in gs_start_tx() */
- tty_wakeup(port->port.tty);
+ if (port->port.tty)
+ tty_wakeup(port->port.tty);
} else {
gs_free_requests(ep, head, &port->read_allocated);
gs_free_requests(port->port_usb->in, &port->write_pool,
--
2.17.1


2020-03-18 10:13:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH] usb: gadget: serial: Fixed KASAN null-ptr-deref in tty_wakeup

On Wed, Mar 18, 2020 at 10:56:01AM +0800, Li Tao wrote:
> The port->port.tty maybe reset as NULL, If gs_close() was invoked
> unexpectedly during running gserial_connect().
>
> BUG: KASAN: null-ptr-deref in tty_wakeup+0x1c/0x84
> Call trace:
> [<0000000095c3c837>] dump_backtrace+0x0/0x6d4
> [<0000000047726bb8>] show_stack+0x18/0x20
> [<00000000bedb4c1e>] --dump_stack+0x20/0x28
> [<00000000722f2e2a>] dump_stack+0x84/0xb0
> [<00000000325683d4>] kasan_report_error+0x178/0x1e4
> [<0000000053079998>] kasan_report_error+0x0/0x1e4
> [<00000000b6d33afa>] --asan_load8+0x150/0x15c
> [<00000000188745b8>] tty_wakeup+0x1c/0x84
> [<0000000064f6dd21>] gs_start_io+0xd0/0x11c
> [<0000000063d67b6c>] gserial_connect+0x15c/0x1b0
> [<00000000faf7c0f9>] dm_set_alt+0xa8/0x190
> [<000000008deb1909>] composite_setup+0xde4/0x1edc
> [<00000000792ee16d>] android_setup+0x210/0x294
> [<00000000ab32ef30>] dwc3_ep0_delegate_req+0x48/0x68
> [<0000000054e26fd2>] dwc3_ep0_interrupt+0xf2c/0x16fc
> [<0000000050cb2262>] dwc3_interrupt+0x464/0x1f44
> [<00000000fdcaa6e9>] --handle_irq_event_percpu+0x184/0x398
> [<000000003b24ff56>] handle_irq_event_percpu+0xa0/0x134
> [<00000000aedda5ee>] handle_irq_event+0x60/0xa0
> [<000000005f51a570>] handle_fasteoi_irq+0x23c/0x31c
> [<000000008db2608d>] generic_handle_irq+0x70/0xa4
> [<00000000098683fc>] --handle_domain_irq+0x84/0xe0
> [<000000008ed23b46>] gic_handle_irq+0x98/0xb8
>
> Signed-off-by: Li Tao <[email protected]>
> ---
> drivers/usb/gadget/function/u_serial.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/function/u_serial.c b/drivers/usb/gadget/function/u_serial.c
> index 8167d379e115..3c109a8f9ec4 100644
> --- a/drivers/usb/gadget/function/u_serial.c
> +++ b/drivers/usb/gadget/function/u_serial.c
> @@ -565,7 +565,8 @@ static int gs_start_io(struct gs_port *port)
> gs_start_tx(port);
> /* Unblock any pending writes into our circular buffer, in case
> * we didn't in gs_start_tx() */
> - tty_wakeup(port->port.tty);
> + if (port->port.tty)
> + tty_wakeup(port->port.tty);

What prevents port.tty from being set to NULL between the check and the
call to tty_wakeup?

Shouldn't gs_close() and gserial_connect() have some sort of locking to
prevent this?

thanks,

greg k-h

2020-03-25 07:38:21

by 李桃

[permalink] [raw]
Subject: Re:Re: [PATCH] usb: gadget: serial: Fixed KASAN null-ptr-deref in tty_wakeup

From: Greg Kroah-Hartman <[email protected]>
Date: 2020-03-18 18:12:40
To: Li Tao <[email protected]>
Cc: Felipe Balbi <[email protected]>,"Michał Mirosław" <[email protected]>,Sergey Organov <[email protected]>,[email protected],[email protected],[email protected]
Subject: Re: [PATCH] usb: gadget: serial: Fixed KASAN null-ptr-deref in tty_wakeup>On Wed, Mar 18, 2020 at 10:56:01AM +0800, Li Tao wrote:
>> The port->port.tty maybe reset as NULL, If gs_close() was invoked
>> unexpectedly during running gserial_connect().
>>
>> BUG: KASAN: null-ptr-deref in tty_wakeup+0x1c/0x84
>> Call trace:
>> [<0000000095c3c837>] dump_backtrace+0x0/0x6d4
>> [<0000000047726bb8>] show_stack+0x18/0x20
>> [<00000000bedb4c1e>] --dump_stack+0x20/0x28
>> [<00000000722f2e2a>] dump_stack+0x84/0xb0
>> [<00000000325683d4>] kasan_report_error+0x178/0x1e4
>> [<0000000053079998>] kasan_report_error+0x0/0x1e4
>> [<00000000b6d33afa>] --asan_load8+0x150/0x15c
>> [<00000000188745b8>] tty_wakeup+0x1c/0x84
>> [<0000000064f6dd21>] gs_start_io+0xd0/0x11c
>> [<0000000063d67b6c>] gserial_connect+0x15c/0x1b0
>> [<00000000faf7c0f9>] dm_set_alt+0xa8/0x190
>> [<000000008deb1909>] composite_setup+0xde4/0x1edc
>> [<00000000792ee16d>] android_setup+0x210/0x294
>> [<00000000ab32ef30>] dwc3_ep0_delegate_req+0x48/0x68
>> [<0000000054e26fd2>] dwc3_ep0_interrupt+0xf2c/0x16fc
>> [<0000000050cb2262>] dwc3_interrupt+0x464/0x1f44
>> [<00000000fdcaa6e9>] --handle_irq_event_percpu+0x184/0x398
>> [<000000003b24ff56>] handle_irq_event_percpu+0xa0/0x134
>> [<00000000aedda5ee>] handle_irq_event+0x60/0xa0
>> [<000000005f51a570>] handle_fasteoi_irq+0x23c/0x31c
>> [<000000008db2608d>] generic_handle_irq+0x70/0xa4
>> [<00000000098683fc>] --handle_domain_irq+0x84/0xe0
>> [<000000008ed23b46>] gic_handle_irq+0x98/0xb8
>>
>> Signed-off-by: Li Tao <[email protected]>
>> ---
>> drivers/usb/gadget/function/u_serial.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/gadget/function/u_serial.c b/drivers/usb/gadget/function/u_serial.c
>> index 8167d379e115..3c109a8f9ec4 100644
>> --- a/drivers/usb/gadget/function/u_serial.c
>> +++ b/drivers/usb/gadget/function/u_serial.c
>> @@ -565,7 +565,8 @@ static int gs_start_io(struct gs_port *port)
>> gs_start_tx(port);
>> /* Unblock any pending writes into our circular buffer, in case
>> * we didn't in gs_start_tx() */
>> - tty_wakeup(port->port.tty);
>> + if (port->port.tty)
>> + tty_wakeup(port->port.tty);
>
>What prevents port.tty from being set to NULL between the check and the
>call to tty_wakeup?
>
>Shouldn't gs_close() and gserial_connect() have some sort of locking to
>prevent this?
>
I encountered this issue on Samsung EXYNOS980 platform, Maybe this is platform specific issue.
The USB interrupt handler got port_lock on CPU 0 in gserial_connect while gs_close is waiting for
this lock on CPU 1. But this port_lock will unlock in gs_start_io-->gs_start_rx temporarily, This race
condition may cause port.tty set as NULL.

>thanks,
>
>greg k-h


2020-04-08 07:58:40

by 李桃

[permalink] [raw]
Subject: Re:Re: [PATCH] usb: gadget: serial: Fixed KASAN null-ptr-deref in tty_wakeup

From: Greg Kroah-Hartman <[email protected]>
Date: 2020-03-18 18:12:40
To: Li Tao <[email protected]>
Cc: Felipe Balbi <[email protected]>,"Michał Mirosław" <[email protected]>,Sergey Organov <[email protected]>,[email protected],[email protected],[email protected]
Subject: Re: [PATCH] usb: gadget: serial: Fixed KASAN null-ptr-deref in tty_wakeup>On Wed, Mar 18, 2020 at 10:56:01AM +0800, Li Tao wrote:
>> The port->port.tty maybe reset as NULL, If gs_close() was invoked
>> unexpectedly during running gserial_connect().
>>
>> BUG: KASAN: null-ptr-deref in tty_wakeup+0x1c/0x84
>> Call trace:
>> [<0000000095c3c837>] dump_backtrace+0x0/0x6d4
>> [<0000000047726bb8>] show_stack+0x18/0x20
>> [<00000000bedb4c1e>] --dump_stack+0x20/0x28
>> [<00000000722f2e2a>] dump_stack+0x84/0xb0
>> [<00000000325683d4>] kasan_report_error+0x178/0x1e4
>> [<0000000053079998>] kasan_report_error+0x0/0x1e4
>> [<00000000b6d33afa>] --asan_load8+0x150/0x15c
>> [<00000000188745b8>] tty_wakeup+0x1c/0x84
>> [<0000000064f6dd21>] gs_start_io+0xd0/0x11c
>> [<0000000063d67b6c>] gserial_connect+0x15c/0x1b0
>> [<00000000faf7c0f9>] dm_set_alt+0xa8/0x190
>> [<000000008deb1909>] composite_setup+0xde4/0x1edc
>> [<00000000792ee16d>] android_setup+0x210/0x294
>> [<00000000ab32ef30>] dwc3_ep0_delegate_req+0x48/0x68
>> [<0000000054e26fd2>] dwc3_ep0_interrupt+0xf2c/0x16fc
>> [<0000000050cb2262>] dwc3_interrupt+0x464/0x1f44
>> [<00000000fdcaa6e9>] --handle_irq_event_percpu+0x184/0x398
>> [<000000003b24ff56>] handle_irq_event_percpu+0xa0/0x134
>> [<00000000aedda5ee>] handle_irq_event+0x60/0xa0
>> [<000000005f51a570>] handle_fasteoi_irq+0x23c/0x31c
>> [<000000008db2608d>] generic_handle_irq+0x70/0xa4
>> [<00000000098683fc>] --handle_domain_irq+0x84/0xe0
>> [<000000008ed23b46>] gic_handle_irq+0x98/0xb8
>>
>> Signed-off-by: Li Tao <[email protected]>
>> ---
>> drivers/usb/gadget/function/u_serial.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/gadget/function/u_serial.c b/drivers/usb/gadget/function/u_serial.c
>> index 8167d379e115..3c109a8f9ec4 100644
>> --- a/drivers/usb/gadget/function/u_serial.c
>> +++ b/drivers/usb/gadget/function/u_serial.c
>> @@ -565,7 +565,8 @@ static int gs_start_io(struct gs_port *port)
>> gs_start_tx(port);
>> /* Unblock any pending writes into our circular buffer, in case
>> * we didn't in gs_start_tx() */
>> - tty_wakeup(port->port.tty);
>> + if (port->port.tty)
>> + tty_wakeup(port->port.tty);
>
>What prevents port.tty from being set to NULL between the check and the
>call to tty_wakeup?
>
>Shouldn't gs_close() and gserial_connect() have some sort of locking to
>prevent this?
>
I encountered this issue on Samsung EXYNOS980 platform, Maybe this is platform specific issue.
The USB interrupt handler got port_lock on CPU 0 in gserial_connect while gs_close is waiting for
this lock on CPU 1. But this port_lock will unlock in gs_start_io-->gs_start_rx temporarily, This race
condition may cause port.tty set as NULL.

greg k-h, Do you have some good suggestions?

>thanks,
>
>greg k-h




2020-04-08 10:12:33

by Michał Mirosław

[permalink] [raw]
Subject: Re: Re: [PATCH] usb: gadget: serial: Fixed KASAN null-ptr-deref in tty_wakeup

On Wed, Apr 08, 2020 at 03:42:53PM +0800, 李桃 wrote:
> Cc: Felipe Balbi <[email protected]>,"Michał Mirosław" <[email protected]>,Sergey Organov <[email protected]>,[email protected],[email protected],[email protected]
> Subject: Re: [PATCH] usb: gadget: serial: Fixed KASAN null-ptr-deref in tty_wakeup>On Wed, Mar 18, 2020 at 10:56:01AM +0800, Li Tao wrote:
> >> The port->port.tty maybe reset as NULL, If gs_close() was invoked
> >> unexpectedly during running gserial_connect().
> >>
> >> BUG: KASAN: null-ptr-deref in tty_wakeup+0x1c/0x84
> >> Call trace:
> >> [<0000000095c3c837>] dump_backtrace+0x0/0x6d4
> >> [<0000000047726bb8>] show_stack+0x18/0x20
> >> [<00000000bedb4c1e>] --dump_stack+0x20/0x28
> >> [<00000000722f2e2a>] dump_stack+0x84/0xb0
> >> [<00000000325683d4>] kasan_report_error+0x178/0x1e4
> >> [<0000000053079998>] kasan_report_error+0x0/0x1e4
> >> [<00000000b6d33afa>] --asan_load8+0x150/0x15c
> >> [<00000000188745b8>] tty_wakeup+0x1c/0x84
> >> [<0000000064f6dd21>] gs_start_io+0xd0/0x11c
> >> [<0000000063d67b6c>] gserial_connect+0x15c/0x1b0
> >> [<00000000faf7c0f9>] dm_set_alt+0xa8/0x190
> >> [<000000008deb1909>] composite_setup+0xde4/0x1edc
> >> [<00000000792ee16d>] android_setup+0x210/0x294
> >> [<00000000ab32ef30>] dwc3_ep0_delegate_req+0x48/0x68
> >> [<0000000054e26fd2>] dwc3_ep0_interrupt+0xf2c/0x16fc
> >> [<0000000050cb2262>] dwc3_interrupt+0x464/0x1f44
> >> [<00000000fdcaa6e9>] --handle_irq_event_percpu+0x184/0x398
> >> [<000000003b24ff56>] handle_irq_event_percpu+0xa0/0x134
> >> [<00000000aedda5ee>] handle_irq_event+0x60/0xa0
> >> [<000000005f51a570>] handle_fasteoi_irq+0x23c/0x31c
> >> [<000000008db2608d>] generic_handle_irq+0x70/0xa4
> >> [<00000000098683fc>] --handle_domain_irq+0x84/0xe0
> >> [<000000008ed23b46>] gic_handle_irq+0x98/0xb8
> >>
> >> Signed-off-by: Li Tao <[email protected]>
> >> ---
> >> drivers/usb/gadget/function/u_serial.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/usb/gadget/function/u_serial.c b/drivers/usb/gadget/function/u_serial.c
> >> index 8167d379e115..3c109a8f9ec4 100644
> >> --- a/drivers/usb/gadget/function/u_serial.c
> >> +++ b/drivers/usb/gadget/function/u_serial.c
> >> @@ -565,7 +565,8 @@ static int gs_start_io(struct gs_port *port)
> >> gs_start_tx(port);
> >> /* Unblock any pending writes into our circular buffer, in case
> >> * we didn't in gs_start_tx() */
> >> - tty_wakeup(port->port.tty);
> >> + if (port->port.tty)
> >> + tty_wakeup(port->port.tty);
> >
> >What prevents port.tty from being set to NULL between the check and the
> >call to tty_wakeup?
> >
> >Shouldn't gs_close() and gserial_connect() have some sort of locking to
> >prevent this?
> >
> I encountered this issue on Samsung EXYNOS980 platform, Maybe this is platform specific issue.
> The USB interrupt handler got port_lock on CPU 0 in gserial_connect while gs_close is waiting for
> this lock on CPU 1. But this port_lock will unlock in gs_start_io-->gs_start_rx temporarily, This race
> condition may cause port.tty set as NULL.

Hi,

gserial_connect() indeed accesses port[] array without taking the
portmaster's mutex. This is since commit 19b10a8828a6 ("usb: gadget:
allocate & giveback serial ports instead hard code them") introduced
dynamic allocation of the port structure.

Best Regards,
Michał Mirosław