В ядре Linux устранена следующая уязвимость:
f2fs: исправлено, чтобы избежать сопоставления неправильного физического блока для файла подкачки. Сяолун Го сообщил об ошибке f2fs в bugzilla [1]
[1] https://bugzilla.kernel.org/show_bug.cgi?id=220951
Цитата:
«При использовании стресс-теста подкачки стресс-нг в файловой системе F2FS с ядром 6.6+,
в системе происходит повреждение данных, что приводит к:
1 ошибка повреждения dm-verity и перезагрузка устройства
2 ошибки повреждения узла F2FS и зависание загрузки
Проблема возникает, в частности, когда:
1 Использование файловой системы F2FS (ext4 не затрагивается)
2 Размер файла подкачки меньше размера раздела F2FS (2 МБ).
3 Файл подкачки имеет фрагментированную физическую структуру (несколько несмежных экстентов).
4 Версия ядра 6.6+ (6.1 не затронута)
Основная причина находится в функции check_swap_activate() в fs/f2fs/data.c. Когда
первый экстент небольшого файла подкачки (< 2 МБ) не выровнен по границам раздела,
функция неправильно обрабатывает его как последний экстент и не может отобразить
последующие экстенты.
Это приводит к неправильному созданию swap_extent, где только
первый экстент отображается, в результате чего последующие записи подкачки перезаписываются неправильно
физическое расположение (данные других файлов). Шаги по воспроизведению
1. Настройте устройство с разделом пользовательских данных в формате F2FS.
2.
Скомпилируйте стресс-ng с https://github.com/ColinIanKing/stress-ng.
3. Запустите стресс-тест подкачки: (устройства Android)
оболочка adb "cd /data/stressng; ./stress-ng-64 --metrics-brief --timeout 60
--поменять 0"
Журнал:
1 Ftrace отображается в ядре 6.6, во втором отображается только первый экстент.
f2fs_map_blocks вызывает функцию check_swap_activate():
стресс-нг-своп-8990: f2fs_map_blocks: ino=11002, смещение файла=0, начало
блкадр=0x43143, длина=0x1
(Сопоставлено только 4 КБ, а не полный файл подкачки)
2 в ядре 6.1 оба экстента отображаются правильно:
стресс-нг-своп-5966: f2fs_map_blocks: ino=28011, смещение файла=0, начало
блкадр=0x13cd4, длина=0x1
стресс-нг-своп-5966: f2fs_map_blocks: ino=28011, смещение файла=1, начало
блкадр=0x60c84b, лен=0xff
Проблемный код находится в check_swap_activate():
if ((pblock - SM_I(sbi)->main_blkaddr) % blks_per_sec ||
nr_pblocks % blks_per_sec ||
!f2fs_valid_pinned_area(sbi, pblock)) {
bool Last_extent = ложь;
not_aligned++;
nr_pblocks = округление (nr_pblocks, blks_per_sec);
if (cur_lblock + nr_pblocks > sis->max)
nr_pblocks -= blks_per_sec;
/* этот экстент последний */
если (!nr_pblocks) {
nr_pblocks = Last_lblock - cur_lblock;
последний_экстент = правда;
}
ret = f2fs_migrate_blocks (inode, cur_lblock, nr_pblocks);
если (рет) {
если (рет == -ENOENT)
Рет = -ЭИНВАЛ;
выйти;
}
если (!last_extent)
перейти к повторной попытке;
}
Когда первый экстент не выровнен и округлен (nr_pblocks, blks_per_sec)
превышает sis->max, мы вычитаем blks_per_sec, в результате чего nr_pblocks = 0.
код ошибочно предполагает, что это последний экстент, устанавливает nr_pblocks =
Last_lblock — cur_lblock (весь файл подкачки) и выполняет миграцию. После
При миграции он не повторяет попытку сопоставления, поэтому последующие экстенты никогда не обрабатываются.
"
Чтобы решить эту проблему, нам нужно найти информацию о сопоставлении блоков после
мы переносим все блоки в хвосте файла подкачки.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid mapping wrong physical block for swapfile Xiaolong Guo reported a f2fs bug in bugzilla [1] [1] https://bugzilla.kernel.org/show_bug.cgi?id=220951 Quoted: "When using stress-ng's swap stress test on F2FS filesystem with kernel 6.6+, the system experiences data corruption leading to either: 1 dm-verity corruption errors and device reboot 2 F2FS node corruption errors and boot hangs The issue occurs specifically when: 1 Using F2FS filesystem (ext4 is unaffected) 2 Swapfile size is less than F2FS section size (2MB) 3 Swapfile has fragmented physical layout (multiple non-contiguous extents) 4 Kernel version is 6.6+ (6.1 is unaffected) The root cause is in check_swap_activate() function in fs/f2fs/data.c. When the first extent of a small swapfile (< 2MB) is not aligned to section boundaries, the function incorrectly treats it as the last extent, failing to map subsequent extents. This results in incorrect swap_extent creation where only the first extent is mapped, causing subsequent swap writes to overwrite wrong physical locations (other files' data). Steps to Reproduce 1 Setup a device with F2FS-formatted userdata partition 2 Compile stress-ng from https://github.com/ColinIanKing/stress-ng 3 Run swap stress test: (Android devices) adb shell "cd /data/stressng; ./stress-ng-64 --metrics-brief --timeout 60 --swap 0" Log: 1 Ftrace shows in kernel 6.6, only first extent is mapped during second f2fs_map_blocks call in check_swap_activate(): stress-ng-swap-8990: f2fs_map_blocks: ino=11002, file offset=0, start blkaddr=0x43143, len=0x1 (Only 4KB mapped, not the full swapfile) 2 in kernel 6.1, both extents are correctly mapped: stress-ng-swap-5966: f2fs_map_blocks: ino=28011, file offset=0, start blkaddr=0x13cd4, len=0x1 stress-ng-swap-5966: f2fs_map_blocks: ino=28011, file offset=1, start blkaddr=0x60c84b, len=0xff The problematic code is in check_swap_activate(): if ((pblock - SM_I(sbi)->main_blkaddr) % blks_per_sec || nr_pblocks % blks_per_sec || !f2fs_valid_pinned_area(sbi, pblock)) { bool last_extent = false; not_aligned++; nr_pblocks = roundup(nr_pblocks, blks_per_sec); if (cur_lblock + nr_pblocks > sis->max) nr_pblocks -= blks_per_sec; /* this extent is last one */ if (!nr_pblocks) { nr_pblocks = last_lblock - cur_lblock; last_extent = true; } ret = f2fs_migrate_blocks(inode, cur_lblock, nr_pblocks); if (ret) { if (ret == -ENOENT) ret = -EINVAL; goto out; } if (!last_extent) goto retry; } When the first extent is unaligned and roundup(nr_pblocks, blks_per_sec) exceeds sis->max, we subtract blks_per_sec resulting in nr_pblocks = 0. The code then incorrectly assumes this is the last extent, sets nr_pblocks = last_lblock - cur_lblock (entire swapfile), and performs migration. After migration, it doesn't retry mapping, so subsequent extents are never processed. " In order to fix this issue, we need to lookup block mapping info after we migrate all blocks in the tail of swapfile.