CVE-2026-45912

Published: Mag 27, 2026 Last Modified: Mag 27, 2026

ExploitDB:

Other exploit source:

Google Dorks:

Description

AI Translation Available

In the Linux kernel, the following vulnerability has been resolved:

ext4: don't cache extent during splitting extent

Caching extents during the splitting process is risky, as it may result
in stale extents remaining in the status tree. Moreover, in most cases,
the corresponding extent block entries are likely already cached before
the split happens, making caching here not particularly useful.

Assume we have an unwritten extent, and then DIO writes the first half.

[UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent
[UUUUUUUUUUUUUUUU] extent status tree
|<- ->| ----> dio write this range

First, when ext4_split_extent_at() splits this extent, it truncates the
existing extent and then inserts a new one. During this process, this
extent status entry may be shrunk, and calls to ext4_find_extent() and
ext4_cache_extents() may occur, which could potentially insert the
truncated range as a hole into the extent status tree. After the split
is completed, this hole is not replaced with the correct status.

[UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent
[UUUUUUU|HHHHHHHH] extent status tree H: hole

Then, the outer calling functions will not correct this remaining hole
extent either. Finally, if we perform a delayed buffer write on this
latter part, it will re-insert the delayed extent and cause an error in
space accounting.

In adition, if the unwritten extent cache is not shrunk during the
splitting, ext4_cache_extents() also conflicts with existing extents
when caching extents. In the future, we will add checks when caching
extents, which will trigger a warning. Therefore, Do not cache extents
that are being split.

AI Generated Translation

Nel kernel Linux, è stata risolta la seguente vulnerabilità:

ext4: non memorizzare in cache l'estensione durante la divisione dell'estensione

Memorizzare in cache le estensioni durante il processo di divisione è rischioso, poiché può portare a rimanere con estensioni obsolete nel tree di stato. Inoltre, nella maggior parte dei casi, le corrispondenti voci di blocco dell'estensione sono già probabilmente in cache prima che avvenga la divisione, rendendo la memorizzazione in cache in questa fase poco utile.

Supponiamo di avere un'estensione non scritta, e successivamente DIO scrive la prima metà.

[UUUUUUUUUUUUUUUU] estensione su disco U: estensione non scritta
[UUUUUUUUUUUUUUUU] albero di stato dell'estensione
|<- ->| ----> scrittura DIO su questo intervallo

Innanzitutto, quando ext4_split_extent_at() divide questa estensione, tronca l'estensione esistente e ne inserisce una nuova. Durante questo processo, questa voce di stato dell'estensione può essere ridimensionata, e possono verificarsi chiamate a ext4_find_extent() e ext4_cache_extents(), che potrebbero potenzialmente inserire l'intervallo troncato come un buco nell'albero di stato dell'estensione. Dopo che la divisione è completata, questo buco non viene sostituito con lo stato corretto.

[UUUUUUU|UUUUUUUU] estensione su disco U: estensione non scritta
[UUUUUUU|HHHHHHHH] albero di stato dell'estensione H: buco

Successivamente, le funzioni chiamanti esterne non correggeranno nemmeno questo buco residuo. Infine, se si esegue una scrittura buffer differita su questa parte, questa reinserirà l'estensione differita causando un errore nel conteggio dello spazio.

Inoltre, se la cache delle estensioni non scritte non viene ridimensionata durante la divisione, ext4_cache_extents() può entrare in conflitto con le estensioni esistenti durante la memorizzazione in cache delle estensioni. In futuro, verranno aggiunti controlli durante la memorizzazione in cache delle estensioni, che attiveranno un avviso. Pertanto, non bisogna memorizzare in cache le estensioni che vengono suddivise.