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.
- Compensating control
Update the nouveau device-memory folio split handling so the split hook accounts for each new sub-folio by invoking nouveau_dmem_folio_split() once per sub-folio under the same lock, keeping chunk->callocated balanced with the subsequent per-sub-folio frees.
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.