CVE-2024-35814

{"id": "CVE-2024-35814", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Secondary", "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 7.1, "attackVector": "LOCAL", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 5.2, "exploitabilityScore": 1.8}]}, "published": "2024-05-17T14:15:15.853", "references": [{"url": "https://git.kernel.org/stable/c/04867a7a33324c9c562ee7949dbcaab7aaad1fb4", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/3e7acd6e25ba77dde48c3b721c54c89cd6a10534", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/777391743771040e12cc40d3d0d178f70c616491", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/c88668aa6c1da240ea3eb4d128b7906e740d3cb8", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Awaiting Analysis", "weaknesses": [{"type": "Secondary", "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "description": [{"lang": "en", "value": "CWE-1055"}, {"lang": "en", "value": "CWE-119"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nswiotlb: Fix double-allocation of slots due to broken alignment handling\n\nCommit bbb73a103fbb (\"swiotlb: fix a braino in the alignment check fix\"),\nwhich was a fix for commit 0eee5ae10256 (\"swiotlb: fix slot alignment\nchecks\"), causes a functional regression with vsock in a virtual machine\nusing bouncing via a restricted DMA SWIOTLB pool.\n\nWhen virtio allocates the virtqueues for the vsock device using\ndma_alloc_coherent(), the SWIOTLB search can return page-unaligned\nallocations if 'area->index' was left unaligned by a previous allocation\nfrom the buffer:\n\n # Final address in brackets is the SWIOTLB address returned to the caller\n | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1645-1649/7168 (0x98326800)\n | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1649-1653/7168 (0x98328800)\n | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1653-1657/7168 (0x9832a800)\n\nThis ends badly (typically buffer corruption and/or a hang) because\nswiotlb_alloc() is expecting a page-aligned allocation and so blindly\nreturns a pointer to the 'struct page' corresponding to the allocation,\ntherefore double-allocating the first half (2KiB slot) of the 4KiB page.\n\nFix the problem by treating the allocation alignment separately to any\nadditional alignment requirements from the device, using the maximum\nof the two as the stride to search the buffer slots and taking care\nto ensure a minimum of page-alignment for buffers larger than a page.\n\nThis also resolves swiotlb allocation failures occuring due to the\ninclusion of ~PAGE_MASK in 'iotlb_align_mask' for large allocations and\nresulting in alignment requirements exceeding swiotlb_max_mapping_size()."}, {"lang": "es", "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: swiotlb: corregida la doble asignaci\u00f3n de ranuras debido a un manejo de alineaci\u00f3n roto. Confirmaci\u00f3n bbb73a103fbb (\"swiotlb: corrija un barino en la correcci\u00f3n de verificaci\u00f3n de alineaci\u00f3n\"), que fue una soluci\u00f3n para la confirmaci\u00f3n 0eee5ae10256 ( \"swiotlb: corregir comprobaciones de alineaci\u00f3n de ranuras\"), provoca una regresi\u00f3n funcional con vsock en una m\u00e1quina virtual mediante el rebote a trav\u00e9s de un grupo DMA SWIOTLB restringido. Cuando virtio asigna las colas virtio para el dispositivo vsock usando dma_alloc_coherent(), la b\u00fasqueda de SWIOTLB puede devolver asignaciones de p\u00e1gina no alineadas si 'area->index' qued\u00f3 desalineado por una asignaci\u00f3n anterior del b\u00fafer: # La direcci\u00f3n final entre par\u00e9ntesis es la direcci\u00f3n 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\u00f3n del b\u00fafer y/o bloqueo) porque swiotlb_alloc() est\u00e1 esperando una p\u00e1gina -asignaci\u00f3n alineada y, por lo tanto, devuelve ciegamente un puntero a la 'struct page' correspondiente a la asignaci\u00f3n, por lo que asigna dos veces la primera mitad (ranura de 2 KB) de la p\u00e1gina de 4 KB. Solucione el problema tratando la alineaci\u00f3n de asignaci\u00f3n por separado de cualquier requisito de alineaci\u00f3n adicional del dispositivo, utilizando el m\u00e1ximo de los dos como paso para buscar las ranuras del b\u00fafer y teniendo cuidado de garantizar un m\u00ednimo de alineaci\u00f3n de p\u00e1gina para b\u00faferes m\u00e1s grandes que una p\u00e1gina. Esto tambi\u00e9n resuelve las fallos de asignaci\u00f3n de swiotlb que ocurren debido a la inclusi\u00f3n de ~PAGE_MASK en 'iotlb_align_mask' para asignaciones grandes y que resultan en requisitos de alineaci\u00f3n que exceden swiotlb_max_mapping_size()."}], "lastModified": "2024-07-03T02:02:13.390", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}