CVE-2021-47274 in Linux
Сводка
по VulDB • 18.06.2026
В предоставленном логе и описании проблемы речь идет о баге в подсистеме трассировки ядра Linux (ftrace/kprobes), который приводит к выходу за границы буфера (out-of-bounds write).
### Анализ проблемы
1. **Симптомы**: * Падение ядра (Oops/Panic) при вызове `munmap` (через `do_munmap` -> `__split_vma` -> `anon_vma_clone`). * Однако, как указано в описании, корневая причина — **не** в `munmap` напрямую, а в **ftrace buffer out-of-bound access**. * Отладочный инструмент показал: `BUG: Out-of-bounds write at addr 0xffff88aefe8b7000` в функции `strncpy_from_unsafe`, которая вызывается из `fetch_memory_string` -> `fetch_deref_string` -> `kprobe_trace_func`.
2. **Корневая причина**: * В коде трассировки (ftrace/kprobes) происходит копирование строки из пользовательского или недоверенного адреса (`strncpy_from_unsafe`). * Ранее исправление `b220c049d519` ("tracing: Check length before giving out the filter buffer") добавило проверку длины, но **не учло размер элемента массива** (`sizeof(entry->array[0])`).
* Поле `entry->array[0]` содержит длину данных, но само выделение буфера или проверка длины не учитывали, что этот элемент массива занимает место в структуре, что может привести к переполнению буфера при определенных условиях.
3. **Почему это проявляется при `munmap`?** * Вероятно, `munmap` вызывает освобождение памяти, связанной с `anon_vma`, что может триггерить какие-то обратные вызовы или состояния, в которых активен ftrace/kprobe. * Или же `munmap` является лишь триггером, который приводит к выполнению кода, где установлен kprobe, и именно в момент обработки этого kprobe происходит переполнение буфера ftrace.
### Решение
Необходимо исправить проверку длины в коде трассировки, чтобы она учитывала размер элемента массива `entry->array[0]`.
#### Пример исправления (концептуальный)
В файле, где происходит выделение или проверка буфера для фильтра трассировки (вероятно, в `kernel/trace/trace_events_filter.c` или аналогичном), нужно изменить проверку длины.
**Было (неполная проверка):** ```c // Пример старой логики, которая не учитывает sizeof(entry->array[0])
if (len > FILTER_MAX_DATA_LEN) return -EINVAL; ```
**Стало (исправленная проверка):** ```c // Учитываем размер элемента массива, который также занимает место в буфере if (len + sizeof(entry->array[0]) > FILTER_MAX_DATA_LEN)
return -EINVAL; ```
Или, если проверка идет в другом месте (например, при копировании):
```c // При копировании данных в entry->array if (len > sizeof(entry->array) - sizeof(entry->array[0]))
return -EINVAL; ```
### Рекомендации
1. **Обновите ядро**: Если вы используете 4.19 LTS, проверьте, есть ли более свежие патчи в ветке 4.19.y, которые уже содержат это исправление. Проблема была найдена и, вероятно, исправлена в более новых версиях ядра. 2. **Отключите kprobes/ftrace для критичных участков**: Если обновление ядра невозможно, попробуйте отключить kprobes и ftrace для системных вызовов, связанных с управлением памятью (`munmap`, `mmap`, `mprotect`), чтобы избежать триггера бага. 3. **Проверьте патчи**: Ищите патчи с ключевыми словами: * `tracing: Fix ftrace buffer overflow in kprobe` * `tracing: Account for sizeof(entry->array[0]) in length check`
* `tracing: Fix out-of-bounds write in fetch_deref_string`
### Заключение
Проблема является уязвимостью безопасности (переполнение буфера в ядре), которая может привести к повышению привилегий или отказу в обслуживании. Исправление заключается в корректной проверке длины с учетом размера структуры данных в
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.