CVE-2026-74441

In the Linux kernel, the following vulnerability has been resolved:

usb: typec: ucsi: Fix race condition and ordering in port unregistration

A synchronization issue exists during port unregistration where pending partner work items can race against workqueue destruction, leading to use-after-free conditions:

crosecucsi crosecucsi.3.auto: error -ETIMEDOUT: PPM init failed BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:__queue_work+0x83/0x4a0 Call Trace: <IRQ> __cfidelayedworktimerfn+0x10/0x10 runtimersoftirq+0x3b6/0xbd0 schedclockcpu+0xc/0x110 irqexitrcu+0x18d/0x330 fredsysvecapictimerinterrupt+0x5e/0x80

Fix this by ensuring strict ordering and proper serialization during teardown:

1. Move ucsiunregisterpartner() to the beginning of the teardown sequence and protect it under the connector mutex lock.
2. Ensure all pending partner tasks are explicitly flushed and finished before the workqueue is destroyed.

3. Switch from moddelayedwork() to a canceldelayedwork() and queuedelayedwork() sequence. This guarantees that items currently marked as pending won't be scheduled an additional time, preventing a double release of resources which leads to the following crash:

   Oops: general protection fault, probably for non-canonical address 0xdead000000000122: 0000 [#1] SMP NOPTI Workqueue: crosecucsi.3.auto-con2 ucsipollworker RIP: 0010:ucsipollworker+0x65/0x1e0 Call Trace: <TASK> processscheduledworks+0x218/0x6d0 worker_thread+0x188/0x3f0 __cfiworkerthread+0x10/0x10 kthread+0x226/0x2a0

To ensure these rules are applied identically across both the normal teardown and the ucsiinit() error paths, consolidate the cleanup logic into a new helper, ucsiunregister_port().