Odebrany

CVE-2026-89493

opublikowano: 11.09.2026, 22:19

modyfikacja: 11.09.2026, 22:19

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

ocfs2: sprawdź poprawność rl_used względem rl_count w walidatorze bloku przeliczenia

ocfs2_find_refcount_rec_in_rl() przegląda tablicę rekordów refcount na dysku
z:

for (; i < le16_to_cpu(rb->rf_records.rl_used); i++) {
rec = &rb->rf_records.rl_recs[i];
...

rl_recs[] znajduje się w pojedynczym bloku metadanych (4096 bajtów w pliku Common
konfiguracja), więc jego rzeczywista pojemność jest ustalana przez
ocfs2_refcount_recs_per_rb(sb) (247 rekordów dla bloku 4K z
16-bajtowy ocfs2_refcount_rec). Zarówno rl_used, jak i rl_count są odczytywane bezpośrednio
wyłączone z dysku przez ocfs2_validate_refcount_block() i nigdy nie są sprawdzane
tej zdolności, ani przeciwko sobie, przed jakimkolwiek przeliczeniem/reflinkem/CoW
operacja chodzi po tablicy.

Stworzony (lub uszkodzony) blok przeliczenia z rl_used == 0xffff powoduje, że
pętla powyżej przejdź daleko poza koniec bloku, dereferując rl_recs[i]
dla i aż do 65534. Wynikowy indeks jest następnie przekazywany rodzeństwa
ocfs2_insert_refcount_rec(), której przesunięcie wstawiania powoduje:

if (indeks < le16_to_cpu(rf_list->rl_used))
memmove(&rf_list->rl_recs[indeks + 1],
&rf_list->rl_recs[indeks],
(le16_to_cpu(rf_list->rl_used) - indeks) *
sizeof(struct ocfs2_refcount_rec));

tj. memmove() o wielkości do (0xffff - indeks) * 16 bajtów (~1 MiB) z
przesunięte już za blok. Można to osiągnąć za pomocą zwykłego linku zwrotnego
(FICLONE) przeciwko spreparowanemu/uszkodzonemu obrazowi ocfs2: dołączanie zakresu
którego cpos sortuje każdy prawdziwy rekord w liściu, wymuszając wyszukiwanie
uciec do końca, zamiast wracać na początku meczu. Model napastnika
jest lokalny: CAP_SYS_ADMIN montuje spreparowany lub uszkodzony obraz ocfs2, lub a
surowy zapis na urządzeniu blokowym obsługującym już zamontowany system plików ocfs2.

ocfs2_validate_refcount_block() już sprawdza ECC bloku,
podpis, rf_blkno i rf_fs_generacja, ale nigdy rl_count/rl_used
względem rzeczywistej pojemności bloku na dysku. To jest ta sama klasa
luka, którą ocfs2_validate_extent_block() (fs/ocfs2/alloc.c) już zamyka
dla nagłówka listy rozszerzeń rodzeństwa, który sprawdza pojemność rekordów
i „used” powiązane przed jakimkolwiek kodem h_list.l_recs[]:

if (le16_to_cpu(eb->h_list.l_count) != ocfs2_extent_recs_per_eb(sb)) {
rc = ocfs2_error(...);
muszę wyjść za kaucją;
}

if (le16_to_cpu(eb->h_list.l_next_free_rec) >
le16_to_cpu(eb->h_list.l_count)) {
rc = ocfs2_error(...);
muszę wyjść za kaucją;
}

Dodaj równoważną parę kontroli do ocfs2_validate_refcount_block():
odrzuć blok refcount, którego rl_count nie pasuje do ustalonej liczby bloków
pojemność zwrócona przez ocfs2_refcount_recs_per_rb() i odrzuć rl_used >
rl_count. Obie kontrole są pomijane, gdy ustawiono OCFS2_REFCOUNT_TREE_FL,
ponieważ w tym przypadku te same bajty unii zawierają listę ocfs2_extent_list
(rf_list), a nie lista rekordów refcount (rf_records) - taki jest układ
już zweryfikowane oddzielnie przez ocfs2_validate_extent_block(), gdy
odczytywany jest odnośny blok zakresu. Odzwierciedla to istniejące
Strażnik „!(rb->rf_flags & OCFS2_REFCOUNT_TREE_FL)” używany gdzie indziej w tym
plik (np. ocfs2_get_refcount_rec()), aby zdecydować, czy rf_records czy
rf_list jest żywym członkiem związku.

Dzięki temu sfałszowany rl_used/rl_count zostaje złapany w bloku
czas sprawdzania poprawności (ocfs2_error()), spójny z każdym innym uszkodzeniem
sprawdź tę funkcję, zamiast wjeżdżać na aut z wczytaniem na aut
ocfs2_find_refcount_rec_in_rl() i kolejna memmove() poza zakresem
w ocfs2_insert_refcount_rec().

Zweryfikowano na podstawie spreparowanego obrazu w wersji 6.19 KASAN (KASAN_GENERIC):
ponowne odtworzenie tego samego reflinku (FICLONE) niezawodnie trafiło w raport KASAN
__ocfs2_increase_refcount()/ocfs2_insert_refcount_rec() przed tą poprawką,
i nie generuje żadnego raportu, gdy ocfs2_validate_refcount_block() odrzuci
sfałszowany rl_used/rl_count.

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

ocfs2: validate rl_used against rl_count in refcount block validator

ocfs2_find_refcount_rec_in_rl() walks the on-disk refcount record array
with:

for (; i < le16_to_cpu(rb->rf_records.rl_used); i++) {
rec = &rb->rf_records.rl_recs[i];
...

rl_recs[] lives in a single metadata block (4096 bytes on the common
configuration), so its real capacity is fixed by
ocfs2_refcount_recs_per_rb(sb) (247 records for a 4K block with the
16-byte ocfs2_refcount_rec). rl_used and rl_count are both read directly
off disk by ocfs2_validate_refcount_block() and are never checked against
that capacity, nor against each other, before any refcount/reflink/CoW
operation walks the array.

A crafted (or corrupted) refcount block with rl_used == 0xffff makes the
loop above walk far past the end of the block, dereferencing rl_recs[i]
for i up to 65534. The resulting index is then handed to the sibling
ocfs2_insert_refcount_rec(), whose insert-shift does:

if (index < le16_to_cpu(rf_list->rl_used))
memmove(&rf_list->rl_recs[index + 1],
&rf_list->rl_recs[index],
(le16_to_cpu(rf_list->rl_used) - index) *
sizeof(struct ocfs2_refcount_rec));

i.e. a memmove() of up to (0xffff - index) * 16 bytes (~1 MiB) from an
offset already past the block. This is reachable from an ordinary reflink
(FICLONE) against a crafted/corrupted ocfs2 image: attaching an extent
whose cpos sorts past every real record in the leaf forces the lookup to
run off the end instead of returning early on a match. The attacker model
is local: CAP_SYS_ADMIN mounting a crafted or corrupted ocfs2 image, or a
raw write to the block device backing an already-mounted ocfs2 filesystem.

ocfs2_validate_refcount_block() already validates the block's ECC,
signature, rf_blkno and rf_fs_generation, but never rl_count/rl_used
against the block's actual on-disk capacity. This is the same class of
gap that ocfs2_validate_extent_block() (fs/ocfs2/alloc.c) already closes
for the sibling extent-list header, which checks both the record capacity
and the "used" bound before any code walks h_list.l_recs[]:

if (le16_to_cpu(eb->h_list.l_count) != ocfs2_extent_recs_per_eb(sb)) {
rc = ocfs2_error(...);
goto bail;
}

if (le16_to_cpu(eb->h_list.l_next_free_rec) >
le16_to_cpu(eb->h_list.l_count)) {
rc = ocfs2_error(...);
goto bail;
}

Add the equivalent pair of checks to ocfs2_validate_refcount_block():
reject a refcount block whose rl_count does not match the fixed per-block
capacity returned by ocfs2_refcount_recs_per_rb(), and reject rl_used >
rl_count. Both checks are skipped when OCFS2_REFCOUNT_TREE_FL is set,
because in that case the same union bytes hold an ocfs2_extent_list
(rf_list), not the refcount record list (rf_records) -- that layout is
already validated separately by ocfs2_validate_extent_block() when the
referenced extent block is read. This mirrors the existing
"!(rb->rf_flags & OCFS2_REFCOUNT_TREE_FL)" guard used elsewhere in this
file (e.g. ocfs2_get_refcount_rec()) to decide whether rf_records or
rf_list is the live member of the union.

With this in place, a forged rl_used/rl_count is caught at block
validation time (ocfs2_error()), consistent with every other corruption
check in this function, instead of driving an out-of-bounds read in
ocfs2_find_refcount_rec_in_rl() and a subsequent out-of-bounds memmove()
in ocfs2_insert_refcount_rec().

Verified against a crafted image on a v6.19 KASAN (KASAN_GENERIC) build:
replaying the same reflink (FICLONE) reliably hit a KASAN report in
__ocfs2_increase_refcount()/ocfs2_insert_refcount_rec() before this patch,
and triggers no report once ocfs2_validate_refcount_block() rejects the
forged rl_used/rl_count.

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve