В ядре Linux устранена следующая уязвимость:
svcrdma: отклонять встроенные ответы, которые переполняют буфер подтягивания. Клиент RPC-over-RDMA может запросить ответ, например NFS READ.
полезная нагрузка, без предоставления списка записи или фрагмента ответа для переноса
это. Когда для такого ответа требуется больше записей разброса/сбора, чем
поддерживает очередь отправки устройства, svc_rdma_pull_up_needed() выбирает
подтягивание и svc_rdma_pull_up_reply_msg() линеаризуют все
ответьте в sctxt->sc_xprt_buf.
Этот буфер имеет размер sc_max_req_size.
байт, а ответ по этому пути ограничен только клиентским
запрос, поэтому svc_rdma_xb_linearize() копирует за конец
буфер и повреждает соседнюю блочную память. Негабаритная длина составляет
затем сохраняется в sc_sges[0].length и публикуется, поэтому устройство также
читается за пределами отображаемой области. Ветка исчерпания SGE — единственный путь подтягивания, который может превышать
буфер: пороговая ветвь подтягивается только ответы меньшего размера
чем RPCRDMA_PULLUP_THRESH, и ответы, соответствующие SGE устройства.
бюджет пересылается напрямую без линеаризации.
Сделать
svc_rdma_pull_up_needed() сообщает -E2BIG, когда будет получен ответ
pull up не может соответствовать sc_max_req_size и не выполняет запрос с помощью
ERR_CHUNK, как указано в разделе 4.5.3 RFC 8166, а не удаляется.
связь. Помощник больше не отвечает на простой вопрос «да/нет»: теперь он
сообщает о подтягивании, отсутствии подтягивания или -E2BIG, если ответ слишком велик для
линеаризовать. Переименуйте svc_rdma_pull_up_needed() в
svc_rdma_check_pull_up(), чтобы его имя больше не подразумевало логическое значение.
предикат.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: svcrdma: Reject inline replies that overflow the pull-up buffer An RPC-over-RDMA client can request a reply, such as an NFS READ payload, without providing a Write list or a Reply chunk to carry it. When such a reply needs more scatter/gather entries than the device's Send Queue supports, svc_rdma_pull_up_needed() selects pull-up and svc_rdma_pull_up_reply_msg() linearizes the whole reply into sctxt->sc_xprt_buf. That buffer is only sc_max_req_size bytes, while the reply on this path is bounded only by the client's request, so svc_rdma_xb_linearize() copies past the end of the buffer and corrupts adjacent slab memory. The oversized length is then stored in sc_sges[0].length and posted, so the device also reads beyond the mapped region. The SGE-exhaustion branch is the only pull-up path that can exceed the buffer: the threshold branch pulls up only replies smaller than RPCRDMA_PULLUP_THRESH, and replies that fit the device's SGE budget are sent directly without linearization. Make svc_rdma_pull_up_needed() report -E2BIG when the reply it would pull up cannot fit sc_max_req_size, and fail the request with ERR_CHUNK as RFC 8166 Section 4.5.3 directs rather than dropping the connection. The helper no longer answers a simple yes/no question: it now reports pull-up, no pull-up, or -E2BIG for a reply too large to linearize. Rename svc_rdma_pull_up_needed() to svc_rdma_check_pull_up() so its name no longer implies a boolean predicate.
Характеристики атаки
Последствия
Строка CVSS v3.1