GHSA-F3WR-G9F6-6VGF
Vulnerability from github – Published: 2026-09-04 18:31 – Updated: 2026-09-04 18:31In 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.
{
"affected": [],
"aliases": [
"CVE-2026-80886"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-04T17:17:01Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nserial: msm: Disable DMA for kernel console UART\n\nAt the moment, concurrent writes from userspace and the kernel to the\nconsole can trigger a race condition that results in an infinite loop of\nthe same messages printed over and over again. This is most likely to\nhappen during system startup or shutdown when the init system starts/stops\na large number of system services that interact with various kernel code.\n\nWhen userspace writes to the TTY device, the driver initiates an\nasynchronous DMA transfer and releases the port lock. At the same moment,\nthe kernel printk path might grab the port lock and re-configure the UART\ncontroller for PIO, without waiting for the DMA operation to complete. It\nseems like this collision results in zero progress being reported for the\nDMA engine, so the same text is printed to the console over and over again.\n\nFor the kernel console, we want a reliable output path that will be\nfunctional even during crashes etc. So rather than implementing complex\ncode to synchronize the kernel console write routines with the userspace\nDMA write routines, simply disable DMA for the console UART instance.\n\nSimilar checks exist in many other serial drivers, e.g. 8250_port.c,\nimx.c, sh-sci.c etc.",
"id": "GHSA-f3wr-g9f6-6vgf",
"modified": "2026-09-04T18:31:32Z",
"published": "2026-09-04T18:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80886"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/22dd2777e6c180e1c945b00f6d18550979436324"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2727744ccb5ca59090451451ee94f530b1be04a5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6acea62738ed4cae6746483026706a773b44dad7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/abc1926c88c189e5d698b91ed6890e09ab5c321d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bb4296de5b538b575978c588cb3738ab8524d01a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d354716245192de2d203f2b35f22ab8dc13595e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e3b42e326f4f30efcdc90bad5f5ba37e1cd91a47"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f58e568dc308c8e13f7730c8de2da5ed514e540d"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.