CVE-2022-48853

{"id": "CVE-2022-48853", "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.5, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "NONE", "privilegesRequired": "LOW", "confidentialityImpact": "HIGH"}, "impactScore": 3.6, "exploitabilityScore": 1.8}]}, "published": "2024-07-16T13:15:12.380", "references": [{"url": "https://git.kernel.org/stable/c/270475d6d2410ec66e971bf181afe1958dad565e", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/6bfc5377a210dbda2a237f16d94d1bd4f1335026", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/7403f4118ab94be837ab9d770507537a8057bc63", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/8d9ac1b6665c73f23e963775f85d99679fd8e192", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/971e5dadffd02beba1063e7dd9c3a82de17cf534", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/c132f2ba716b5ee6b35f82226a6e5417d013d753", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/d4d975e7921079f877f828099bb8260af335508f", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/270475d6d2410ec66e971bf181afe1958dad565e", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/6bfc5377a210dbda2a237f16d94d1bd4f1335026", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/7403f4118ab94be837ab9d770507537a8057bc63", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/8d9ac1b6665c73f23e963775f85d99679fd8e192", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/971e5dadffd02beba1063e7dd9c3a82de17cf534", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/c132f2ba716b5ee6b35f82226a6e5417d013d753", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/d4d975e7921079f877f828099bb8260af335508f", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}], "vulnStatus": "Modified", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "NVD-CWE-noinfo"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nswiotlb: fix info leak with DMA_FROM_DEVICE\n\nThe problem I'm addressing was discovered by the LTP test covering\ncve-2018-1000204.\n\nA short description of what happens follows:\n1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO\n interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV\n and a corresponding dxferp. The peculiar thing about this is that TUR\n is not reading from the device.\n2) In sg_start_req() the invocation of blk_rq_map_user() effectively\n bounces the user-space buffer. As if the device was to transfer into\n it. Since commit a45b599ad808 (\"scsi: sg: allocate with __GFP_ZERO in\n sg_build_indirect()\") we make sure this first bounce buffer is\n allocated with GFP_ZERO.\n3) For the rest of the story we keep ignoring that we have a TUR, so the\n device won't touch the buffer we prepare as if the we had a\n DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device\n and the buffer allocated by SG is mapped by the function\n virtqueue_add_split() which uses DMA_FROM_DEVICE for the \"in\" sgs (here\n scatter-gather and not scsi generics). This mapping involves bouncing\n via the swiotlb (we need swiotlb to do virtio in protected guest like\n s390 Secure Execution, or AMD SEV).\n4) When the SCSI TUR is done, we first copy back the content of the second\n (that is swiotlb) bounce buffer (which most likely contains some\n previous IO data), to the first bounce buffer, which contains all\n zeros. Then we copy back the content of the first bounce buffer to\n the user-space buffer.\n5) The test case detects that the buffer, which it zero-initialized,\n ain't all zeros and fails.\n\nOne can argue that this is an swiotlb problem, because without swiotlb\nwe leak all zeros, and the swiotlb should be transparent in a sense that\nit does not affect the outcome (if all other participants are well\nbehaved).\n\nCopying the content of the original buffer into the swiotlb buffer is\nthe only way I can think of to make swiotlb transparent in such\nscenarios. So let's do just that if in doubt, but allow the driver\nto tell us that the whole mapped buffer is going to be overwritten,\nin which case we can preserve the old behavior and avoid the performance\nimpact of the extra bounce."}, {"lang": "es", "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: swiotlb: corrige la fuga de informaci\u00f3n con DMA_FROM_DEVICE El problema que estoy abordando fue descubierto mediante la prueba LTP que cubre cve-2018-1000204. A continuaci\u00f3n se ofrece una breve descripci\u00f3n de lo que sucede: 1) El caso de prueba emite un c\u00f3digo de comando 00 (UNIDAD DE PRUEBA LISTO) a trav\u00e9s de la interfaz SG_IO con: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV y un dxferp correspondiente. Lo peculiar de esto es que TUR no lee desde el dispositivo. 2) En sg_start_req() la invocaci\u00f3n de blk_rq_map_user() efectivamente rebota el buffer del espacio de usuario. Como si el dispositivo fuera a transferirse a \u00e9l. Desde El commit a45b599ad808 (\"scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()\") nos aseguramos de que este primer b\u00fafer de rebote est\u00e9 asignado con GFP_ZERO. 3) Durante el resto de la historia seguimos ignorando que tenemos un TUR, por lo que el dispositivo no tocar\u00e1 el buffer que preparamos como si tuvi\u00e9ramos una situaci\u00f3n del tipo DMA_FROM_DEVICE. Mi configuraci\u00f3n utiliza un dispositivo virtio-scsi y el b\u00fafer asignado por SG se asigna mediante la funci\u00f3n virtqueue_add_split() que usa DMA_FROM_DEVICE para los sgs \"in\" (aqu\u00ed scatter-gather y no gen\u00e9ricos scsi). Este mapeo implica rebotar a trav\u00e9s de swiotlb (necesitamos swiotlb para hacer virtio en un invitado protegido como s390 Secure Execution o AMD SEV). 4) Cuando finaliza el SCSI TUR, primero copiamos el contenido del segundo b\u00fafer de rebote (es decir, swiotlb) (que probablemente contiene algunos datos de IO anteriores) al primer b\u00fafer de rebote, que contiene todos ceros. Luego volvemos a copiar el contenido del primer b\u00fafer de rebote al b\u00fafer de espacio de usuario. 5) El caso de prueba detecta que el b\u00fafer, que inicializ\u00f3 en cero, no es todo ceros y falla. Se puede argumentar que se trata de un problema de swiotlb, porque sin swiotlb se filtran todos los ceros, y swiotlb deber\u00eda ser transparente en el sentido de que no afecte el resultado (si todos los dem\u00e1s participantes se portan bien). Copiar el contenido del b\u00fafer original en el b\u00fafer swiotlb es la \u00fanica forma que se me ocurre para hacer que swiotlb sea transparente en tales escenarios. Entonces, hagamos eso en caso de duda, pero permitamos que el controlador nos diga que se sobrescribir\u00e1 todo el b\u00fafer asignado, en cuyo caso podemos preservar el comportamiento anterior y evitar el impacto en el rendimiento del rebote adicional."}], "lastModified": "2024-11-21T07:34:12.970", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "CF939175-79DE-4866-B38C-4C8F9896B785", "versionEndExcluding": "4.9.320"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "EBB1A3B4-E46A-4454-A428-85CC0AC925F6", "versionEndExcluding": "4.14.281", "versionStartIncluding": "4.10"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "239757EB-B2DF-4DD4-8EEE-97141186DA12", "versionEndExcluding": "4.19.245", "versionStartIncluding": "4.15"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "8CB6E8F5-C2B1-46F3-A807-0F6104AC340F", "versionEndExcluding": "5.4.189", "versionStartIncluding": "4.20"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "91D3BFD0-D3F3-4018-957C-96CCBF357D79", "versionEndExcluding": "5.10.110", "versionStartIncluding": "5.5"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "15DC6588-B28F-4637-9A1E-3753B34A40CF", "versionEndExcluding": "5.15.29", "versionStartIncluding": "5.11"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "83FDEDF2-0E19-4879-91FD-171E66D1B335", "versionEndExcluding": "5.16.15", "versionStartIncluding": "5.16"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}