В ядре Linux устранена следующая уязвимость:
xen/pvcalls: связанный серверный ответ req_id перед индексацией rsp[]
pvcalls_front_event_handler() берет req_id непосредственно из
кольцевой ответ, предоставленный серверной частью, и использует его для индексации
массив bedata->rsp[] для memcpy() и хранилища без проверки диапазона. А
вредоносный или ошибочный бэкэнд может установить req_id после PVCALLS_NR_RSP_PER_RING
и управлять записью за пределами выделенного пространства данных.
req_id также был объявлен как int, тогда как поле связи rsp->req_id имеет значение u32, поэтому
проверки диапазона только подписанного значения недостаточно: бэкэнд
req_id 0xffffffff становится -1, передает >= PVCALLS_NR_RSP_PER_RING
тест и индексы bedata->rsp[-1]. Объявите req_id как u32, чтобы один
переплет покрывает оба конца.
Серверная часть, отправляющая req_id вне диапазона, нарушила соединение.
протокол, поэтому вместо того, чтобы молча отбрасывать ответ, войдите один раз и
перестаньте доверять бэкэнду: установите bedata->disabled. Обработчик событий затем
игнорирует дальнейшие ответы и пути запросов, ожидающие
возврат ответа -EIO вместо вечной блокировки. Это отражает
обработка фатальных ошибок использует xen-netback (xenvif_fatal_tx_err()).
Интерфейс pvcalls в настоящее время доверяет своему серверу, поэтому это не
классическая проблема безопасности Xen, но она важна для усиления защиты фотоэлектрических интерфейсов
против вредоносных серверных частей (конфиденциальное и дезагрегированное развертывание).
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: xen/pvcalls: bound backend response req_id before indexing rsp[] pvcalls_front_event_handler() takes req_id directly from the backend-supplied ring response and uses it to index the fixed-size bedata->rsp[] array for a memcpy() and a store, with no range check. A malicious or buggy backend can set req_id past PVCALLS_NR_RSP_PER_RING and drive an out-of-bounds write past the bedata allocation. req_id was also declared int while the wire field rsp->req_id is u32, so a range check on the signed value alone is insufficient: a backend req_id of 0xffffffff becomes -1, passes a >= PVCALLS_NR_RSP_PER_RING test and indexes bedata->rsp[-1]. Declare req_id as u32 so a single bound covers both ends. A backend that sends an out-of-range req_id has violated the wire protocol, so rather than silently dropping the response, log once and stop trusting the backend: set bedata->disabled. The event handler then ignores further responses, and the request paths that wait for a response return -EIO instead of blocking forever. This mirrors the fatal-error handling xen-netback uses (xenvif_fatal_tx_err()). The pvcalls frontend currently trusts its backend, so this is not a classic-Xen security issue, but it matters for hardening PV frontends against malicious backends (confidential and disaggregated deployments).
Характеристики атаки
Последствия
Строка CVSS v3.1