В ядре Linux устранена следующая уязвимость:
atm: lec: исправить null-ptr-deref в lec_arp_clear_vccs
syzkaller сообщил о разыменовании null-ptr в lec_arp_clear_vccs(). Эту проблему можно легко воспроизвести с помощью репродуктора syzkaller. В модуле ATM LANE (эмуляция локальной сети) один и тот же atm_vcc может использоваться совместно
несколько записей lec_arp_table (например, через запись->vcc или запись->recv_vcc).
Когда базовый VCC закрыт, lec_vcc_close() перебирает все
Записи ARP и вызывает lec_arp_clear_vccs() для каждой соответствующей записи. Например, когда lec_vcc_close() перебирает списки hlist в
priv->lec_arp_empty_ones или другие таблицы ARP:
1. В первой итерации для первой совпадающей записи ARP, использующей VCC,
lec_arp_clear_vccs() освобождает связанный vpriv (то есть vcc->user_back)
и устанавливает для vcc->user_back значение NULL.
2.
Во второй итерации для следующей совпадающей записи ARP, использующей тот же
VCC, lec_arp_clear_vccs() вызывается снова. Он получает NULL vpriv от
vcc->user_back (через LEC_VCC_PRIV(vcc)) и затем пытается разыменовать его
через `vcc->pop = vpriv->old_pop`, что приводит к сбою null-ptr-deref. Исправьте это, добавив нулевую проверку для vpriv перед разыменованием.
это.
Если vpriv уже равен NULL, это означает, что VCC очищен.
предыдущим вызовом, поэтому мы можем спокойно пропустить очистку и просто
очистите указатели vcc/recv_vcc записи. Весь блок очистки (включая vcc_release_async()) помещается внутри
vpriv Guard, потому что NULL vpriv указывает, что VCC уже был
полностью выпущено на предыдущей итерации — повторение демонтажа приведет
избыточно устанавливать флаги и запускать обратные вызовы для уже закрывающегося сокета. Тег Fixes указывает на первоначальную фиксацию, поскольку путь вход->vcc имеет
был уязвим с момента исходного кода.
Путь записи->recv_vcc был позже добавлено коммитом 8d9f73c0ad2f («atm: исправить утечку памяти vcc->user_back») с тем же шаблоном, и здесь зафиксированы оба пути.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: atm: lec: fix null-ptr-deref in lec_arp_clear_vccs syzkaller reported a null-ptr-deref in lec_arp_clear_vccs(). This issue can be easily reproduced using the syzkaller reproducer. In the ATM LANE (LAN Emulation) module, the same atm_vcc can be shared by multiple lec_arp_table entries (e.g., via entry->vcc or entry->recv_vcc). When the underlying VCC is closed, lec_vcc_close() iterates over all ARP entries and calls lec_arp_clear_vccs() for each matched entry. For example, when lec_vcc_close() iterates through the hlists in priv->lec_arp_empty_ones or other ARP tables: 1. In the first iteration, for the first matched ARP entry sharing the VCC, lec_arp_clear_vccs() frees the associated vpriv (which is vcc->user_back) and sets vcc->user_back to NULL. 2. In the second iteration, for the next matched ARP entry sharing the same VCC, lec_arp_clear_vccs() is called again. It obtains a NULL vpriv from vcc->user_back (via LEC_VCC_PRIV(vcc)) and then attempts to dereference it via `vcc->pop = vpriv->old_pop`, leading to a null-ptr-deref crash. Fix this by adding a null check for vpriv before dereferencing it. If vpriv is already NULL, it means the VCC has been cleared by a previous call, so we can safely skip the cleanup and just clear the entry's vcc/recv_vcc pointers. The entire cleanup block (including vcc_release_async()) is placed inside the vpriv guard because a NULL vpriv indicates the VCC has already been fully released by a prior iteration — repeating the teardown would redundantly set flags and trigger callbacks on an already-closing socket. The Fixes tag points to the initial commit because the entry->vcc path has been vulnerable since the original code. The entry->recv_vcc path was later added by commit 8d9f73c0ad2f ("atm: fix a memory leak of vcc->user_back") with the same pattern, and both paths are fixed here.