Исходное сообщение
"Обновление X.Org Server 21.1.10 с устранением уязвимостей. У..." Отправлено Аноним, 17-Дек-23 22:28
>> Проблема вызвана использованием 32-разрядного типа int в переменной > для расчёта размера, который может быть переполнен при передаче запроса большого размера. > Как? Ну сменилось оно с 2^32-1 на 0. А дальше что? Так, этого гражданина тоже к сям и классическим типам на пушечный выстрел не подпускать! Дальше, чувак, если это было индексом массива/адресом - условие inner loop обламывается и код начинает читать или записывать совершенно левые "индексы" (адреса памяти). Если ты попробуешь на 0 адрес сходить, в лучшем случае все таки просто упадет нахрен - ибо "null pointer dereference". В иксах даже это основательно расстроит юзера. Но вообще, это при более умном варианте дает шарахаться по памяти - и ее произвольным адресам, позволяя делать с процессом - ну вот все. Дописать ему кода немного, запустить, поменять что-то, ... И кстати есть изрядная разница между signed и unsigned int. Но да, если гребаный олд вкатит что-то типа int i=0; i--; array[i]=10; - оно даже что-то сделает. Но немного не то что ты хотел. И индекс (адрес) будет - ну вот совсем не 0, если это (signed) "int".

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
	Введите код, изображенный на картинке: