В ядре Linux устранена следующая уязвимость: атм: lec: исправить null-ptr-deref в lec_arp_clear_vccs syzkaller сообщил null-ptr-deef в lec_…

В ядре Linux устранена следующая уязвимость: атм: lec: исправить null-ptr-deref в lec_arp_clear_vccs syzkaller сообщил null-ptr-deef в lec_arp_clear_vccs(). Эту проблему можно легко воспроизвести с помощью репродуктора сискаллера. В модуле ATM LANE (LAN Emulation) тот же атм_вк может быть общим несколько записей lec_arp_table (например, через запись->vcc или вход->recv_vcc). Когда базовый VCC закрыт, lec_vcc_close() итерирует все Записи ARP и звонки lec_arp_clear_vccs() для каждой подобраной записи. Например, когда lec_vcc_close() итерирует через списки в priv->lec_arp_empty_ones или другие таблицы ARP: 1. 1. В первой итерации, для первого сопоставленного ARP-захода, разделяющего VCC, lec_arp_clear_vccs() освобождает ассоциированный vpriv (который является vcc->user_back) и устанавливает vcc->user_back в NULL. 2. 2. Во второй итерации для следующей подобранной ARP-записи, разделяющей то же самое VCC, lec_arp_clear_vccs() снова вызывается. Получает NULL vpriv от vcc->user_back (через LEC_VCC_PRIV(vcc)) и затем пытается отнестись к нему через `vcc->pop = vpriv->old_pop`, что привело к квалальному крушику. Исправьте это, добавив нулевую проверку на vpriv перед оговоркой это. Если vpriv уже NULL, это означает, что VCC был очищен по предыдущему вызову, так что мы можем безопасно пропустить очистку и просто очистить указатели записи vcc/recv_vcc. Весь блок очистки (включая vcc_release_async()) помещается внутрь Вирусная охрана, потому что NULL vpriv указывает, что VCC уже был полностью освобождена предыдущей итерацией — повторение разрыва будет Излишне устанавливали флаги и вызывали обратные вызовы на уже закрывающую розетку. Тег исправлений указывает на начальную приверженность, потому что путь входа->vcc имеет Он был уязвим со времени оригинального кода. Путь вход->recv_vcc был позже добавлено mits, 8d9f73c0ad2f («atm: исправьте утечку памяти vcc->user_back») с одним и тем же рисунком, и оба пути закреплены здесь.