[PATCH v2 0/2] usb: typec: ucsi: Fixes for Huawei Matebook E Go UCSI driver

[PATCH v2 0/2] usb: typec: ucsi: Fixes for Huawei Matebook E Go UCSI driver

[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

[PATCH v2 1/2] usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()

[Duoming Zhou]

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

[PATCH v2 2/2] usb: typec: ucsi: fix use-after-free caused by uec->work

[Duoming Zhou]

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

Re: [PATCH v2 2/2] usb: typec: ucsi: fix use-after-free caused by uec->work

[Greg KH]

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?

Re: [PATCH v2 2/2] usb: typec: ucsi: fix use-after-free caused by uec->work

[duoming]

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/

Re: [PATCH v2 2/2] usb: typec: ucsi: fix use-after-free caused by uec->work

[Greg KH]

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.

Re: [PATCH v2 1/2] usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()

[Heikki Krogerus]

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

Re: [PATCH v2 2/2] usb: typec: ucsi: fix use-after-free caused by uec->work

[Heikki Krogerus]

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

Re: [PATCH v2 1/2] usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()

[Greg KH]

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