Августовское обновление Windows 10 принесло множество проблем

Августовское обновление Windows 10 принесло множество проблем

Августовское обновление Windows 10 принесло множество проблем

21 августа корпорация Microsoft выпустила обновление под идентификатором KB4100347, которое предназначалось для Windows 10 и Windows Server 2016. Этот патч был примечателен тем, что в нем содержалось обновление микрокода процессоров Intel для противодействия атаке Spectre. Однако оказалось, что эти «заплатки» вызвали множество проблем — пользователи сообщают о невозможности правильно загрузить систему Windows 10, а также о проблемах с производительностью.

Самое интересное, что пользователям процессоров AMD также пришло это обновление.

Основные жалобы пользователей связаны с тремя проблемами: невозможностью загрузки системы, бесконечными циклами ошибки «Preparing Automatic Repair» и значительным падением производительности при прослушивании музыки, работе в браузере Chrome и других приложениях.

Один из постов на Reddit описывает проблему с загрузкой, которая, по-видимому, затрагивает рабочие станции, использующие процессоры Xeon. Однако другие пользователи сообщают об аналогичных проблемах в случае с процессорами Intel i3, i5 и i7.

Также на Reddit был опубликован метод удаления этого злополучного обновления, в котором потребуется использование Windows Recovery Environment для тех систем, которым не удается загрузиться.

Тем пользователям, чьи системы в состоянии загрузиться, но при этом страдают от производительности, рекомендуют удалить обновление штатными средствами.

Стоит обратить внимание на тот факт, что пользователи, установившие сначала майское обновление, а затем последнее августовское, будут видеть, что KB4100347 упоминается дважды в истории обновлений.

Напомним, что ранее Intel добавила новый пункт к своему лицензионному соглашению, согласно которому разработчикам дистрибутивов Linux запрещается публиковать результаты тестирования программного обеспечения на быстродействие. Об этом сообщил один из ключевых лидеров движения Open Source и Free Software Брюс Перенс.

Баги в ядре Linux скрываются в среднем 2 года, а иногда и 20 лет

История с первой CVE для Rust-кода в ядре Linux, которая недавно привела к падениям системы, выглядела почти как повод для оптимизма. В тот же день для кода на C зарегистрировали ещё 159 CVE — контраст показательный. Но новое исследование напоминает: проблема не только в языках программирования.

Гораздо тревожнее первой Linux-дыры в коде на Rust тот факт, что многие ошибки в ядре Linux могут годами, а иногда и десятилетиями оставаться незамеченными.

Исследовательница Дженни Гуанни Ку из компании Pebblebed проанализировала 125 183 бага за почти 20 лет развития ядра Linux — и результаты оказались, мягко говоря, неожиданными.

 

По данным исследования, средний баг в ядре Linux обнаруживают через 2,1 года после его появления. Но это ещё не предел. Самый «долгоиграющий» дефект — переполнение буфера в сетевом коде — прожил в ядре 20,7 года, прежде чем на него обратили внимание.

Важно уточнить: речь идёт о багах в целом, а не только об уязвимостях. Лишь 158 ошибок из всей выборки получили CVE, остальные могли приводить к сбоям, нестабильности или неопределённому поведению, но не обязательно к эксплуатации.

Исследование опирается на тег Fixes:, который используется в разработке ядра Linux. Когда разработчик исправляет ошибку, он указывает коммит, в котором баг был добавлен. Дженни написала инструмент, который прошёлся по git-истории ядра с 2005 года, сопоставил такие пары коммитов и вычислил, сколько времени баг оставался незамеченным.

В датасет вошли данные до версии Linux 6.19-rc3, охватывающие период с апреля 2005 по январь 2026 года. Всего — почти 120 тысяч уникальных исправлений от более чем 9 тысяч разработчиков.

Оказалось, что скорость обнаружения ошибок сильно зависит от подсистемы ядра:

  • CAN-драйверы — в среднем 4,2 года до обнаружения бага;
  • SCTP-стек — около 4 лет;
  • GPU-код — 1,4 года;
  • BPF — всего 1,1 года.

Проще говоря, чем активнее подсистема используется и исследуется, тем быстрее там находят ошибки.

Отдельная проблема — неполные фиксы. Исследование показывает, что нередко разработчики закрывают проблему лишь частично. Например, в 2024 году был выпущен патч для проверки полей в netfilter, но уже через год исследователь нашёл способ его обойти.

Такие ситуации особенно опасны: создаётся ощущение, что проблема решена, хотя на самом деле она просто сменила форму.

RSS: Новости на портале Anti-Malware.ru