Три уязвимости AMD Turin могут позволить коду внутри виртуальной машины косвенно считывать данные других процессов или ядра, работающих на том же физическом ядре CPU. Google Cloud уже закрыла сценарии атак между виртуальными машинами и между VM и хостом, но клиентам затронутых инстансов всё равно понадобятся патч гостевой ОС и полная остановка с последующим запуском машины.
Проблема касается серий C4D, N4D, H4D, Z4D и G4, включая bare-metal-инстансы C4D и Z4D. Как сообщает The Hacker News, речь идёт о трёх атаках класса Transient Scheduler Attacks: TSA-SQ с идентификатором CVE-2024-36350, TSA-L1 — CVE-2024-36357 и новой CVE-2026-0004, которую в Xen Project называют TSA-Fill.
Turin — кодовое имя серверных AMD EPYC пятого поколения на архитектуре Zen 5. Две из трёх проблем впервые раскрыли 8 июля 2025 года для более ранних EPYC, однако для Zen 5 картина оказалась сложнее первоначальных оценок. AMD теперь указывает, что новые процессоры подвержены атакам иначе, чем ранее исследованные чипы. Xen Project отдельно уточнил прежнее заявление: ранее AMD сообщала, что Zen 5 не уязвимы для TSA-SQ и TSA-L1.
Все три сценария относятся к локальным атакам: злоумышленнику нужно суметь запустить код на целевой системе. По классификации AMD, для эксплуатации требуются низкие привилегии, но атака имеет высокую сложность. CVE-2026-0004 потенциально даёт возможность извлекать информацию из кэша данных L1. Это не означает, что любой пользователь VM получает доступ ко всей памяти сервера: Google заявляет, что межмашинная изоляция и граница между VM и хостом уже защищены. Риск остаётся внутри одной гостевой ОС, если атакующий процесс делит физическое ядро с целью.
Для облачных команд важна не столько экзотичность атаки, сколько процедура исправления. Google Cloud в течение недели обновляет CPU-информацию, которую видят виртуальные машины. После появления этого обновления ядро гостевой ОС с нужным патчем сможет включить защиту. Затем VM требуется именно остановить и запустить заново: обычной перезагрузки гостевой ОС недостаточно. Провайдер пока не объяснил, как клиенту точно проверить, дошло ли обновление CPU-информации до конкретного инстанса.
Если в VM работает собственный гипервизор, порядок тот же: обновить гостевое ядро и выполнить stop/start после доставки изменений со стороны Google. Владельцам bare-metal C4D и Z4D придётся следить за обновлениями своего поставщика ОС или гипервизора. Для GKE Google готовит обновлённые образы нод для bare-metal на Turin; обновление нод должно принести и новую CPU-информацию. На момент публикации бюллетеня эти образы ещё не были отмечены как доступные. Пользователям Cloud Run никаких действий предпринимать не нужно.
Состояние экосистемы обновлений пока неоднородно. В исходном дереве Linux уже есть коммит с защитой от TSA на Zen 5, включая новый вариант атаки. В Debian исправление CVE-2026-0004 на данный момент попало только в ветку unstable, а ядра bookworm, trixie и forky в трекере безопасности всё ещё значатся уязвимыми. Xen Project выпустил патчи для гипервизора и сообщил, что микрокод для всех TSA-сценариев на Zen 5 присутствует в linux-firmware с 23 сентября.
Для серверов Turin в собственной инфраструктуре одних обновлений ОС недостаточно: AMD рекомендует сочетать обновление платформенной прошивки и ОС. Компания также предупреждает о возможном влиянии защит на производительность — знакомая плата за закрытие микроархитектурных каналов утечки. Google оценивает риск как средний, а в каталоге CISA KEV все три CVE пока отсутствуют; ни AMD, ни Google не сообщали о зафиксированной эксплуатации.
Практический вывод для DevOps и ИБ-команд довольно приземлённый: инвентаризировать затронутые C4D, N4D, H4D, Z4D и G4, сверить готовность образов ОС и заранее запланировать короткое окно на stop/start. История с уязвимостями AMD Turin снова показывает, что для облачной изоляции патча на стороне провайдера бывает недостаточно: последняя миля безопасности часто проходит через гостевое ядро, микрокод и дисциплину обновлений клиента.
