// For flags

CVE-2024-35814

swiotlb: Fix double-allocation of slots due to broken alignment handling

Severity Score

7.1
*CVSS v3.1

Exploit Likelihood

*EPSS

Affected Versions

*CPE

Public Exploits

0
*Multiple Sources

Exploited in Wild

-
*KEV

Decision

Track
*SSVC
Descriptions

In the Linux kernel, the following vulnerability has been resolved:

swiotlb: Fix double-allocation of slots due to broken alignment handling

Commit bbb73a103fbb ("swiotlb: fix a braino in the alignment check fix"),
which was a fix for commit 0eee5ae10256 ("swiotlb: fix slot alignment
checks"), causes a functional regression with vsock in a virtual machine
using bouncing via a restricted DMA SWIOTLB pool.

When virtio allocates the virtqueues for the vsock device using
dma_alloc_coherent(), the SWIOTLB search can return page-unaligned
allocations if 'area->index' was left unaligned by a previous allocation
from the buffer:

# Final address in brackets is the SWIOTLB address returned to the caller
| virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1645-1649/7168 (0x98326800)
| virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1649-1653/7168 (0x98328800)
| virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1653-1657/7168 (0x9832a800)

This ends badly (typically buffer corruption and/or a hang) because
swiotlb_alloc() is expecting a page-aligned allocation and so blindly
returns a pointer to the 'struct page' corresponding to the allocation,
therefore double-allocating the first half (2KiB slot) of the 4KiB page.

Fix the problem by treating the allocation alignment separately to any
additional alignment requirements from the device, using the maximum
of the two as the stride to search the buffer slots and taking care
to ensure a minimum of page-alignment for buffers larger than a page.

This also resolves swiotlb allocation failures occuring due to the
inclusion of ~PAGE_MASK in 'iotlb_align_mask' for large allocations and
resulting in alignment requirements exceeding swiotlb_max_mapping_size().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: swiotlb: corregida la doble asignación de ranuras debido a un manejo de alineación roto. Confirmación bbb73a103fbb ("swiotlb: corrija un barino en la corrección de verificación de alineación"), que fue una solución para la confirmación 0eee5ae10256 ( "swiotlb: corregir comprobaciones de alineación de ranuras"), provoca una regresión funcional con vsock en una máquina virtual mediante el rebote a través de un grupo DMA SWIOTLB restringido. Cuando virtio asigna las colas virtio para el dispositivo vsock usando dma_alloc_coherent(), la búsqueda de SWIOTLB puede devolver asignaciones de página no alineadas si 'area->index' quedó desalineado por una asignación anterior del búfer: # La dirección final entre paréntesis es la dirección de SWIOTLB devuelto a la persona que llama | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: obtuvo la ranura 1645-1649/7168 (0x98326800) | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: obtuvo la ranura 1649-1653/7168 (0x98328800) | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: obtuvo la ranura 1653-1657/7168 (0x9832a800) Esto termina mal (normalmente corrupción del búfer y/o bloqueo) porque swiotlb_alloc() está esperando una página -asignación alineada y, por lo tanto, devuelve ciegamente un puntero a la 'struct page' correspondiente a la asignación, por lo que asigna dos veces la primera mitad (ranura de 2 KB) de la página de 4 KB. Solucione el problema tratando la alineación de asignación por separado de cualquier requisito de alineación adicional del dispositivo, utilizando el máximo de los dos como paso para buscar las ranuras del búfer y teniendo cuidado de garantizar un mínimo de alineación de página para búferes más grandes que una página. Esto también resuelve las fallos de asignación de swiotlb que ocurren debido a la inclusión de ~PAGE_MASK en 'iotlb_align_mask' para asignaciones grandes y que resultan en requisitos de alineación que exceden swiotlb_max_mapping_size().

*Credits: N/A
CVSS Scores
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
High
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High
* Common Vulnerability Scoring System
SSVC
  • Decision:Track
Exploitation
None
Automatable
No
Tech. Impact
Partial
* Organization's Worst-case Scenario
Timeline
  • 2024-05-17 CVE Reserved
  • 2024-05-17 CVE Published
  • 2024-05-18 EPSS Updated
  • 2024-12-19 CVE Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
  • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
  • CWE-1055: Multiple Inheritance from Concrete Classes
CAPEC
Affected Vendors, Products, and Versions
Vendor Product Version Other Status
Vendor Product Version Other Status <-- --> Vendor Product Version Other Status
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.3 < 6.6.24
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.3 < 6.6.24"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.3 < 6.7.12
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.3 < 6.7.12"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.3 < 6.8.3
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.3 < 6.8.3"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.3 < 6.9
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.3 < 6.9"
en
Affected