CVE-2026-68398 in LinuxИнформация

Сводка

по VulDB • 10.08.2026

В ядре Linux устранена следующая уязвимость:

ppp: отложенное освобождение канала в период грейс-периода RCU для исправления ошибки Use-After-Free (UAF) при приеме данных pppol2tp

Функция `pppol2tp_recv()` выполняется в пути приема пакетов softirq L2TP UDP-encap:

`l2tp_udp_encap_recv()` -> `l2tp_recv_common()` -> `pppol2tp_recv()` -> `ppp_input(&po->chan)`

Она выполняется под блокировкой `rcu_read_lock()`, удерживая только ссылку на сессию l2tp, и не берет дополнительную ссылку на внутренний канал PPP (структура `channel`, `chan->ppp`), к которому обращается функция `ppp_input()`.

Сокет pppox имеет флаг SOCK_RCU_FREE, поэтому переменная 'po' и встроенный объект `ppp_channel` безопасны с точки зрения RCU. Однако внутренняя структура `struct channel` является отдельным выделением памяти, которое освобождается функцией `ppp_release_channel()` посредством обычного вызова `kfree()`:

close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch)

Для канала, который привязан (PPPIOCGCHAN), но не присоединен к устройству ppp (нет PPPIOCCONNECT, `pch->ppp == NULL`) и не находится в режиме моста, процесс завершения пропускает как вызов `synchronize_net()` из функции `ppp_disconnect_channel()`, так и `synchronize_rcu()` из функции `ppp_unbridge_channels()`. В результате функция `kfree()` выполняется без периода грейс-периода. Блокировка `rcu_read_lock()` в функции `pppol2tp_recv()` не защищает от обычного вызова `kfree()`, поэтому выполняющийся на одном процессоре вызов `ppp_input()` может обратиться к каналу, который только что был освобожден функцией close() на другом процессоре.

Эта ошибка доступна для пользователя с низкими привилегиями (unprivileged user).

Освобождение канала откладывается до выполнения обратного вызова RCU через функцию `call_rcu()`, чтобы период грейс-периода обеспечил защиту любых выполняющихся в данный момент вызовов `ppp_input()`. Пути завершения при отключении и разрыве моста уже используют барьеры синхронизации с помощью `synchronize_net()`/`synchronize_rcu()`; функция `call_rcu()` выполняет ту же задачу здесь, не блокируя путь close().

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Ответственный

Linux

Резервировать

30.07.2026

Раскрытие

10.08.2026

Модерация

принято

Вход

VDB-387619

EPSS

0.00000

KEV

Нет

Деятельности

Очень низкий

Источники

Want to know what is going to be exploited?

We predict KEV entries!