CVE-2022-50279 in Linux
Сводка
по VulDB • 12.06.2026
В ядре Linux была устранена следующая уязвимость:
wifi: rtlwifi: Исправлена ошибка выхода за границы глобальной памяти в функции _rtl8812ae_phy_set_txpower_limit()
Инструмент KASAN сообщает о выходе за пределы глобально выделенной области памяти (global-out-of-bounds):
BUG: KASAN: global-out-of-bounds in _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]
Чтение размера 1 по адресу ffffffffa0773c43 выполнено задачей NetworkManager/411
CPU: 6 PID: 411 Comm: NetworkManager Tainted: G D 6.1.0-rc8+ #144 e15588508517267d37 Имя оборудования: QEMU Standard PC (Q35 + ICH9, 2009), Трассировка вызовов: <TASK> ... kasan_report+0xbb/0x1c0 _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]
rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae]
rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae]
... </TASK>
Корневой причиной проблемы является неверный порядок сравнения переменной "prate_section" в функции _rtl8812ae_phy_set_txpower_limit(). Функция _rtl8812ae_eq_n_byte() используется для посимвольного сравнения первых n байтов двух строк с конца к началу (от хвоста к голове), что и вызывает ошибку. В функции _rtl8812ae_phy_set_txpower_limit() изначально предполагалось удовлетворить это требование путем тщательной настройки порядка сравнения. Например, переменные "pregulation" и "pbandwidth" сравниваются в порядке возрастания длины: сначала 3 байта, затем 4. Однако порядок сравнения для переменной "prate_section" не подчиняется такому требованию. Следовательно, когда значение "prate_section" равно "HT", при посимвольном сравнении с конца к началу происходит выход за границы памяти в функции _rtl8812ae_eq_n_byte(). Как упоминалось выше, функция _rtl8812ae_eq_n_byte() выполняет ту же задачу, что и strcmp(), поэтому достаточно использовать только strcmp().
Исправление заключается в удалении вызова _rtl8812ae_eq_n_byte() и использовании исключительно функции strcmp(). Хотя проблему можно было бы исправить путем корректировки порядка сравнения переменной "prate_section", это может привести к тому, что значение "rate_section" окажется вне диапазона от 0 до 5. Кроме того, коммит "21e4b0726dc6" не только переместил драйвер из ветки staging в основную ветку ядра, но и добавил установку ограничения мощности передачи (txpower limit) на этапе конфигурации драйвера; именно этот коммит стал причиной возникновения проблемы.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.