CVE-2024-50126 in Linux
Сводка
по VulDB • 21.05.2026
В предоставленном логе KASAN (Kernel Address SANitizer) описывается классическая ошибка **Use-After-Free (UAF)** в подсистеме сетевого планировщика `taprio` (Time-Aware Priority Shaper).
### Краткий анализ
1. **Суть ошибки:** Память была освобождена (`Freed by task 6192`), но затем к ней произошло обращение (`Allocated by task 15857` или, что более вероятно в контексте UAF, обращение произошло *после* освобождения, но KASAN показывает стек выделения для идентификации объекта). * *Примечание:* В логах KASAN обычно показываются два стека: один для выделения (`Allocated`), другой для освобождения (`Freed`). Если ошибка UAF, то чтение/запись произошло после `Freed`. В данном фрагменте показаны только стеки выделения и освобождения. Сам факт ошибки (например, `BUG: KASAN: use-after-free`) обычно находится выше или ниже этого фрагмента. Однако контекст указывает на проблему в `taprio`.
2. **Ключевые функции:** * **Выделение:** `taprio_change` -> `__kmalloc_cache_noprof` * Это происходит при изменении конфигурации Qdisc через `tc_modify_qdisc`. * **Освобождение:** `taprio_free_sched_cb` -> `kfree` * Это происходит в RCU-колбэке (`rcu_core`).
3. **Причина:** Ошибка возникает из-за неправильного управления жизненным циклом памяти в `taprio`. Вероятные сценарии: * **RCU-задержка:** Память освобождается в RCU-колбэке (`taprio_free_sched_cb`), но какой-то другой поток или прерывание все еще имеет ссылку на эту память и пытается ее использовать. * **Гонка (Race Condition):** Между моментом, когда конфигурация помечена на удаление, и моментом, когда RCU-колбэк действительно освобождает память, другой поток (`task 15857`) может попытаться получить доступ к старой конфигурации. * **Неправильное использование `rcu_read_lock()`:** Если код, использующий память, не захвачен в RCU-критическую секцию, он может получить доступ к уже освобожденной памяти.
### Детальный разбор стеков
#### Стек выделения (Task 15857): ``` taprio_change -> tc_modify_qdisc -> rtnetlink_rcv_msg -> ... -> __arm64_sys_sendmsg ``` Это стандартный путь изменения сетевого Qdisc через `tc` утилиту. `taprio_change` выделяет новую структуру конфигурации.
#### Стек освобождения (Task 6192): ``` taprio_free_sched_cb -> rcu_core -> handle_softirqs -> ... ``` Это RCU-колбэк, который вызывается после завершения RCU-груды (RCU grace period). `taprio_free_sched_cb` освобождает старую конфигурацию, которая больше не используется.
### Возможные причины и решения
1. **Отсутствие синхронизации в `taprio_change`:** Если `taprio_change` пытается получить доступ к старой структуре данных, которая уже помечена на удаление (но еще не освобождена RCU), это может привести к UAF, если RCU-колбэк сработал быстрее, чем ожидалось, или если нет правильной блокировки.
2. **Неправильное использование RCU:** Убедитесь, что все места, где читается конфигурация `taprio`, находятся внутри `rcu_read_lock()`. Если чтение происходит вне RCU-критической секции, оно может попасть на освобожденную память.
3. **Гонка между `taprio_change` и `taprio_free_sched_cb`:** Возможно, `taprio_change` некорректно обрабатывает ситуацию, когда старая конфигурация все еще находится в процессе удаления через RCU.
### Рекомендации по исправлению
1. **Проверьте использование RCU:** Убедитесь, что все чтения конфигурации `taprio` защищены `rcu_read_lock()` и `rcu_read_unlock()`.
2. **Проверьте порядок освобождения:** Убедитесь, что `taprio_free_sched_cb` вызывается только после того, как все ссылки на старую конфигурацию гарантированно освобождены.
3. **Добавьте дополнительную синхрон
If you want to get the best quality for vulnerability data then you always have to consider VulDB.