fkie_cve-2022-48853
Vulnerability from fkie_nvd
Published
2024-07-16 13:15
Modified
2025-01-24 16:15
Severity ?
5.5 (Medium) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Summary
In the Linux kernel, the following vulnerability has been resolved: swiotlb: fix info leak with DMA_FROM_DEVICE The problem I'm addressing was discovered by the LTP test covering cve-2018-1000204. A short description of what happens follows: 1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV and a corresponding dxferp. The peculiar thing about this is that TUR is not reading from the device. 2) In sg_start_req() the invocation of blk_rq_map_user() effectively bounces the user-space buffer. As if the device was to transfer into it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") we make sure this first bounce buffer is allocated with GFP_ZERO. 3) For the rest of the story we keep ignoring that we have a TUR, so the device won't touch the buffer we prepare as if the we had a DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device and the buffer allocated by SG is mapped by the function virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here scatter-gather and not scsi generics). This mapping involves bouncing via the swiotlb (we need swiotlb to do virtio in protected guest like s390 Secure Execution, or AMD SEV). 4) When the SCSI TUR is done, we first copy back the content of the second (that is swiotlb) bounce buffer (which most likely contains some previous IO data), to the first bounce buffer, which contains all zeros. Then we copy back the content of the first bounce buffer to the user-space buffer. 5) The test case detects that the buffer, which it zero-initialized, ain't all zeros and fails. One can argue that this is an swiotlb problem, because without swiotlb we leak all zeros, and the swiotlb should be transparent in a sense that it does not affect the outcome (if all other participants are well behaved). Copying the content of the original buffer into the swiotlb buffer is the only way I can think of to make swiotlb transparent in such scenarios. So let's do just that if in doubt, but allow the driver to tell us that the whole mapped buffer is going to be overwritten, in which case we can preserve the old behavior and avoid the performance impact of the extra bounce.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/270475d6d2410ec66e971bf181afe1958dad565ePatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/6bfc5377a210dbda2a237f16d94d1bd4f1335026Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/7403f4118ab94be837ab9d770507537a8057bc63Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/8d9ac1b6665c73f23e963775f85d99679fd8e192Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/971e5dadffd02beba1063e7dd9c3a82de17cf534Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/c132f2ba716b5ee6b35f82226a6e5417d013d753Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8ePatch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/270475d6d2410ec66e971bf181afe1958dad565ePatch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/6bfc5377a210dbda2a237f16d94d1bd4f1335026Patch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/7403f4118ab94be837ab9d770507537a8057bc63Patch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/8d9ac1b6665c73f23e963775f85d99679fd8e192Patch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/971e5dadffd02beba1063e7dd9c3a82de17cf534Patch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/c132f2ba716b5ee6b35f82226a6e5417d013d753Patch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/d4d975e7921079f877f828099bb8260af335508fPatch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8ePatch
Impacted products
Vendor Product Version
linux linux_kernel *
linux linux_kernel *
linux linux_kernel *
linux linux_kernel *
linux linux_kernel *
linux linux_kernel *
linux linux_kernel *


To clipboard 

