| 1.1, Аноним (1), 13:13, 14/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ну вот добрались и до биндингов к скриптовым языкам, которые всю дорогу писали как попало. Без сишных зависимостей этот питон даже ползать не сможет, так что впереди длинный путь )))
| | |
| |
| 2.6, Аноним (6), 13:27, 14/04/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Функция zlib'а в текушем виде как минимум 4 года существует, дальше по коммитам не прошёлся, потому что гитхаб - неудобное лагающее г~вно
| | |
| |
| |
| 4.13, Аноним (6), 13:47, 14/04/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
В том что на простой вопрос на опеннетике дать простой ответ проще, чем достать комп чтобы скачать репу и быстро найти там, где функция появилась. Хотите - найдите.
Я лично считаю что бага никакого и не было, либо его надо фиксить не там, потому что выглядят патчи как рандомный вброс типичных "ааааа нулл забыли", т.е. скорее всего ллмкой по популярному проекту прошлись и она что-то выбрзнула.
| | |
|
|
|
| 1.8, Аноним (6), 13:30, 14/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Занулили какой-то рандомный указатель, который потом может нигде и не используется... С этими вашими лллмками только strcpy да рандомное отсутствие '= NULL' сейчас и будут исправлять всякие идиоты, которым нужно коммитов налутать для... чего-то... джиа-танов новых подготавливают наверное.
| | |
| |
| 2.31, Сладкая булочка (?), 16:21, 14/04/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Тест добавили, однако какой-то phd чел пришел и сказал, что не нужно
> Considering we need to hit an error path with a MemoryError, I'm not sure we really need a test. Sometimes we do add tests, sometimes not. I don't think there is a need to add a test. The test also don't assert that we hit the goto so I don't think we need it.
Видите ли в своих же тестах питонисты не смогли создать способ задать кол-во доступной памяти.
| | |
| |
| 3.39, ruroruro (ok), 16:59, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
 > питонисты не смогли создать способ задать кол-во доступной памяти
