* [PATCH v2 0/2] usb: typec: ucsi: Fixes for Huawei Matebook E Go UCSI driver
@ 2025-11-25 10:36 Duoming Zhou
2025-11-25 10:36 ` [PATCH v2 1/2] usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe() Duoming Zhou
2025-11-25 10:36 ` [PATCH v2 2/2] usb: typec: ucsi: fix use-after-free caused by uec->work Duoming Zhou
0 siblings, 2 replies; 9+ messages in thread
From: Duoming Zhou @ 2025-11-25 10:36 UTC (permalink / raw)
To: linux-usb
Cc: gregkh, heikki.krogerus, mitltlatltl, linux-kernel,
sergei.shtylyov, Duoming Zhou
This patch series addresses two critical issues in the Huawei Matebook E Go
UCSI driver that were preventing proper functionality and causing potential
use-after-free scenarios.
The first patch fixes a probe failure by adding the missing poll_cci to the
UCSI operations structure, which is required by the UCSI core for proper
initialization.
The second patch resolves use-after-free vulnerabilities where a delayed
work item could access freed memory after device or module removal, by
ensuring proper cancellation of the work item in gaokun_ucsi_remove().
Duoming Zhou (2):
usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()
usb: typec: ucsi: fix use-after-free caused by uec->work
drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c | 2 ++
1 file changed, 2 insertions(+)
--
2.34.1
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v2 1/2] usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()
2025-11-25 10:36 [PATCH v2 0/2] usb: typec: ucsi: Fixes for Huawei Matebook E Go UCSI driver Duoming Zhou
@ 2025-11-25 10:36 ` Duoming Zhou
2025-11-26 9:49 ` Heikki Krogerus
2025-12-17 13:19 ` Greg KH
2025-11-25 10:36 ` [PATCH v2 2/2] usb: typec: ucsi: fix use-after-free caused by uec->work Duoming Zhou
1 sibling, 2 replies; 9+ messages in thread
From: Duoming Zhou @ 2025-11-25 10:36 UTC (permalink / raw)
To: linux-usb
Cc: gregkh, heikki.krogerus, mitltlatltl, linux-kernel,
sergei.shtylyov, Duoming Zhou, stable
The gaokun_ucsi_probe() uses ucsi_create() to allocate a UCSI instance.
The ucsi_create() validates whether ops->poll_cci is defined, and if not,
it directly returns -EINVAL. However, the gaokun_ucsi_ops structure does
not define the poll_cci, causing ucsi_create() always fail with -EINVAL.
This issue can be observed in the kernel log with the following error:
ucsi_huawei_gaokun.ucsi huawei_gaokun_ec.ucsi.0: probe with driver
ucsi_huawei_gaokun.ucsi failed with error -22
Fix the issue by adding the missing poll_cci callback to gaokun_ucsi_ops.
Fixes: 00327d7f2c8c ("usb: typec: ucsi: add Huawei Matebook E Go ucsi driver")
Cc: stable@vger.kernel.org
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
---
Changes in v2:
- Add cc: stable.
- Correct spelling mistake.
drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
index 7b5222081bb..8401ab414bd 100644
--- a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
+++ b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
@@ -196,6 +196,7 @@ static void gaokun_ucsi_connector_status(struct ucsi_connector *con)
const struct ucsi_operations gaokun_ucsi_ops = {
.read_version = gaokun_ucsi_read_version,
.read_cci = gaokun_ucsi_read_cci,
+ .poll_cci = gaokun_ucsi_read_cci,
.read_message_in = gaokun_ucsi_read_message_in,
.sync_control = ucsi_sync_control_common,
.async_control = gaokun_ucsi_async_control,
--
2.34.1
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v2 1/2] usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()
2025-11-25 10:36 ` [PATCH v2 1/2] usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe() Duoming Zhou
@ 2025-11-26 9:49 ` Heikki Krogerus
2025-12-17 13:19 ` Greg KH
1 sibling, 0 replies; 9+ messages in thread
From: Heikki Krogerus @ 2025-11-26 9:49 UTC (permalink / raw)
To: Duoming Zhou
Cc: linux-usb, gregkh, mitltlatltl, linux-kernel, sergei.shtylyov,
stable
Tue, Nov 25, 2025 at 06:36:26PM +0800, Duoming Zhou kirjoitti:
> The gaokun_ucsi_probe() uses ucsi_create() to allocate a UCSI instance.
> The ucsi_create() validates whether ops->poll_cci is defined, and if not,
> it directly returns -EINVAL. However, the gaokun_ucsi_ops structure does
> not define the poll_cci, causing ucsi_create() always fail with -EINVAL.
> This issue can be observed in the kernel log with the following error:
>
> ucsi_huawei_gaokun.ucsi huawei_gaokun_ec.ucsi.0: probe with driver
> ucsi_huawei_gaokun.ucsi failed with error -22
>
> Fix the issue by adding the missing poll_cci callback to gaokun_ucsi_ops.
>
> Fixes: 00327d7f2c8c ("usb: typec: ucsi: add Huawei Matebook E Go ucsi driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
> Changes in v2:
> - Add cc: stable.
> - Correct spelling mistake.
>
> drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> index 7b5222081bb..8401ab414bd 100644
> --- a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> +++ b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> @@ -196,6 +196,7 @@ static void gaokun_ucsi_connector_status(struct ucsi_connector *con)
> const struct ucsi_operations gaokun_ucsi_ops = {
> .read_version = gaokun_ucsi_read_version,
> .read_cci = gaokun_ucsi_read_cci,
> + .poll_cci = gaokun_ucsi_read_cci,
> .read_message_in = gaokun_ucsi_read_message_in,
> .sync_control = ucsi_sync_control_common,
> .async_control = gaokun_ucsi_async_control,
> --
> 2.34.1
--
heikki
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v2 1/2] usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()
2025-11-25 10:36 ` [PATCH v2 1/2] usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe() Duoming Zhou
2025-11-26 9:49 ` Heikki Krogerus
@ 2025-12-17 13:19 ` Greg KH
1 sibling, 0 replies; 9+ messages in thread
From: Greg KH @ 2025-12-17 13:19 UTC (permalink / raw)
To: Duoming Zhou
Cc: linux-usb, heikki.krogerus, mitltlatltl, linux-kernel,
sergei.shtylyov, stable
On Tue, Nov 25, 2025 at 06:36:26PM +0800, Duoming Zhou wrote:
> The gaokun_ucsi_probe() uses ucsi_create() to allocate a UCSI instance.
> The ucsi_create() validates whether ops->poll_cci is defined, and if not,
> it directly returns -EINVAL. However, the gaokun_ucsi_ops structure does
> not define the poll_cci, causing ucsi_create() always fail with -EINVAL.
> This issue can be observed in the kernel log with the following error:
>
> ucsi_huawei_gaokun.ucsi huawei_gaokun_ec.ucsi.0: probe with driver
> ucsi_huawei_gaokun.ucsi failed with error -22
>
> Fix the issue by adding the missing poll_cci callback to gaokun_ucsi_ops.
>
> Fixes: 00327d7f2c8c ("usb: typec: ucsi: add Huawei Matebook E Go ucsi driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
> ---
> Changes in v2:
> - Add cc: stable.
> - Correct spelling mistake.
>
> drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> index 7b5222081bb..8401ab414bd 100644
> --- a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> +++ b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> @@ -196,6 +196,7 @@ static void gaokun_ucsi_connector_status(struct ucsi_connector *con)
> const struct ucsi_operations gaokun_ucsi_ops = {
> .read_version = gaokun_ucsi_read_version,
> .read_cci = gaokun_ucsi_read_cci,
> + .poll_cci = gaokun_ucsi_read_cci,
> .read_message_in = gaokun_ucsi_read_message_in,
> .sync_control = ucsi_sync_control_common,
> .async_control = gaokun_ucsi_async_control,
> --
> 2.34.1
>
What ever happened to this? if it is still needed, please rebase
against 6.19-rc1 and resend.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v2 2/2] usb: typec: ucsi: fix use-after-free caused by uec->work
2025-11-25 10:36 [PATCH v2 0/2] usb: typec: ucsi: Fixes for Huawei Matebook E Go UCSI driver Duoming Zhou
2025-11-25 10:36 ` [PATCH v2 1/2] usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe() Duoming Zhou
@ 2025-11-25 10:36 ` Duoming Zhou
2025-11-25 11:44 ` Greg KH
2025-11-26 9:50 ` Heikki Krogerus
1 sibling, 2 replies; 9+ messages in thread
From: Duoming Zhou @ 2025-11-25 10:36 UTC (permalink / raw)
To: linux-usb
Cc: gregkh, heikki.krogerus, mitltlatltl, linux-kernel,
sergei.shtylyov, Duoming Zhou, stable
The delayed work uec->work is scheduled in gaokun_ucsi_probe()
but never properly canceled in gaokun_ucsi_remove(). This creates
use-after-free scenarios where the ucsi and gaokun_ucsi structure
are freed after ucsi_destroy() completes execution, while the
gaokun_ucsi_register_worker() might be either currently executing
or still pending in the work queue. The already-freed gaokun_ucsi
or ucsi structure may then be accessed.
Furthermore, the race window is 3 seconds, which is sufficiently
long to make this bug easily reproducible. The following is the
trace captured by KASAN:
==================================================================
BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630
Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0
...
Call trace:
show_stack+0x18/0x24 (C)
dump_stack_lvl+0x78/0x90
print_report+0x114/0x580
kasan_report+0xa4/0xf0
__asan_report_store8_noabort+0x20/0x2c
__run_timers+0x5ec/0x630
run_timer_softirq+0xe8/0x1cc
handle_softirqs+0x294/0x720
__do_softirq+0x14/0x20
____do_softirq+0x10/0x1c
call_on_irq_stack+0x30/0x48
do_softirq_own_stack+0x1c/0x28
__irq_exit_rcu+0x27c/0x364
irq_exit_rcu+0x10/0x1c
el1_interrupt+0x40/0x60
el1h_64_irq_handler+0x18/0x24
el1h_64_irq+0x6c/0x70
arch_local_irq_enable+0x4/0x8 (P)
do_idle+0x334/0x458
cpu_startup_entry+0x60/0x70
rest_init+0x158/0x174
start_kernel+0x2f8/0x394
__primary_switched+0x8c/0x94
Allocated by task 72 on cpu 0 at 27.510341s:
kasan_save_stack+0x2c/0x54
kasan_save_track+0x24/0x5c
kasan_save_alloc_info+0x40/0x54
__kasan_kmalloc+0xa0/0xb8
__kmalloc_node_track_caller_noprof+0x1c0/0x588
devm_kmalloc+0x7c/0x1c8
gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8
really_probe+0x17c/0x5b8
__driver_probe_device+0x158/0x2c4
driver_probe_device+0x10c/0x264
__device_attach_driver+0x168/0x2d0
bus_for_each_drv+0x100/0x188
__device_attach+0x174/0x368
device_initial_probe+0x14/0x20
bus_probe_device+0x120/0x150
device_add+0xb3c/0x10fc
__auxiliary_device_add+0x88/0x130
...
Freed by task 73 on cpu 1 at 28.910627s:
kasan_save_stack+0x2c/0x54
kasan_save_track+0x24/0x5c
__kasan_save_free_info+0x4c/0x74
__kasan_slab_free+0x60/0x8c
kfree+0xd4/0x410
devres_release_all+0x140/0x1f0
device_unbind_cleanup+0x20/0x190
device_release_driver_internal+0x344/0x460
device_release_driver+0x18/0x24
bus_remove_device+0x198/0x274
device_del+0x310/0xa84
...
The buggy address belongs to the object at ffff00000ec28c00
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 200 bytes inside of
freed 512-byte region
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28
head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff)
page_type: f5(slab)
raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000
raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000
head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Add disable_delayed_work_sync() in gaokun_ucsi_remove() to ensure
that uec->work is properly canceled and prevented from executing
after the ucsi and gaokun_ucsi structure have been deallocated.
Fixes: 00327d7f2c8c ("usb: typec: ucsi: add Huawei Matebook E Go ucsi driver")
Cc: stable@vger.kernel.org
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
---
drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
index 8401ab414bd..c5965656bab 100644
--- a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
+++ b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
@@ -503,6 +503,7 @@ static void gaokun_ucsi_remove(struct auxiliary_device *adev)
{
struct gaokun_ucsi *uec = auxiliary_get_drvdata(adev);
+ disable_delayed_work_sync(&uec->work);
gaokun_ec_unregister_notify(uec->ec, &uec->nb);
ucsi_unregister(uec->ucsi);
ucsi_destroy(uec->ucsi);
--
2.34.1
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v2 2/2] usb: typec: ucsi: fix use-after-free caused by uec->work
2025-11-25 10:36 ` [PATCH v2 2/2] usb: typec: ucsi: fix use-after-free caused by uec->work Duoming Zhou
@ 2025-11-25 11:44 ` Greg KH
2025-11-25 12:02 ` duoming
2025-11-26 9:50 ` Heikki Krogerus
1 sibling, 1 reply; 9+ messages in thread
From: Greg KH @ 2025-11-25 11:44 UTC (permalink / raw)
To: Duoming Zhou
Cc: linux-usb, heikki.krogerus, mitltlatltl, linux-kernel,
sergei.shtylyov, stable
On Tue, Nov 25, 2025 at 06:36:27PM +0800, Duoming Zhou wrote:
> The delayed work uec->work is scheduled in gaokun_ucsi_probe()
> but never properly canceled in gaokun_ucsi_remove(). This creates
> use-after-free scenarios where the ucsi and gaokun_ucsi structure
> are freed after ucsi_destroy() completes execution, while the
> gaokun_ucsi_register_worker() might be either currently executing
> or still pending in the work queue. The already-freed gaokun_ucsi
> or ucsi structure may then be accessed.
>
> Furthermore, the race window is 3 seconds, which is sufficiently
> long to make this bug easily reproducible. The following is the
> trace captured by KASAN:
>
> ==================================================================
> BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630
> Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0
> ...
> Call trace:
> show_stack+0x18/0x24 (C)
> dump_stack_lvl+0x78/0x90
> print_report+0x114/0x580
> kasan_report+0xa4/0xf0
> __asan_report_store8_noabort+0x20/0x2c
> __run_timers+0x5ec/0x630
> run_timer_softirq+0xe8/0x1cc
> handle_softirqs+0x294/0x720
> __do_softirq+0x14/0x20
> ____do_softirq+0x10/0x1c
> call_on_irq_stack+0x30/0x48
> do_softirq_own_stack+0x1c/0x28
> __irq_exit_rcu+0x27c/0x364
> irq_exit_rcu+0x10/0x1c
> el1_interrupt+0x40/0x60
> el1h_64_irq_handler+0x18/0x24
> el1h_64_irq+0x6c/0x70
> arch_local_irq_enable+0x4/0x8 (P)
> do_idle+0x334/0x458
> cpu_startup_entry+0x60/0x70
> rest_init+0x158/0x174
> start_kernel+0x2f8/0x394
> __primary_switched+0x8c/0x94
>
> Allocated by task 72 on cpu 0 at 27.510341s:
> kasan_save_stack+0x2c/0x54
> kasan_save_track+0x24/0x5c
> kasan_save_alloc_info+0x40/0x54
> __kasan_kmalloc+0xa0/0xb8
> __kmalloc_node_track_caller_noprof+0x1c0/0x588
> devm_kmalloc+0x7c/0x1c8
> gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8
> really_probe+0x17c/0x5b8
> __driver_probe_device+0x158/0x2c4
> driver_probe_device+0x10c/0x264
> __device_attach_driver+0x168/0x2d0
> bus_for_each_drv+0x100/0x188
> __device_attach+0x174/0x368
> device_initial_probe+0x14/0x20
> bus_probe_device+0x120/0x150
> device_add+0xb3c/0x10fc
> __auxiliary_device_add+0x88/0x130
> ...
>
> Freed by task 73 on cpu 1 at 28.910627s:
> kasan_save_stack+0x2c/0x54
> kasan_save_track+0x24/0x5c
> __kasan_save_free_info+0x4c/0x74
> __kasan_slab_free+0x60/0x8c
> kfree+0xd4/0x410
> devres_release_all+0x140/0x1f0
> device_unbind_cleanup+0x20/0x190
> device_release_driver_internal+0x344/0x460
> device_release_driver+0x18/0x24
> bus_remove_device+0x198/0x274
> device_del+0x310/0xa84
> ...
>
> The buggy address belongs to the object at ffff00000ec28c00
> which belongs to the cache kmalloc-512 of size 512
> The buggy address is located 200 bytes inside of
> freed 512-byte region
> The buggy address belongs to the physical page:
> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28
> head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff)
> page_type: f5(slab)
> raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000
> raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
> head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000
> head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
> head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff
> head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
>
> Add disable_delayed_work_sync() in gaokun_ucsi_remove() to ensure
> that uec->work is properly canceled and prevented from executing
> after the ucsi and gaokun_ucsi structure have been deallocated.
>
> Fixes: 00327d7f2c8c ("usb: typec: ucsi: add Huawei Matebook E Go ucsi driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
> ---
> drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> index 8401ab414bd..c5965656bab 100644
> --- a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> +++ b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> @@ -503,6 +503,7 @@ static void gaokun_ucsi_remove(struct auxiliary_device *adev)
> {
> struct gaokun_ucsi *uec = auxiliary_get_drvdata(adev);
>
> + disable_delayed_work_sync(&uec->work);
> gaokun_ec_unregister_notify(uec->ec, &uec->nb);
> ucsi_unregister(uec->ucsi);
> ucsi_destroy(uec->ucsi);
> --
> 2.34.1
>
>
What changed from v1?
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v2 2/2] usb: typec: ucsi: fix use-after-free caused by uec->work
2025-11-25 11:44 ` Greg KH
@ 2025-11-25 12:02 ` duoming
2025-11-25 13:02 ` Greg KH
0 siblings, 1 reply; 9+ messages in thread
From: duoming @ 2025-11-25 12:02 UTC (permalink / raw)
To: Greg KH
Cc: linux-usb, heikki.krogerus, mitltlatltl, linux-kernel,
sergei.shtylyov, stable
On Tue, 25 Nov 2025 12:44:02 +0100, Greg KH wrote:
> > The delayed work uec->work is scheduled in gaokun_ucsi_probe()
> > but never properly canceled in gaokun_ucsi_remove(). This creates
> > use-after-free scenarios where the ucsi and gaokun_ucsi structure
> > are freed after ucsi_destroy() completes execution, while the
> > gaokun_ucsi_register_worker() might be either currently executing
> > or still pending in the work queue. The already-freed gaokun_ucsi
> > or ucsi structure may then be accessed.
> >
> > Furthermore, the race window is 3 seconds, which is sufficiently
> > long to make this bug easily reproducible. The following is the
> > trace captured by KASAN:
> >
> > ==================================================================
> > BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630
> > Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0
> > ...
> > Call trace:
> > show_stack+0x18/0x24 (C)
> > dump_stack_lvl+0x78/0x90
> > print_report+0x114/0x580
> > kasan_report+0xa4/0xf0
> > __asan_report_store8_noabort+0x20/0x2c
> > __run_timers+0x5ec/0x630
> > run_timer_softirq+0xe8/0x1cc
> > handle_softirqs+0x294/0x720
> > __do_softirq+0x14/0x20
> > ____do_softirq+0x10/0x1c
> > call_on_irq_stack+0x30/0x48
> > do_softirq_own_stack+0x1c/0x28
> > __irq_exit_rcu+0x27c/0x364
> > irq_exit_rcu+0x10/0x1c
> > el1_interrupt+0x40/0x60
> > el1h_64_irq_handler+0x18/0x24
> > el1h_64_irq+0x6c/0x70
> > arch_local_irq_enable+0x4/0x8 (P)
> > do_idle+0x334/0x458
> > cpu_startup_entry+0x60/0x70
> > rest_init+0x158/0x174
> > start_kernel+0x2f8/0x394
> > __primary_switched+0x8c/0x94
> >
> > Allocated by task 72 on cpu 0 at 27.510341s:
> > kasan_save_stack+0x2c/0x54
> > kasan_save_track+0x24/0x5c
> > kasan_save_alloc_info+0x40/0x54
> > __kasan_kmalloc+0xa0/0xb8
> > __kmalloc_node_track_caller_noprof+0x1c0/0x588
> > devm_kmalloc+0x7c/0x1c8
> > gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8
> > really_probe+0x17c/0x5b8
> > __driver_probe_device+0x158/0x2c4
> > driver_probe_device+0x10c/0x264
> > __device_attach_driver+0x168/0x2d0
> > bus_for_each_drv+0x100/0x188
> > __device_attach+0x174/0x368
> > device_initial_probe+0x14/0x20
> > bus_probe_device+0x120/0x150
> > device_add+0xb3c/0x10fc
> > __auxiliary_device_add+0x88/0x130
> > ...
> >
> > Freed by task 73 on cpu 1 at 28.910627s:
> > kasan_save_stack+0x2c/0x54
> > kasan_save_track+0x24/0x5c
> > __kasan_save_free_info+0x4c/0x74
> > __kasan_slab_free+0x60/0x8c
> > kfree+0xd4/0x410
> > devres_release_all+0x140/0x1f0
> > device_unbind_cleanup+0x20/0x190
> > device_release_driver_internal+0x344/0x460
> > device_release_driver+0x18/0x24
> > bus_remove_device+0x198/0x274
> > device_del+0x310/0xa84
> > ...
> >
> > The buggy address belongs to the object at ffff00000ec28c00
> > which belongs to the cache kmalloc-512 of size 512
> > The buggy address is located 200 bytes inside of
> > freed 512-byte region
> > The buggy address belongs to the physical page:
> > page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28
> > head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> > flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff)
> > page_type: f5(slab)
> > raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000
> > raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
> > head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000
> > head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
> > head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff
> > head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004
> > page dumped because: kasan: bad access detected
> >
> > Memory state around the buggy address:
> > ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ^
> > ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ==================================================================
> >
> > Add disable_delayed_work_sync() in gaokun_ucsi_remove() to ensure
> > that uec->work is properly canceled and prevented from executing
> > after the ucsi and gaokun_ucsi structure have been deallocated.
> >
> > Fixes: 00327d7f2c8c ("usb: typec: ucsi: add Huawei Matebook E Go ucsi driver")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
> > ---
> > drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> > index 8401ab414bd..c5965656bab 100644
> > --- a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> > +++ b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> > @@ -503,6 +503,7 @@ static void gaokun_ucsi_remove(struct auxiliary_device *adev)
> > {
> > struct gaokun_ucsi *uec = auxiliary_get_drvdata(adev);
> >
> > + disable_delayed_work_sync(&uec->work);
> > gaokun_ec_unregister_notify(uec->ec, &uec->nb);
> > ucsi_unregister(uec->ucsi);
> > ucsi_destroy(uec->ucsi);
> > --
> > 2.34.1
> >
> >
>
> What changed from v1?
The original patch[1] only fixes the probe failure in
gaokun_ucsi_probe(). This new version is a patch series
that also addresses the use-after-free issue.
[1] https://lore.kernel.org/lkml/20251125082505.52249-1-duoming@zju.edu.cn/
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v2 2/2] usb: typec: ucsi: fix use-after-free caused by uec->work
2025-11-25 12:02 ` duoming
@ 2025-11-25 13:02 ` Greg KH
0 siblings, 0 replies; 9+ messages in thread
From: Greg KH @ 2025-11-25 13:02 UTC (permalink / raw)
To: duoming
Cc: linux-usb, heikki.krogerus, mitltlatltl, linux-kernel,
sergei.shtylyov, stable
On Tue, Nov 25, 2025 at 08:02:40PM +0800, duoming@zju.edu.cn wrote:
> On Tue, 25 Nov 2025 12:44:02 +0100, Greg KH wrote:
> > > The delayed work uec->work is scheduled in gaokun_ucsi_probe()
> > > but never properly canceled in gaokun_ucsi_remove(). This creates
> > > use-after-free scenarios where the ucsi and gaokun_ucsi structure
> > > are freed after ucsi_destroy() completes execution, while the
> > > gaokun_ucsi_register_worker() might be either currently executing
> > > or still pending in the work queue. The already-freed gaokun_ucsi
> > > or ucsi structure may then be accessed.
> > >
> > > Furthermore, the race window is 3 seconds, which is sufficiently
> > > long to make this bug easily reproducible. The following is the
> > > trace captured by KASAN:
> > >
> > > ==================================================================
> > > BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630
> > > Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0
> > > ...
> > > Call trace:
> > > show_stack+0x18/0x24 (C)
> > > dump_stack_lvl+0x78/0x90
> > > print_report+0x114/0x580
> > > kasan_report+0xa4/0xf0
> > > __asan_report_store8_noabort+0x20/0x2c
> > > __run_timers+0x5ec/0x630
> > > run_timer_softirq+0xe8/0x1cc
> > > handle_softirqs+0x294/0x720
> > > __do_softirq+0x14/0x20
> > > ____do_softirq+0x10/0x1c
> > > call_on_irq_stack+0x30/0x48
> > > do_softirq_own_stack+0x1c/0x28
> > > __irq_exit_rcu+0x27c/0x364
> > > irq_exit_rcu+0x10/0x1c
> > > el1_interrupt+0x40/0x60
> > > el1h_64_irq_handler+0x18/0x24
> > > el1h_64_irq+0x6c/0x70
> > > arch_local_irq_enable+0x4/0x8 (P)
> > > do_idle+0x334/0x458
> > > cpu_startup_entry+0x60/0x70
> > > rest_init+0x158/0x174
> > > start_kernel+0x2f8/0x394
> > > __primary_switched+0x8c/0x94
> > >
> > > Allocated by task 72 on cpu 0 at 27.510341s:
> > > kasan_save_stack+0x2c/0x54
> > > kasan_save_track+0x24/0x5c
> > > kasan_save_alloc_info+0x40/0x54
> > > __kasan_kmalloc+0xa0/0xb8
> > > __kmalloc_node_track_caller_noprof+0x1c0/0x588
> > > devm_kmalloc+0x7c/0x1c8
> > > gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8
> > > really_probe+0x17c/0x5b8
> > > __driver_probe_device+0x158/0x2c4
> > > driver_probe_device+0x10c/0x264
> > > __device_attach_driver+0x168/0x2d0
> > > bus_for_each_drv+0x100/0x188
> > > __device_attach+0x174/0x368
> > > device_initial_probe+0x14/0x20
> > > bus_probe_device+0x120/0x150
> > > device_add+0xb3c/0x10fc
> > > __auxiliary_device_add+0x88/0x130
> > > ...
> > >
> > > Freed by task 73 on cpu 1 at 28.910627s:
> > > kasan_save_stack+0x2c/0x54
> > > kasan_save_track+0x24/0x5c
> > > __kasan_save_free_info+0x4c/0x74
> > > __kasan_slab_free+0x60/0x8c
> > > kfree+0xd4/0x410
> > > devres_release_all+0x140/0x1f0
> > > device_unbind_cleanup+0x20/0x190
> > > device_release_driver_internal+0x344/0x460
> > > device_release_driver+0x18/0x24
> > > bus_remove_device+0x198/0x274
> > > device_del+0x310/0xa84
> > > ...
> > >
> > > The buggy address belongs to the object at ffff00000ec28c00
> > > which belongs to the cache kmalloc-512 of size 512
> > > The buggy address is located 200 bytes inside of
> > > freed 512-byte region
> > > The buggy address belongs to the physical page:
> > > page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28
> > > head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> > > flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff)
> > > page_type: f5(slab)
> > > raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000
> > > raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
> > > head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000
> > > head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
> > > head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff
> > > head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004
> > > page dumped because: kasan: bad access detected
> > >
> > > Memory state around the buggy address:
> > > ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > > ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > > >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > > ^
> > > ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > > ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > > ==================================================================
> > >
> > > Add disable_delayed_work_sync() in gaokun_ucsi_remove() to ensure
> > > that uec->work is properly canceled and prevented from executing
> > > after the ucsi and gaokun_ucsi structure have been deallocated.
> > >
> > > Fixes: 00327d7f2c8c ("usb: typec: ucsi: add Huawei Matebook E Go ucsi driver")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
> > > ---
> > > drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> > > index 8401ab414bd..c5965656bab 100644
> > > --- a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> > > +++ b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> > > @@ -503,6 +503,7 @@ static void gaokun_ucsi_remove(struct auxiliary_device *adev)
> > > {
> > > struct gaokun_ucsi *uec = auxiliary_get_drvdata(adev);
> > >
> > > + disable_delayed_work_sync(&uec->work);
> > > gaokun_ec_unregister_notify(uec->ec, &uec->nb);
> > > ucsi_unregister(uec->ucsi);
> > > ucsi_destroy(uec->ucsi);
> > > --
> > > 2.34.1
> > >
> > >
> >
> > What changed from v1?
>
> The original patch[1] only fixes the probe failure in
> gaokun_ucsi_probe(). This new version is a patch series
> that also addresses the use-after-free issue.
>
> [1] https://lore.kernel.org/lkml/20251125082505.52249-1-duoming@zju.edu.cn/
Always document this in the future please.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 2/2] usb: typec: ucsi: fix use-after-free caused by uec->work
2025-11-25 10:36 ` [PATCH v2 2/2] usb: typec: ucsi: fix use-after-free caused by uec->work Duoming Zhou
2025-11-25 11:44 ` Greg KH
@ 2025-11-26 9:50 ` Heikki Krogerus
1 sibling, 0 replies; 9+ messages in thread
From: Heikki Krogerus @ 2025-11-26 9:50 UTC (permalink / raw)
To: Duoming Zhou
Cc: linux-usb, gregkh, mitltlatltl, linux-kernel, sergei.shtylyov,
stable
Tue, Nov 25, 2025 at 06:36:27PM +0800, Duoming Zhou kirjoitti:
> The delayed work uec->work is scheduled in gaokun_ucsi_probe()
> but never properly canceled in gaokun_ucsi_remove(). This creates
> use-after-free scenarios where the ucsi and gaokun_ucsi structure
> are freed after ucsi_destroy() completes execution, while the
> gaokun_ucsi_register_worker() might be either currently executing
> or still pending in the work queue. The already-freed gaokun_ucsi
> or ucsi structure may then be accessed.
>
> Furthermore, the race window is 3 seconds, which is sufficiently
> long to make this bug easily reproducible. The following is the
> trace captured by KASAN:
>
> ==================================================================
> BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630
> Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0
> ...
> Call trace:
> show_stack+0x18/0x24 (C)
> dump_stack_lvl+0x78/0x90
> print_report+0x114/0x580
> kasan_report+0xa4/0xf0
> __asan_report_store8_noabort+0x20/0x2c
> __run_timers+0x5ec/0x630
> run_timer_softirq+0xe8/0x1cc
> handle_softirqs+0x294/0x720
> __do_softirq+0x14/0x20
> ____do_softirq+0x10/0x1c
> call_on_irq_stack+0x30/0x48
> do_softirq_own_stack+0x1c/0x28
> __irq_exit_rcu+0x27c/0x364
> irq_exit_rcu+0x10/0x1c
> el1_interrupt+0x40/0x60
> el1h_64_irq_handler+0x18/0x24
> el1h_64_irq+0x6c/0x70
> arch_local_irq_enable+0x4/0x8 (P)
> do_idle+0x334/0x458
> cpu_startup_entry+0x60/0x70
> rest_init+0x158/0x174
> start_kernel+0x2f8/0x394
> __primary_switched+0x8c/0x94
>
> Allocated by task 72 on cpu 0 at 27.510341s:
> kasan_save_stack+0x2c/0x54
> kasan_save_track+0x24/0x5c
> kasan_save_alloc_info+0x40/0x54
> __kasan_kmalloc+0xa0/0xb8
> __kmalloc_node_track_caller_noprof+0x1c0/0x588
> devm_kmalloc+0x7c/0x1c8
> gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8
> really_probe+0x17c/0x5b8
> __driver_probe_device+0x158/0x2c4
> driver_probe_device+0x10c/0x264
> __device_attach_driver+0x168/0x2d0
> bus_for_each_drv+0x100/0x188
> __device_attach+0x174/0x368
> device_initial_probe+0x14/0x20
> bus_probe_device+0x120/0x150
> device_add+0xb3c/0x10fc
> __auxiliary_device_add+0x88/0x130
> ...
>
> Freed by task 73 on cpu 1 at 28.910627s:
> kasan_save_stack+0x2c/0x54
> kasan_save_track+0x24/0x5c
> __kasan_save_free_info+0x4c/0x74
> __kasan_slab_free+0x60/0x8c
> kfree+0xd4/0x410
> devres_release_all+0x140/0x1f0
> device_unbind_cleanup+0x20/0x190
> device_release_driver_internal+0x344/0x460
> device_release_driver+0x18/0x24
> bus_remove_device+0x198/0x274
> device_del+0x310/0xa84
> ...
>
> The buggy address belongs to the object at ffff00000ec28c00
> which belongs to the cache kmalloc-512 of size 512
> The buggy address is located 200 bytes inside of
> freed 512-byte region
> The buggy address belongs to the physical page:
> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28
> head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff)
> page_type: f5(slab)
> raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000
> raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
> head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000
> head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
> head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff
> head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
>
> Add disable_delayed_work_sync() in gaokun_ucsi_remove() to ensure
> that uec->work is properly canceled and prevented from executing
> after the ucsi and gaokun_ucsi structure have been deallocated.
>
> Fixes: 00327d7f2c8c ("usb: typec: ucsi: add Huawei Matebook E Go ucsi driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
> drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> index 8401ab414bd..c5965656bab 100644
> --- a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> +++ b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> @@ -503,6 +503,7 @@ static void gaokun_ucsi_remove(struct auxiliary_device *adev)
> {
> struct gaokun_ucsi *uec = auxiliary_get_drvdata(adev);
>
> + disable_delayed_work_sync(&uec->work);
> gaokun_ec_unregister_notify(uec->ec, &uec->nb);
> ucsi_unregister(uec->ucsi);
> ucsi_destroy(uec->ucsi);
> --
> 2.34.1
--
heikki
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2025-12-17 13:19 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-11-25 10:36 [PATCH v2 0/2] usb: typec: ucsi: Fixes for Huawei Matebook E Go UCSI driver Duoming Zhou
2025-11-25 10:36 ` [PATCH v2 1/2] usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe() Duoming Zhou
2025-11-26 9:49 ` Heikki Krogerus
2025-12-17 13:19 ` Greg KH
2025-11-25 10:36 ` [PATCH v2 2/2] usb: typec: ucsi: fix use-after-free caused by uec->work Duoming Zhou
2025-11-25 11:44 ` Greg KH
2025-11-25 12:02 ` duoming
2025-11-25 13:02 ` Greg KH
2025-11-26 9:50 ` Heikki Krogerus
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).