{
   configurations: [
      {
         nodes: [
            {
               cpeMatch: [
                  {
                     criteria: "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                     matchCriteriaId: "CF939175-79DE-4866-B38C-4C8F9896B785",
                     versionEndExcluding: "4.9.320",
                     vulnerable: true,
                  },
                  {
                     criteria: "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                     matchCriteriaId: "EBB1A3B4-E46A-4454-A428-85CC0AC925F6",
                     versionEndExcluding: "4.14.281",
                     versionStartIncluding: "4.10",
                     vulnerable: true,
                  },
                  {
                     criteria: "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                     matchCriteriaId: "239757EB-B2DF-4DD4-8EEE-97141186DA12",
                     versionEndExcluding: "4.19.245",
                     versionStartIncluding: "4.15",
                     vulnerable: true,
                  },
                  {
                     criteria: "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                     matchCriteriaId: "8CB6E8F5-C2B1-46F3-A807-0F6104AC340F",
                     versionEndExcluding: "5.4.189",
                     versionStartIncluding: "4.20",
                     vulnerable: true,
                  },
                  {
                     criteria: "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                     matchCriteriaId: "91D3BFD0-D3F3-4018-957C-96CCBF357D79",
                     versionEndExcluding: "5.10.110",
                     versionStartIncluding: "5.5",
                     vulnerable: true,
                  },
                  {
                     criteria: "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                     matchCriteriaId: "15DC6588-B28F-4637-9A1E-3753B34A40CF",
                     versionEndExcluding: "5.15.29",
                     versionStartIncluding: "5.11",
                     vulnerable: true,
                  },
                  {
                     criteria: "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                     matchCriteriaId: "83FDEDF2-0E19-4879-91FD-171E66D1B335",
                     versionEndExcluding: "5.16.15",
                     versionStartIncluding: "5.16",
                     vulnerable: true,
                  },
               ],
               negate: false,
               operator: "OR",
            },
         ],
      },
   ],
   cveTags: [],
   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ó la siguiente vulnerabilidad: swiotlb: corrige la fuga de información con DMA_FROM_DEVICE El problema que estoy abordando fue descubierto mediante la prueba LTP que cubre cve-2018-1000204. A continuación se ofrece una breve descripción de lo que sucede: 1) El caso de prueba emite un código de comando 00 (UNIDAD DE PRUEBA LISTO) a través 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ón de blk_rq_map_user() efectivamente rebota el buffer del espacio de usuario. Como si el dispositivo fuera a transferirse a él. Desde El commit a45b599ad808 (\"scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()\") nos aseguramos de que este primer búfer de rebote esté asignado con GFP_ZERO. 3) Durante el resto de la historia seguimos ignorando que tenemos un TUR, por lo que el dispositivo no tocará el buffer que preparamos como si tuviéramos una situación del tipo DMA_FROM_DEVICE. Mi configuración utiliza un dispositivo virtio-scsi y el búfer asignado por SG se asigna mediante la función virtqueue_add_split() que usa DMA_FROM_DEVICE para los sgs \"in\" (aquí scatter-gather y no genéricos scsi). Este mapeo implica rebotar a través 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úfer de rebote (es decir, swiotlb) (que probablemente contiene algunos datos de IO anteriores) al primer búfer de rebote, que contiene todos ceros. Luego volvemos a copiar el contenido del primer búfer de rebote al búfer de espacio de usuario. 5) El caso de prueba detecta que el búfer, que inicializó 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ía ser transparente en el sentido de que no afecte el resultado (si todos los demás participantes se portan bien). Copiar el contenido del búfer original en el búfer swiotlb es la única 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á todo el búfer asignado, en cuyo caso podemos preservar el comportamiento anterior y evitar el impacto en el rendimiento del rebote adicional.",
      },
   ],
   id: "CVE-2022-48853",
   lastModified: "2025-01-24T16:15:28.903",
   metrics: {
      cvssMetricV31: [
         {
            cvssData: {
               attackComplexity: "LOW",
               attackVector: "LOCAL",
               availabilityImpact: "NONE",
               baseScore: 5.5,
               baseSeverity: "MEDIUM",
               confidentialityImpact: "HIGH",
               integrityImpact: "NONE",
               privilegesRequired: "LOW",
               scope: "UNCHANGED",
               userInteraction: "NONE",
               vectorString: "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
               version: "3.1",
            },
            exploitabilityScore: 1.8,
            impactScore: 3.6,
            source: "nvd@nist.gov",
            type: "Primary",
         },
      ],
   },
   published: "2024-07-16T13:15:12.380",
   references: [
      {
         source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
         tags: [
            "Patch",
         ],
         url: "https://git.kernel.org/stable/c/270475d6d2410ec66e971bf181afe1958dad565e",
      },
      {
         source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
         tags: [
            "Patch",
         ],
         url: "https://git.kernel.org/stable/c/6bfc5377a210dbda2a237f16d94d1bd4f1335026",
      },
      {
         source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
         tags: [
            "Patch",
         ],
         url: "https://git.kernel.org/stable/c/7403f4118ab94be837ab9d770507537a8057bc63",
      },
      {
         source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
         tags: [
            "Patch",
         ],
         url: "https://git.kernel.org/stable/c/8d9ac1b6665c73f23e963775f85d99679fd8e192",
      },
      {
         source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
         tags: [
            "Patch",
         ],
         url: "https://git.kernel.org/stable/c/971e5dadffd02beba1063e7dd9c3a82de17cf534",
      },
      {
         source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
         tags: [
            "Patch",
         ],
         url: "https://git.kernel.org/stable/c/c132f2ba716b5ee6b35f82226a6e5417d013d753",
      },
      {
         source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
         tags: [
            "Patch",
         ],
         url: "https://git.kernel.org/stable/c/ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e",
      },
      {
         source: "af854a3a-2127-422b-91ae-364da2661108",
         tags: [
            "Patch",
         ],
         url: "https://git.kernel.org/stable/c/270475d6d2410ec66e971bf181afe1958dad565e",
      },
      {
         source: "af854a3a-2127-422b-91ae-364da2661108",
         tags: [
            "Patch",
         ],
         url: "https://git.kernel.org/stable/c/6bfc5377a210dbda2a237f16d94d1bd4f1335026",
      },
      {
         source: "af854a3a-2127-422b-91ae-364da2661108",
         tags: [
            "Patch",
         ],
         url: "https://git.kernel.org/stable/c/7403f4118ab94be837ab9d770507537a8057bc63",
      },
      {
         source: "af854a3a-2127-422b-91ae-364da2661108",
         tags: [
            "Patch",
         ],
         url: "https://git.kernel.org/stable/c/8d9ac1b6665c73f23e963775f85d99679fd8e192",
      },
      {
         source: "af854a3a-2127-422b-91ae-364da2661108",
         tags: [
            "Patch",
         ],
         url: "https://git.kernel.org/stable/c/971e5dadffd02beba1063e7dd9c3a82de17cf534",
      },
      {
         source: "af854a3a-2127-422b-91ae-364da2661108",
         tags: [
            "Patch",
         ],
         url: "https://git.kernel.org/stable/c/c132f2ba716b5ee6b35f82226a6e5417d013d753",
      },
      {
         source: "af854a3a-2127-422b-91ae-364da2661108",
         tags: [
            "Patch",
         ],
         url: "https://git.kernel.org/stable/c/d4d975e7921079f877f828099bb8260af335508f",
      },
      {
         source: "af854a3a-2127-422b-91ae-364da2661108",
         tags: [
            "Patch",
         ],
         url: "https://git.kernel.org/stable/c/ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e",
      },
   ],
   sourceIdentifier: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   vulnStatus: "Modified",
   weaknesses: [
      {
         description: [
            {
               lang: "en",
               value: "NVD-CWE-noinfo",
            },
         ],
         source: "nvd@nist.gov",
         type: "Primary",
      },
   ],
}


Log in or create an account to share your comment.

Security Advisory comment format.

This schema specifies the format of a comment related to a security advisory.

UUIDv4 of the comment
UUIDv4 of the Vulnerability-Lookup instance
When the comment was created originally
When the comment was last updated
Title of the comment
Description of the comment
The identifier of the vulnerability (CVE ID, GHSA-ID, PYSEC ID, etc.).



Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.