Буквально следующий коммент после того что вы процитировали:
> agreed, while it is neat that we have '_testcapi.set_nomemory' (I didn't realize that), it is a difficult thing to use in a deterministic manner to show that the specific case in desire of covering is hit. usually not worth it. | | |
| |
| 4.41, Сладкая булочка (?), 17:10, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
>> питонисты не смогли создать способ задать кол-во доступной памяти
> Буквально следующий коммент после того что вы процитировали:
>> it is a difficult thing to use in a deterministic manner to show that the specific case in desire of covering is hit. usually not worth it.
Получается готового эксплойта нет? А что тогда столько шума? А если есть, то почему его в тест не засунуть?
| | |
| |
| 5.44, ruroruro (ok), 17:49, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
Лично я рабочего эксплоита не видел. Учитывая, что lzma/bz2/gzip под капотом все равно декомпрессию делают чанками и на большинстве современных машин память выделяется с overcommitом, на самом деле даже просто словить MemoryError в данной ситуации - не очень просто (если просто сделать скажем bz2 файл, который декомпрессится в больше данных чем есть оперативки, то процесс просто будет убит OOM Killerом, а не MemoryError).
Тест, который изначально был в PR - синтетически симулирует истощение памяти (то есть '_testcapi.set_nomemory' просто делает так чтобы следующий 'PyMem_Malloc' "прикинулся" что памяти нет). Это конечно хорошо, но просто такие тесты на самом деле не очень демонстрирует, что действительно уязвимости нет.
То есть, например, в моих экспериментах эти тесты не приводят к крашу даже на версиях питона, в которых баг не исправлен. Так что ¯\_(ツ)_/¯.
А на счет "столько шума", добро пожаловать в мир CVE. Вообще даже если бы был эксплоит, скора 9.1 он сто пудов не заслуживал бы (т.к. при "нормальном" использовании lzma/bz2/gzip никто в здравом уме не станет ловить MemoryError и после этого продолжать использовать тот же самый Decompressor объект).
Ну это мое ИМХО.
| | |
|
|
|
|
| 1.9, Аноним (9), 13:33, 14/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Вот и в managed-языках бывают ошибки работы с памятью. А уж в компилируемом Расте, тем боллее, могут быть.
| | |
| |
| 2.12, Аноним (11), 13:43, 14/04/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Все эти ошибки по работе с памятью это пугалки для детей. Чтобы заставить их делать то что тебе выгодно, а не им.
| | |
| |
| 3.21, Аноним (21), 15:14, 14/04/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Так и запишем:
>Полицаи и турма - пугалки для детей, чтобы заставить их делать то, что им не нужно, на взрослых не работает. | | |
| |
| 4.24, Аноним (24), 15:43, 14/04/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Аналогии это вот прям вообще не твое. Тут скорее аналогия с рен тв и рептилоидами. Но ты конечно продолжай включать защитную реакцию чтобы защитить своё ошибочное мировоззрение.
| | |
|
|
| 2.19, Аноним (19), 14:32, 14/04/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Вот и в managed-языках бывают ошибки работы с памятью.
Ошибка не в языке, а в конкретной реализации.
Потому что реализация на dъряхе, а там всегда клали болт на безопасность и на работу с памятью.
| | |
| |
| |
| 4.32, Аноним (32), 16:28, 14/04/2026 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Ошибка в библиотеке на языке.
На каком языке? Ты там код на питоне увидел?
Дырень в CPython. CPython это реализация (implementation) питона.
Кроме него есть и другие - IronPython, Jython и тд. В них есть эта дыра?
| | |
|
|
|
| 1.14, Аноним (14), 13:51, 14/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
все биндинги сделать на расте, в usafe засунуть код на микропитоне, чтобы усилить безопасность!
| | |
| 1.18, Аноним (19), 14:31, 14/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
> Уязвимость в Python-библиотеках
Какая прелесть!
Дырени в _bz2module.c, _lzmamodule.c и zlibmodule.c
| | |
| 1.20, Аноним (20), 15:05, 14/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Читаешь новость "Уязвимость в Python-библиотеках"
"уязвимость, приводящая к обращению к памяти после её свобождения".
Думаешь "да ладно? как же так?!"
А потом открываешь патчик, а там cpython!
И все сразу становится на свои места))
| | |
| 1.23, Аноним (23), 15:31, 14/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Всё это эдж кейсес, которые в реальных сценариях никак не_проявляют себя. Их устранение чаще всего не_обосновано из-за оверинжиниринга. Это как делать проверку словаря на нулевые значения, которые могут вызвать деление на ноль, хотя сам словарь априори заполняется правильно, чисто by design исключая нули.
| | |
| |
| 2.26, Аноним (22), 15:50, 14/04/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Всё это эдж кейсес, которые в реальных сценариях
В реальных сценариях через это и ломают.
> никак не_проявляют себя.
Тебя Артемис 2 с Луны только что привёз?
> Их устранение чаще всего не_обосновано из-за оверинжиниринга.
Это правда. На си настолько неудобно и сложно писать, что хорошо сделанная работа требует слишком много усилий, поэтому сишники делают работу спустя рукава.
| | |
| |
| 3.28, Аноним (28), 16:04, 14/04/2026 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> поэтому сишники делают работу спустя рукава.
а никто их не учил ка надо делать, Си ведь для них "высокоуровневый" ЯП, который почему-то требует архитектурных знаний, ну вопрос - а зачем мне тогда Си? Усердный Сишник - на асм писать будет, а остальные ничем от питоновых "тяпляпщиков" не отличаются. А почему никто на асм не пишет, я объяснял в прошлых новостях, никто не хочет изучать архитектуру ЦПУ когда она через полгода протухает и никак не стабилизируется - ад одним словом. Бабла ради все? ну ок, тогда платите бабло за качественный код на том же Си. А так все заслуженно, и спецам на руку, им не нужен качественный софт это же угроза нац. безопасТности!
| | |
|
| 2.27, Аноним (28), 15:59, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Их устранение чаще всего не_обосновано из-за оверинжиниринга.
оверинжиниринг - бред, там должна быть проверка на нулевые значения, точнее на корректные значения.
| | |
| |
| 3.30, Аноним (30), 16:19, 14/04/2026 [^] [^^] [^^^] [ответить]
| –2 +/– |
Ну так для СИшников дополнительные проверки и есть оверинжениринг.
Они просто не могут номально проверять краевые случае и инварианты, в силу убогости инструмента и непривычности задачи.
Как писал Теордор Тцо "check if directory block is within i_size".
А там уже как повезет.
| | |
| |
| 4.33, Аноним (28), 16:42, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Ну так для СИшников дополнительные проверки и есть оверинжениринг.
Как понимать "дополнительные проверки"? - Проверки бывают либо необходимые и достаточные, либо - избыточные. Любой оптимальный корректный алгоритм имеет необходимые и достаточные проверки.
| | |
| |
| 5.37, Аноним (37), 16:55, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Как понимать "дополнительные проверки"? - Проверки бывают либо необходимые и достаточные, либо - избыточные. Любой оптимальный корректный алгоритм имеет необходимые и достаточные проверки.
Ээээ, ты это что-то на умном пишешь.
Ты просто думай по другому.
"Если проверка замедляет программу на 1% - значит выкинем ее, пофиг что возможно это приведет к CVE с получением рута"
"Если проверка мне мешает - значит это неудобная и ненужная проверка"
"Если мне лень - значит проверка не нужная"
"В недоязыке ошибку приходится пробрасывать как отрицательный инт? ну и пофиг, сделаем просто функцию signed, а не такой как она должна быть"
Как писал Дуглас Макилрой про первые CVE в только что изобретенном СИ
"Overflowable buffers were common in those days. It was all too easy
when programming to shrug one's shoulders and opine that nobody would
ever want to input a 200-character line, say, so why bother writing
the extra code to catch it?
Dennis once fed a couple-of-thousand-byte line on standard input to everything in /bin. Crashes abounded, but so what?"
tuhs.org/pipermail/tuhs/2026-January/032966.html
В общем всем было положить на качество и это не поменялось до сих пор.
| | |
|
|
|
|
| 1.35, ruroruro (ok), 16:48, 14/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
> The vulnerability is only present if the program re-uses decompressor instances across multiple decompression calls even after a 'MemoryError' is raised during decompression. Using the helper functions to one-shot decompress data such as 'lzma.decompress()', 'bz2.decompress()', 'gzip.decompress()', and 'zlib.decompress()' are not affected as a new decompressor instance is used per call. If the decompressor instance is not re-used after an error condition, this usage is similarly not vulnerable.
То есть для того чтобы попасть на эту уязвимость нужно сделать что-то вроде:
'''
d = lzma.LZMADecompressor()
try:
d.decompress(malicious_data)
except MemoryError:
pass
d.decompress(more_malicious_data)
'''
Ага, это явно CVE 9.1, Critical.
| | |
| |
| 2.38, Аноним (38), 16:56, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Ага, это явно CVE 9.1, Critical.
А оно может прилитель снаружи?
Типа запустил скрипт с интернета и он тебе подгадил?
| | |
| |
| 3.40, ruroruro (ok), 17:02, 14/04/2026 [^] [^^] [^^^] [ответить]
| +2 +/– |
шта? Если ты запустил зловредный скрипт с интернета, то никакого CVE и не нужно, ты и так уже выполняешь arbitrary code.
| | |
| |
| 4.42, Аноним (42), 17:37, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Чуть проще (из недавнего): скачал модельку для блендера со встроенными скриптами...
| | |
|
|
|
|
