CVE-2026-80886

Vulnérabilité non évaluée dans Linux (Linux)

CVSS 0.0 · Non évaluée
EPSS 0.2%
Linux•Linux•Versions : <=6.1.*, 7.1.5, 6.18.40, <=6.12.*, <abc1926c88c189e5d698b91ed6890e09ab5c321d, <22dd2777e6c180e1c945b00f6d18550979436324, 0, <e3b42e326f4f30efcdc90bad5f5ba37e1cd91a47, <=7.1.*, <6acea62738ed4cae6746483026706a773b44dad7, 4.4, 6.1.178, <=5.10.*, <=6.6.*, 6.12.97, 3a878c430fd6eb4f8587f9ebd187f773bf85d1d6, <=6.18.*, <2727744ccb5ca59090451451ee94f530b1be04a5, 5.15.212, <d354716245192de2d203f2b35f22ab8dc13595e2, 6.6.145, 5.10.261, <f58e568dc308c8e13f7730c8de2da5ed514e540d, <bb4296de5b538b575978c588cb3738ab8524d01a, <=*, <=5.15.*, 7.2, <4.4

Description

In the Linux kernel, the following vulnerability has been resolved: serial: msm: Disable DMA for kernel console UART At the moment, concurrent writes from userspace and the kernel to the console can trigger a race condition that results in an infinite loop of the same messages printed over and over again. This is most likely to happen during system startup or shutdown when the init system starts/stops a large number of system services that interact with various kernel code. When userspace writes to the TTY device, the driver initiates an asynchronous DMA transfer and releases the port lock. At the same moment, the kernel printk path might grab the port lock and re-configure the UART controller for PIO, without waiting for the DMA operation to complete. It seems like this collision results in zero progress being reported for the DMA engine, so the same text is printed to the console over and over again. For the kernel console, we want a reliable output path that will be functional even during crashes etc. So rather than implementing complex code to synchronize the kernel console write routines with the userspace DMA write routines, simply disable DMA for the console UART instance. Similar checks exist in many other serial drivers, e.g. 8250_port.c, imx.c, sh-sci.c etc.

Gravité et risque d'exploitation

CVE-2026-80886 obtient un score CVSS de 0.0/10, soit une gravité non évaluée. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.22 %, ce qui la place devant 11.7 % des CVE référencées.

Que faire ?

  • Vérifiez si Linux (versions <=6.1.*, 7.1.5, 6.18.40, <=6.12.*, <abc1926c88c189e5d698b91ed6890e09ab5c321d, <22dd2777e6c180e1c945b00f6d18550979436324, 0, <e3b42e326f4f30efcdc90bad5f5ba37e1cd91a47, <=7.1.*, <6acea62738ed4cae6746483026706a773b44dad7, 4.4, 6.1.178, <=5.10.*, <=6.6.*, 6.12.97, 3a878c430fd6eb4f8587f9ebd187f773bf85d1d6, <=6.18.*, <2727744ccb5ca59090451451ee94f530b1be04a5, 5.15.212, <d354716245192de2d203f2b35f22ab8dc13595e2, 6.6.145, 5.10.261, <f58e568dc308c8e13f7730c8de2da5ed514e540d, <bb4296de5b538b575978c588cb3738ab8524d01a, <=*, <=5.15.*, 7.2, <4.4) est présent sur votre parc.
  • Appliquez le correctif ou la version corrigée indiqués dans les références de l'éditeur.
  • À défaut de correctif, limitez l'exposition (filtrage réseau, désactivation du composant).
  • Automatisez la détection : les agents CVE Heimdall (gratuits, open source) corrèlent l'inventaire de vos serveurs avec la base CVE.

Références