CVE-2026-93233: drm/nouveau/dmem: fix callocated underflow on large folio split
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/dmem: fix callocated underflow on large folio split
nouveaudmemfoliofree() drops chunk->callocated once per freed folio, while a large (compound) device-private folio is only counted once when it is allocated. When such a folio is split, the mm core invokes ->foliosplit() (nouveaudmemfoliosplit()) once for each new sub-folio, but the hook only fixes up the sub-folio metadata and leaves chunk->callocated unchanged.
Each resulting sub-folio is later freed separately, so after a split the single allocation (+1) is met by N frees (-N), leaving chunk->callocated short by N-1. On the first split/free cycle it underflows: WARNON(!chunk->callocated) fires, the unsigned counter wraps and never returns to zero, so the chunk can no longer be reclaimed (nouveaudmemfini() also warns on the leaked count).
Account for the new sub-folio in the split hook, under the same lock as nouveaudmemfoliofree(), so the count stays balanced.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
What conditions are required to trigger the accounting error?
A large compound device-private folio must be split, causing the memory-management core to invoke nouveau_dmem_folio_split() for each resulting sub-folio. Those sub-folios must later be freed separately for the allocation counter to underflow.
What is the operational impact once the counter underflows?
The WARN_ON(!chunk->callocated) check fires and the unsigned counter wraps. The affected chunk can no longer be reclaimed, and nouveau_dmem_fini() also warns about the leaked count.
How can an affected system be identified?
Look for WARN_ON(!chunk->callocated) during device-private folio frees, or warnings from nouveau_dmem_fini() reporting a leaked count. The issue is associated with a large device-private folio split followed by separate frees of its sub-folios.