CVE-2023-53317 in Linux
Сводка
по VulDB • 23.05.2026
В предоставленном стеке вызовов и отладочной информации описывается проблема в файловых системах ext4, связанная с некорректным состоянием битовой карты блоков (block bitmap).
### Анализ проблемы
1. **Стек вызовов**: * Процесс монтирования (`ext4_fill_super` -> `ext4_orphan_cleanup`) пытается инициализировать дискворы (dquot) для файлов. * Это приводит к записи квот (`ext4_quota_write` -> `ext4_bread` -> `ext4_getblk`). * `ext4_getblk` вызывает `ext4_map_blocks`, который пытается выделить новые блоки (`ext4_mb_new_blocks`). * Выделение блоков происходит через механизм многоуровневого выделения (`mballoc`).
2. **Отладочная информация**: * `mb_find_extent block=41, order=0 needed=64`: Система пытается выделить 64 блока (один блок группы), начиная с блока 41. * `ex=0/41/1@3735929054`: Указывает на существующее экстент-дескриптор или состояние. * `block_bitmap: ff 3f 0c 00 fc 01 00 00 ...`: Это дамп битовой карты. * Биты `0xff` (11111111) в начале означают, что первые 8 блоков помечены как **занятые**. * Однако, судя по контексту (`blocks per group is 64`), битовая карта должна соответствовать размеру группы блоков. * Утверждение: *"Actually, blocks per group is 64, but block bitmap indicate at least has 128 blocks"* указывает на рассинхронизацию между метаданными суперблока (размер группы) и фактическим содержимым битовой карты. Возможно, битовая карта содержит данные, выходящие за пределы допустимого диапазона для группы из 64 блоков, или биты "padding" (заполнителя) в конце битовой карты не сброшены, хотя должны быть.
3. **Суть бага**: * Функция `ext4_validate_block_bitmap()` не проверяет корректность битов, которые должны быть сброшены (равны 0), если они находятся за пределами реального количества блоков в группе или являются служебными (padding). * Это приводит к тому, что `mballoc` видит "занятые" блоки там, где их быть не должно, или интерпретирует битовую карту некорректно, что вызывает ошибки при выделении или проверке целостности.
### Решение
Необходимо добавить проверку в функцию `ext4_validate_block_bitmap()` (или в смежную функцию в `fs/ext4/mballoc.c`), которая будет проверять, что все биты в битовой карте, выходящие за пределы `blocks_per_group`, сброшены в 0. Это аналогично проверке, которую выполняет утилита `e2fsck` с сообщением *"Padding at end of block bitmap is not set"*.
### Пример исправления (концептуальный)
В файле `fs/ext4/mballoc.c` или `fs/ext4/balloc.c` нужно найти функцию валидации битовой карты и добавить проверку:
```c // Примерная логика внутри ext4_validate_block_bitmap() или аналогичной функции
static int ext4_validate_block_bitmap(struct super_block *sb, struct ext4_group_desc *gdp, ext4_group_t block_group, struct buffer_head *bh) {
struct ext4_sb_info *sbi = EXT4_SB(sb); ext4_grpblk_t offset; unsigned long *bitmap = (unsigned long *)bh->b_data; ext4_fsblk_t group_first_block = ext4_group_first_block_no(sb, block_group); ext4_fsblk_t group_last_block = group_first_block + sbi->s_blocks_per_group - 1; int bits_per_group = sbi->s_blocks_per_group; int bytes_per_group = BITS_TO_LONGS(bits_per_group) * sizeof(long);
// ... существующие проверки ...
// НОВАЯ ПРОВЕРКА: Проверка padding в конце битовой карты // Битовая карта должна иметь размер, достаточный для покрытия всех блоков группы. // Все биты после последнего блока группы должны быть равны 0. // Вычисляем количество полных слов (long) в битовой карте int full_words = bits_per_group / BITS_PER_LONG; int remaining_bits =
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.