В ядре Linux устранена следующая уязвимость:
bpf: исправлена проблема с UAF в bpf_trampoline_link_cgroup_shim. Основная причина этой ошибки заключается в том, что когда «bpf_link_put» уменьшает
счетчик ссылок 'shim_link->link.link' равен нулю, ресурс считается
выпущен, но на него все еще можно ссылаться через 'tr->progs_hlist' в
'cgroup_shim_find'. Фактическая очистка 'tr->progs_hlist' в
«bpf_shim_tramp_link_release» отложен.
Во время этого окна еще один процесс может вызвать использование после освобождения через «bpf_trampoline_link_cgroup_shim». Основываясь на предложениях Мартина Кафай Лау, я создал простой патч. Чтобы это исправить: Добавьте атомарную ненулевую проверку в «bpf_trampoline_link_cgroup_shim».
Увеличивайте счетчик ссылок только в том случае, если он еще не равен нулю. Тестирование:
Я проверил исправление, добавив задержку в
«bpf_shim_tramp_link_release», чтобы облегчить возникновение ошибки:
static void bpf_shim_tramp_link_release(struct bpf_link *link)
{
/* ... */
if (!shim_link->батут)
возврат;
+ мссон(100);
WARN_ON_ONCE(bpf_trampoline_unlink_prog(&shim_link->ссылка,
shim_link->батут, NULL));
bpf_trampoline_put(shim_link->батут);
}
До патча запуск PoC легко воспроизводил сбой (почти 100%).
со отслеживанием вызовов, аналогичным отчету KaiyanM. После патча ошибка больше не возникает даже после миллионов
итерации.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a UAF issue in bpf_trampoline_link_cgroup_shim The root cause of this bug is that when 'bpf_link_put' reduces the refcount of 'shim_link->link.link' to zero, the resource is considered released but may still be referenced via 'tr->progs_hlist' in 'cgroup_shim_find'. The actual cleanup of 'tr->progs_hlist' in 'bpf_shim_tramp_link_release' is deferred. During this window, another process can cause a use-after-free via 'bpf_trampoline_link_cgroup_shim'. Based on Martin KaFai Lau's suggestions, I have created a simple patch. To fix this: Add an atomic non-zero check in 'bpf_trampoline_link_cgroup_shim'. Only increment the refcount if it is not already zero. Testing: I verified the fix by adding a delay in 'bpf_shim_tramp_link_release' to make the bug easier to trigger: static void bpf_shim_tramp_link_release(struct bpf_link *link) { /* ... */ if (!shim_link->trampoline) return; + msleep(100); WARN_ON_ONCE(bpf_trampoline_unlink_prog(&shim_link->link, shim_link->trampoline, NULL)); bpf_trampoline_put(shim_link->trampoline); } Before the patch, running a PoC easily reproduced the crash(almost 100%) with a call trace similar to KaiyanM's report. After the patch, the bug no longer occurs even after millions of iterations.