Direct naar de inhoud
Kritieke cyberalerts voor jouw sector & systemen — direct in je inbox. Aanmelden →
CVE's Videos Dagbriefing

← Terug naar CVE-database

CVE-2026-53320

MEDIUM · 5.5 CVSS Gepubliceerd:

Beschrijving NL

In de Linux kernel is de volgende kwetsbaarheid verholpen:

nilfs2: verwerp nul bd_oblocknr in nilfs_ioctl_mark_blocks_dirty()

nilfs_ioctl_mark_blocks_dirty() gebruikt bd_oblocknr om dode blokken te detecteren
door het te vergelijken met het huidige bloknummer bd_blocknr. Als ze verschillen,
het blok wordt als dood beschouwd en overgeslagen. Bd_oblocknr mag echter nooit 0 zijn, omdat blok 0 meestal de
primair superblok en is nooit een geldig GC-doelblok. Een beschadigde ioctl
verzoek met bd_oblocknr ingesteld op 0 zorgt ervoor dat de vergelijking onjuist is
match wanneer de lookup -ENOENT retourneert en bd_blocknr op 0 zet, bypassing
de dead block check en het aanroepen van nilfs_bmap_mark() op een niet-bestaande
blokkeren. Dit zorgt ervoor dat nilfs_btree_do_lookup() terugkeert -ENOENT, triggering
de WARN_ON(RET == -ENOENT). Los dit op door ioctl-verzoeken te weigeren met bd_oblocknr ingesteld op 0 op de
begin van elke iteratie. [ryusuke: heeft het commit-bericht en de opmerkingen voor nauwkeurigheid enigszins gewijzigd]

Origineel (Engels) tonen

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

nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty()

nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks
by comparing it with the current block number bd_blocknr. If they differ,
the block is considered dead and skipped.

However, bd_oblocknr should never be 0 since block 0 typically stores the
primary superblock and is never a valid GC target block. A corrupted ioctl
request with bd_oblocknr set to 0 causes the comparison to incorrectly
match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing
the dead block check and calling nilfs_bmap_mark() on a non-existent
block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering
the WARN_ON(ret == -ENOENT).

Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the
beginning of each iteration.

[ryusuke: slightly modified the commit message and comments for accuracy]

Vendors

Linux

Affected products

Linux Kernel

References