CVE-2025-21902 in Linux
Sumário
de VulDB • 29/06/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
acpi: typec: ucsi: Introduzir um método ->poll_cci
Para o backend ACPI do UCSI, os "registradores" do UCSI são apenas uma cópia em memória dos valores dos registradores em uma opregion. A implementação ACPI na BIOS garante que o conteúdo da opregion seja sincronizado com o controlador embutido e assegura que os registradores (em particular CCI) sejam sincronizados de volta para a opregion nas notificações. Embora exista uma chamada ACPI que sincroniza os registradores reais com a opregion, raramente há necessidade de fazer isso e, em algumas implementações ACPI, isso realmente causa falhas de várias maneiras interessantes.
A única razão para forçar uma sincronização do controlador embutido é sondar o CCI enquanto as notificações estão desabilitadas. Apenas o núcleo ucsi sabe se este é o caso e adivinhar com base no comando atual é subideal, ou seja, levando ao seguinte aviso espúrio:
WARNING: CPU: 3 PID: 76 at drivers/usb/typec/ucsi/ucsi.c:1388 ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi]
CPU: 3 UID: 0 PID: 76 Comm: kworker/3:0 Not tainted 6.12.11-200.fc41.x86_64 #1 Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN45WW 03/17/2023 Workqueue: events_long ucsi_init_work [typec_ucsi]
RIP: 0010:ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi]
Call Trace: <TASK> ucsi_init_work+0x3c/0xac0 [typec_ucsi]
process_one_work+0x179/0x330 worker_thread+0x252/0x390 kthread+0xd2/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK>
Assim, introduz-se um método ->poll_cci() que funciona como o ->read_cci(), com uma sincronização forçada adicional e documenta-se que este deve ser usado ao sondar com notificações desabilitadas. Para todos os outros backends que presumivelmente não têm esse problema, usa-se a mesma implementação para ambos os métodos.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.