CVE-2026-89830
UnknownSummary
In the Linux kernel, __allocate_data_block() in the f2fs filesystem increments the valid block count via inc_valid_block_count() when allocating a new data block, but if the subsequent f2fs_allocate_data_block() fails, the function returns the error without rolling back that increment. This causes a permanent valid block count leak.
Risk Assessment
The block count leak can lead to incorrect free-space accounting and potentially to integrity or availability issues in the f2fs filesystem.
Recommendation
Update the Linux kernel to a version containing the fix that calls dec_valid_block_count() to undo the increment before returning the error.
Other vulnerabilities in Linux kernel (f2fs)
See all- CVE-2026-93235Unknown
A flaw was found in the Linux kernel F2FS filesystem where extending a file size across an unaligned EOF boundary did not zero out post-EOF data in the partial page. As a result, stale disk data beyond the previous EOF could be exposed after remounting or crash recovery.
- CVE-2026-89829High
In the Linux kernel, f2fs_sanity_check_node_footer() is not passed the correct folio->index value, causing it to check the same nid incorrectly. This can lead to improper node consistency verification in the f2fs filesystem.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix valid block count leak on data block allocation failure In __allocate_data_block(), when allocating a new data block (dn->data_blkaddr == NULL_ADDR), inc_valid_block_count() is called first to increment total_valid_block_count and i_blocks. If the subsequent f2fs_allocate_data_block() fails, the function returns the error directly without rolling back the already-incremented block counts, causing a permanent leak. Fix this by calling dec_valid_block_count() to undo the increment before returning the error. The condition old_blkaddr == NULL_ADDR precisely identifies the case where inc_valid_block_count() was called.