https://www.opennet.me/openforum/vsluhforumID3/139805.html В поставляемых в составе CPython классах распаковки сжатых данных в форматах lzma, bz2 и gzip (lzma.LZMADecompressor, bz2.BZ2Decompressor и gzip.GzipFile) выявлена уязвимость (CVE-2026-6100), приводящая к обращению к памяти после её освобождения. Проблема присвоен критический уровень опасности (9.1 из 10) - в случае успешной эксплуатации уязвимость может привести к утечке информации из памяти процесса или выполнению кода атакующего при распаковке специально оформленных данных...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=65202<br> https://www.opennet.me/openforum/vsluhforumID3/139805.html#71 Tue, 14 Apr 2026 22:39:29 GMT лутший линопс<br> https://www.opennet.me/openforum/vsluhforumID3/139805.html#70 Tue, 14 Apr 2026 20:55:49 GMT Вас то это всё как касается?<br> https://www.opennet.me/openforum/vsluhforumID3/139805.html#69 Tue, 14 Apr 2026 20:51:42 GMT &gt; в линуксе<br><br>В линуксе, как минимум в ядре, вообще пофигу на кодировку текста, пока это null-терминированные строки. В адекватных и с выключенными дебильными опциями, которые таки заставляют систему парсить юникод, файловых системах то же самое, только '/' в резолвере путей является разделителем. Да и вообще, utf-8 парсится элементарно в код-поинты, с которыми дальше можешь делать что хочешь.<br> https://www.opennet.me/openforum/vsluhforumID3/139805.html#66 Tue, 14 Apr 2026 18:42:47 GMT &gt; На си настолько неудобно и сложно писать<br><br>Понятия не имею, с роду на си ничего не писал. Мой удел это Python. И даже на Python большинство багов, которые находят нейронки - edge cases, которые никак не влияют на работоспособность и безопасность, но их закрытие увеличивает размер модуля иногда раза в два.<br> https://www.opennet.me/openforum/vsluhforumID3/139805.html#65 Tue, 14 Apr 2026 18:15:58 GMT &gt; Это понятно, но взамен ничего не принесли. Где гарантия, что "завтра" эти <br>&gt; зануления указателей снова не пропадут? Понятно, что случай крайний, но он <br>&gt; показывает, что готовой инфрастурктуры для тестирования в условиях настоящего исчерпания <br>&gt; памяти нет.<br><br>Нууу... Я не очень вникал, но вроде как сборка со всякими SANами у них в CI есть https://github.com/python/cpython/blob/main/.github/workflows/reusable-san.yml и даже fuzzing какой-то есть https://github.com/python/cpython/blob/main/.github/workflows/build.yml#L608. Так что инфраструктура точняк есть. Правда очевидно, что этот fuzzing данную уязвимость не нашел (но тут пожалуй тоже понятно, fuzzing сам по себе вряд ли мог бы edge case с MemoryError вызвать).<br><br>Ну а то что сейчас взамен нормальный тест не добавили - idk. Может просто чтобы побыстрее фикс выкатить. Или может мэйнтейнеры (также как я) считают что данная уязвимость на самом деле не супер критичная. Или может как раз нужен более полноценный репродюсер.<br><br>Если вам кажется что это мега https://www.opennet.me/openforum/vsluhforumID3/139805.html#64 Tue, 14 Apr 2026 18:06:30 GMT &gt; Почему то это волнует только вас.<br><br>Не только меня Ваня, не только меня.<br><br>&gt; Интересно что с вами не так?) <br><br>А что не так?<br>Просто обратили внимание что питон к проблеме отношения не имеет.<br><br><br> https://www.opennet.me/openforum/vsluhforumID3/139805.html#63 Tue, 14 Apr 2026 17:49:29 GMT Почему то это волнует только вас.<br>Интересно что с вами не так?)<br> https://www.opennet.me/openforum/vsluhforumID3/139805.html#62 Tue, 14 Apr 2026 17:49:25 GMT &gt;&gt;&gt; Учитывая, что lzma/bz2/gzip под капотом все равно декомпрессию делают чанками и на большинстве современных машин память выделяется с overcommitом, на самом деле даже просто словить MemoryError в данной ситуации - не очень просто (если просто сделать скажем bz2 файл, который декомпрессится в больше данных чем есть оперативки, то процесс просто будет убит OOM Killerом, а не MemoryError).<br>&gt;&gt; Можно контейнер отдельный для этого теста сделать.<br>&gt; Тащить docker как зависимость CPython просто ради этого теста - так себе идея. <br><br>Можно без всякого докера нативно на линуксе это сделать. И да, тест будет линукс only.<br><br>&gt; Конечно, есть всякие fuzzerы, address sanitizerы и прочий инструментарий, с помощью которого <br>&gt; можно было бы более точно убедиться в наличии / отсутствии этого <br>&gt; use after free. Но это уже отдельная тема. <br><br>Ну да, логично тесты запускать с ubsan хотя бы.<br><br>&gt; Тот юнит тест, который был в исходном PRе однозначно детектировать утечку указателя в данной <br>&gt; ситуации не позволял и соответственно https://www.opennet.me/openforum/vsluhforumID3/139805.html#61 Tue, 14 Apr 2026 17:36:40 GMT &gt;&gt; Учитывая, что lzma/bz2/gzip под капотом все равно декомпрессию делают чанками и на большинстве современных машин память выделяется с overcommitом, на самом деле даже просто словить MemoryError в данной ситуации - не очень просто (если просто сделать скажем bz2 файл, который декомпрессится в больше данных чем есть оперативки, то процесс просто будет убит OOM Killerом, а не MemoryError).<br>&gt; Можно контейнер отдельный для этого теста сделать.<br><br>Мои рассуждения на тему overcommit и OOM были относительно вопросов "есть ли готовый эксплоит" и "насколько реалистичная / значительная эта уязвимость на самом деле", а не "как сделать тест".<br><br>Тащить docker как зависимость CPython просто ради этого теста - так себе идея. Функционала `_testcapi.set_nomemory` вполне достаточно для того чтобы симулировать MemoryError в нужном месте.<br><br>Проблема с тем тестом, который убрали из PRа - не в том как вызвать MemoryError, а в том, как потом однозначно задетектировать, была ли "утечка" указателя или нет. Тот тест, который исходн