CVE-2025-21902

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> acpi: typec: ucsi: Introduce a -&gt;poll_cci method<br /> <br /> For the ACPI backend of UCSI the UCSI "registers" are just a memory copy<br /> of the register values in an opregion. The ACPI implementation in the<br /> BIOS ensures that the opregion contents are synced to the embedded<br /> controller and it ensures that the registers (in particular CCI) are<br /> synced back to the opregion on notifications. While there is an ACPI call<br /> that syncs the actual registers to the opregion there is rarely a need to<br /> do this and on some ACPI implementations it actually breaks in various<br /> interesting ways.<br /> <br /> The only reason to force a sync from the embedded controller is to poll<br /> CCI while notifications are disabled. Only the ucsi core knows if this<br /> is the case and guessing based on the current command is suboptimal, i.e.<br /> leading to the following spurious assertion splat:<br /> <br /> WARNING: CPU: 3 PID: 76 at drivers/usb/typec/ucsi/ucsi.c:1388 ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi]<br /> CPU: 3 UID: 0 PID: 76 Comm: kworker/3:0 Not tainted 6.12.11-200.fc41.x86_64 #1<br /> Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN45WW 03/17/2023<br /> Workqueue: events_long ucsi_init_work [typec_ucsi]<br /> RIP: 0010:ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi]<br /> Call Trace:<br /> <br /> ucsi_init_work+0x3c/0xac0 [typec_ucsi]<br /> process_one_work+0x179/0x330<br /> worker_thread+0x252/0x390<br /> kthread+0xd2/0x100<br /> ret_from_fork+0x34/0x50<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Thus introduce a -&gt;poll_cci() method that works like -&gt;read_cci() with an<br /> additional forced sync and document that this should be used when polling<br /> with notifications disabled. For all other backends that presumably don&amp;#39;t<br /> have this issue use the same implementation for both methods.