CVE-2024-56582 in Linux
Сводка
по VulDB • 05.06.2026
В предоставленном дампе KASAN (Kernel Address Sanitizer) отчет об ошибке **Use-After-Free** (использование памяти после освобождения) в подсистеме **Btrfs**, конкретно в функции `btrfs_ioctl_send` (которая используется для отправки снимков файловой системы, например, через `btrfs send`).
### Краткий анализ проблемы
1. **Суть ошибки**: * Процесс пытается прочитать/использовать память (`read`/`access`), которая уже была освобождена (`kfree`). * Ошибка происходит в функции `btrfs_encoded_read_regular_fill_pages` (или связанной с ней цепочке вызовов), которая вызывается из `send_extent_data` -> `process_extent` -> `changed_cb` -> `btrfs_ioctl_send`.
2. **Объект памяти**: * Размер объекта: **96 байт**. * Кэш аллокатора: `kmalloc-rnd-07-96`. * Адрес объекта: `ffff888106a83f00`. * Ошибка доступа происходит по адресу `ffff888106a83f00 + 24` байта (то есть внутри объекта, но не на его границе).
3. **Цепочка освобождения (Freed by task 3661)**: * Память была освобождена через `kfree` в функции `btrfs_encoded_read_regular_fill_pages`. * Это указывает на то, что в процессе отправки снимка (`btrfs send`) был выделен буфер, который затем был освобожден, но какой-то другой поток или часть кода все еще пытается к нему обратиться.
4. **Цепочка использования (Allocated by task ...)**: * В вашем сообщении эта часть обрезана (`---truncated---`), но обычно она показывает, где память была выделена. Если она была выделена в том же потоке, что и освобождена, это может быть ошибка логики (например, двойное освобождение или использование после освобождения в одном потоке). Если в другом — это гонка данных (race condition).
---
### Возможные причины
1. **Гонка данных (Race Condition)**: * `btrfs send` работает с данными файловой системы. Если структура данных Btrfs изменяется (например, происходит запись, удаление или перенос extent) в то же время, когда `btrfs send` пытается прочитать эти данные, может возникнуть ситуация, когда указатель на буфер становится недействительным. * Особенно вероятно, если `btrfs send` использует асинхронные операции или если есть несколько потоков, работающих с одним и тем же снимком.
2. **Ошибка в логике освобождения буфера**: * В функции `btrfs_encoded_read_regular_fill_pages` память освобождается через `kfree`. Возможно, указатель на эту память сохраняется где-то еще (например, в структуре extent или в очереди обработки), и когда она освобождается, другие части кода продолжают на нее ссылаться.
3. **Баг в версии ядра**: * Такие ошибки часто являются известными багами в определенных версиях ядра Linux, особенно в подсистеме Btrfs, которая активно развивается.
---
### Что делать?
#### 1. Обновите ядро Это наиболее вероятное решение. Ошибки Use-After-Free в Btrfs `send` были исправлены в нескольких обновлениях ядра. * Проверьте версию вашего ядра. * Обновитесь до последней стабильной версии ядра (или хотя бы до версии, которая содержит патчи для Btrfs после даты, когда вы столкнулись с ошибкой). * Если вы используете дистрибутив, проверьте наличие обновлений ядра в репозиториях.
#### 2. Избегайте `btrfs send` во время интенсивных операций записи Если ошибка воспроизводится только при определенных условиях, попробуйте: * Не запускать `btrfs send` во время активной записи данных в файловую систему. * Использовать снимки (snapshots) для отправки: создайте снимок, а затем отправляйте данные именно с него. Это изолирует данные от изменений в основной файловой системе.
#### 3. Проверьте целостность файловой системы Хотя это не устранит ошибку в коде ядра, полезно убедиться, что нет повреждений данных: ```bash sudo btrfs check /dev/your_device ```
#### 4. Соберите полную информацию для отчета об ошибке Если вы хотите сообщить об ошибке разработ
VulDB is the best source for vulnerability data and more expert information about this specific topic.