cve-2024-50022
Vulnerability from cvelistv5
Published
2024-10-21 19:39
Modified
2024-12-19 09:31
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/7fcbd9785d4c17ea533c42f20a9083a83f301fa6Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/9c4198dfdca818c5ce19c764d90eabd156bbc6daPatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/b822007e8db341d6f175c645ed79866db501ad86Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/e877427d218159ac29c9326100920d24330c9ee6Patch
Impacted products
Vendor Product Version
Linux Linux Version: b9b5777f09be84d0de472ded2253d2f5101427f2
Version: b9b5777f09be84d0de472ded2253d2f5101427f2
Version: b9b5777f09be84d0de472ded2253d2f5101427f2
Version: b9b5777f09be84d0de472ded2253d2f5101427f2
 Create a notification for this product.
   Linux Linux Version: 5.17
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-50022",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-10-22T13:27:15.558211Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-10-22T13:28:47.118Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/dax/device.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "9c4198dfdca818c5ce19c764d90eabd156bbc6da",
              "status": "affected",
              "version": "b9b5777f09be84d0de472ded2253d2f5101427f2",
              "versionType": "git"
            },
            {
              "lessThan": "b822007e8db341d6f175c645ed79866db501ad86",
              "status": "affected",
              "version": "b9b5777f09be84d0de472ded2253d2f5101427f2",
              "versionType": "git"
            },
            {
              "lessThan": "e877427d218159ac29c9326100920d24330c9ee6",
              "status": "affected",
              "version": "b9b5777f09be84d0de472ded2253d2f5101427f2",
              "versionType": "git"
            },
            {
              "lessThan": "7fcbd9785d4c17ea533c42f20a9083a83f301fa6",
              "status": "affected",
              "version": "b9b5777f09be84d0de472ded2253d2f5101427f2",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/dax/device.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.17"
            },
            {
              "lessThan": "5.17",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.113",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.57",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.11.*",
              "status": "unaffected",
              "version": "6.11.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.12",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndevice-dax: correct pgoff align in dax_set_mapping()\n\npgoff should be aligned using ALIGN_DOWN() instead of ALIGN().  Otherwise,\nvmf-\u003eaddress not aligned to fault_size will be aligned to the next\nalignment, that can result in memory failure getting the wrong address.\n\nIt\u0027s a subtle situation that only can be observed in\npage_mapped_in_vma() after the page is page fault handled by\ndev_dax_huge_fault.  Generally, there is little chance to perform\npage_mapped_in_vma in dev-dax\u0027s page unless in specific error injection\nto the dax device to trigger an MCE - memory-failure.  In that case,\npage_mapped_in_vma() will be triggered to determine which task is\naccessing the failure address and kill that task in the end.\n\n\nWe used self-developed dax device (which is 2M aligned mapping) , to\nperform error injection to random address.  It turned out that error\ninjected to non-2M-aligned address was causing endless MCE until panic.\nBecause page_mapped_in_vma() kept resulting wrong address and the task\naccessing the failure address was never killed properly:\n\n\n[ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: \nRecovered\n[ 3784.049006] mce: Uncorrected hardware memory error in user-access at \n200c9742380\n[ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: \nRecovered\n[ 3784.448042] mce: Uncorrected hardware memory error in user-access at \n200c9742380\n[ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: \nRecovered\n[ 3784.792026] mce: Uncorrected hardware memory error in user-access at \n200c9742380\n[ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: \nRecovered\n[ 3785.162502] mce: Uncorrected hardware memory error in user-access at \n200c9742380\n[ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: \nRecovered\n[ 3785.461116] mce: Uncorrected hardware memory error in user-access at \n200c9742380\n[ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: \nRecovered\n[ 3785.764730] mce: Uncorrected hardware memory error in user-access at \n200c9742380\n[ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: \nRecovered\n[ 3786.042128] mce: Uncorrected hardware memory error in user-access at \n200c9742380\n[ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: \nRecovered\n[ 3786.464293] mce: Uncorrected hardware memory error in user-access at \n200c9742380\n[ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: \nRecovered\n[ 3786.818090] mce: Uncorrected hardware memory error in user-access at \n200c9742380\n[ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: \nRecovered\n[ 3787.085297] mce: Uncorrected hardware memory error in user-access at \n200c9742380\n[ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: \nRecovered\n\nIt took us several weeks to pinpoint this problem,\u00a0 but we eventually\nused bpftrace to trace the page fault and mce address and successfully\nidentified the issue.\n\n\nJoao added:\n\n; Likely we never reproduce in production because we always pin\n: device-dax regions in the region align they provide (Qemu does\n: similarly with prealloc in hugetlb/file backed memory).  I think this\n: bug requires that we touch *unpinned* device-dax regions unaligned to\n: the device-dax selected alignment (page size i.e.  4K/2M/1G)"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2024-12-19T09:31:32.368Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/9c4198dfdca818c5ce19c764d90eabd156bbc6da"
        },
        {
          "url": "https://git.kernel.org/stable/c/b822007e8db341d6f175c645ed79866db501ad86"
        },
        {
          "url": "https://git.kernel.org/stable/c/e877427d218159ac29c9326100920d24330c9ee6"
        },
        {
          "url": "https://git.kernel.org/stable/c/7fcbd9785d4c17ea533c42f20a9083a83f301fa6"
        }
      ],
      "title": "device-dax: correct pgoff align in dax_set_mapping()",
      "x_generator": {
        "engine": "bippy-5f407fcff5a0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-50022",
    "datePublished": "2024-10-21T19:39:27.873Z",
    "dateReserved": "2024-10-21T12:17:06.064Z",
    "dateUpdated": "2024-12-19T09:31:32.368Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-50022\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-10-21T20:15:15.690\",\"lastModified\":\"2024-10-25T15:05:57.403\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\ndevice-dax: correct pgoff align in dax_set_mapping()\\n\\npgoff should be aligned using ALIGN_DOWN() instead of ALIGN().  Otherwise,\\nvmf-\u003eaddress not aligned to fault_size will be aligned to the next\\nalignment, that can result in memory failure getting the wrong address.\\n\\nIt\u0027s a subtle situation that only can be observed in\\npage_mapped_in_vma() after the page is page fault handled by\\ndev_dax_huge_fault.  Generally, there is little chance to perform\\npage_mapped_in_vma in dev-dax\u0027s page unless in specific error injection\\nto the dax device to trigger an MCE - memory-failure.  In that case,\\npage_mapped_in_vma() will be triggered to determine which task is\\naccessing the failure address and kill that task in the end.\\n\\n\\nWe used self-developed dax device (which is 2M aligned mapping) , to\\nperform error injection to random address.  It turned out that error\\ninjected to non-2M-aligned address was causing endless MCE until panic.\\nBecause page_mapped_in_vma() kept resulting wrong address and the task\\naccessing the failure address was never killed properly:\\n\\n\\n[ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3784.049006] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3784.448042] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3784.792026] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3785.162502] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3785.461116] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3785.764730] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3786.042128] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3786.464293] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3786.818090] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3787.085297] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n\\nIt took us several weeks to pinpoint this problem,\u00a0 but we eventually\\nused bpftrace to trace the page fault and mce address and successfully\\nidentified the issue.\\n\\n\\nJoao added:\\n\\n; Likely we never reproduce in production because we always pin\\n: device-dax regions in the region align they provide (Qemu does\\n: similarly with prealloc in hugetlb/file backed memory).  I think this\\n: bug requires that we touch *unpinned* device-dax regions unaligned to\\n: the device-dax selected alignment (page size i.e.  4K/2M/1G)\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: device-dax: alineaci\u00f3n correcta de pgoff en dax_set_mapping() pgoff debe alinearse usando ALIGN_DOWN() en lugar de ALIGN(). De lo contrario, vmf-\u0026gt;address no alineado con fault_size se alinear\u00e1 con la siguiente alineaci\u00f3n, lo que puede provocar que El fallo de memoria obtenga la direcci\u00f3n incorrecta. Es una situaci\u00f3n sutil que solo se puede observar en page_mapped_in_vma() despu\u00e9s de que dev_dax_huge_fault gestione El fallo de p\u00e1gina. Generalmente, hay pocas posibilidades de realizar page_mapped_in_vma en la p\u00e1gina de dev-dax a menos que se trate de una inyecci\u00f3n de error espec\u00edfica en el dispositivo dax para activar un MCE (fallo de memoria). En ese caso, se activar\u00e1 page_mapped_in_vma() para determinar qu\u00e9 tarea est\u00e1 accediendo a la direcci\u00f3n de fallo y matar esa tarea al final. Usamos un dispositivo dax desarrollado por nosotros mismos (que es un mapeo alineado de 2M) para realizar una inyecci\u00f3n de error en una direcci\u00f3n aleatoria. Result\u00f3 que el error inyectado en una direcci\u00f3n no alineada a 2M estaba causando un MCE interminable hasta que surgi\u00f3 el p\u00e1nico. Debido a que page_mapped_in_vma() segu\u00eda generando una direcci\u00f3n incorrecta y la tarea que acced\u00eda a la direcci\u00f3n fallida nunca se finalizaba correctamente: [3783.719419] Error de memoria: 0x200c9742: acci\u00f3n de recuperaci\u00f3n para la p\u00e1gina dax: recuperada [3784.049006] mce: Error de memoria de hardware sin corregir en el acceso de usuario en 200c9742380 [3784.049190] Error de memoria: 0x200c9742: acci\u00f3n de recuperaci\u00f3n para la p\u00e1gina dax: recuperada [3784.448042] mce: Error de memoria de hardware sin corregir en el acceso de usuario en 200c9742380 [3784.448186] Error de memoria: 0x200c9742: acci\u00f3n de recuperaci\u00f3n para la p\u00e1gina dax: recuperada [3784.792026] mce: Error de memoria de hardware sin corregir en el acceso de usuario en 200c9742380 [3784.792179] Error de memoria: 0x200c9742: acci\u00f3n de recuperaci\u00f3n para la p\u00e1gina dax: Recuperado [3785.162502] mce: Error de memoria de hardware sin corregir en el acceso de usuario en 200c9742380 [3785.162633] Error de memoria: 0x200c9742: acci\u00f3n de recuperaci\u00f3n para la p\u00e1gina dax: Recuperado [3785.461116] mce: Error de memoria de hardware sin corregir en el acceso de usuario en 200c9742380 [3785.461247] Error de memoria: 0x200c9742: acci\u00f3n de recuperaci\u00f3n para la p\u00e1gina dax: Recuperado [3785.764730] mce: Error de memoria de hardware sin corregir en acceso de usuario en 200c9742380 [3785.764859] Error de memoria: 0x200c9742: acci\u00f3n de recuperaci\u00f3n para la p\u00e1gina dax: Recuperado [3786.042128] mce: Error de memoria de hardware sin corregir en acceso de usuario en 200c9742380 [3786.042259] Error de memoria: 0x200c9742: acci\u00f3n de recuperaci\u00f3n para la p\u00e1gina dax: Recuperado [3786.464293] mce: Error de memoria de hardware sin corregir en acceso de usuario en 200c9742380 [3786.464423] Error de memoria: 0x200c9742: acci\u00f3n de recuperaci\u00f3n para la p\u00e1gina dax: Recuperado [3786.818090] mce: Error de memoria de hardware sin corregir en acceso de usuario en 200c9742380 [ 3786.818217] Error de memoria: 0x200c9742: acci\u00f3n de recuperaci\u00f3n para la p\u00e1gina dax: Recuperado [ 3787.085297] mce: Error de memoria de hardware sin corregir en el acceso de usuario en 200c9742380 [ 3787.085424] Error de memoria: 0x200c9742: acci\u00f3n de recuperaci\u00f3n para la p\u00e1gina dax: Recuperado Nos llev\u00f3 varias semanas localizar este problema, pero finalmente usamos bpftrace para rastrear El fallo de p\u00e1gina y la direcci\u00f3n mce e identificamos el problema con \u00e9xito. Joao agreg\u00f3: ; Es probable que nunca lo reproduzcamos en producci\u00f3n porque siempre fijamos : las regiones device-dax en la alineaci\u00f3n de regi\u00f3n que proporcionan (Qemu hace : de manera similar con prealloc en la memoria respaldada por hugetlb/archivo). Creo que este error requiere que toquemos regiones del dispositivo DAX *no fijadas* que no est\u00e9n alineadas con la alineaci\u00f3n seleccionada del dispositivo DAX (tama\u00f1o de p\u00e1gina, es decir, 4K/2M/1G)\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"NVD-CWE-noinfo\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.17\",\"versionEndExcluding\":\"6.1.113\",\"matchCriteriaId\":\"09358D68-A717-469E-B900-8002A642E29A\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.2\",\"versionEndExcluding\":\"6.6.57\",\"matchCriteriaId\":\"05D83DB8-7465-4F88-AFB2-980011992AC1\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.7\",\"versionEndExcluding\":\"6.11.4\",\"matchCriteriaId\":\"AA84D336-CE9A-4535-B901-1AD77EC17C34\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"7F361E1D-580F-4A2D-A509-7615F73167A1\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"925478D0-3E3D-4E6F-ACD5-09F28D5DF82C\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/7fcbd9785d4c17ea533c42f20a9083a83f301fa6\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/9c4198dfdca818c5ce19c764d90eabd156bbc6da\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/b822007e8db341d6f175c645ed79866db501ad86\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/e877427d218159ac29c9326100920d24330c9ee6\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2024-50022\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2024-10-22T13:27:15.558211Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2024-10-22T13:27:18.704Z\"}}], \"cna\": {\"title\": \"device-dax: correct pgoff align in dax_set_mapping()\", \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"b9b5777f09be\", \"lessThan\": \"9c4198dfdca8\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"b9b5777f09be\", \"lessThan\": \"b822007e8db3\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"b9b5777f09be\", \"lessThan\": \"e877427d2181\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"b9b5777f09be\", \"lessThan\": \"7fcbd9785d4c\", \"versionType\": \"git\"}], \"programFiles\": [\"drivers/dax/device.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"5.17\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"5.17\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"6.1.113\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.1.*\"}, {\"status\": \"unaffected\", \"version\": \"6.6.57\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.6.*\"}, {\"status\": \"unaffected\", \"version\": \"6.11.4\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.11.*\"}, {\"status\": \"unaffected\", \"version\": \"6.12-rc3\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"drivers/dax/device.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/9c4198dfdca818c5ce19c764d90eabd156bbc6da\"}, {\"url\": \"https://git.kernel.org/stable/c/b822007e8db341d6f175c645ed79866db501ad86\"}, {\"url\": \"https://git.kernel.org/stable/c/e877427d218159ac29c9326100920d24330c9ee6\"}, {\"url\": \"https://git.kernel.org/stable/c/7fcbd9785d4c17ea533c42f20a9083a83f301fa6\"}], \"x_generator\": {\"engine\": \"bippy-9e1c9544281a\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\ndevice-dax: correct pgoff align in dax_set_mapping()\\n\\npgoff should be aligned using ALIGN_DOWN() instead of ALIGN().  Otherwise,\\nvmf-\u003eaddress not aligned to fault_size will be aligned to the next\\nalignment, that can result in memory failure getting the wrong address.\\n\\nIt\u0027s a subtle situation that only can be observed in\\npage_mapped_in_vma() after the page is page fault handled by\\ndev_dax_huge_fault.  Generally, there is little chance to perform\\npage_mapped_in_vma in dev-dax\u0027s page unless in specific error injection\\nto the dax device to trigger an MCE - memory-failure.  In that case,\\npage_mapped_in_vma() will be triggered to determine which task is\\naccessing the failure address and kill that task in the end.\\n\\n\\nWe used self-developed dax device (which is 2M aligned mapping) , to\\nperform error injection to random address.  It turned out that error\\ninjected to non-2M-aligned address was causing endless MCE until panic.\\nBecause page_mapped_in_vma() kept resulting wrong address and the task\\naccessing the failure address was never killed properly:\\n\\n\\n[ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3784.049006] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3784.448042] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3784.792026] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3785.162502] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3785.461116] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3785.764730] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3786.042128] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3786.464293] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3786.818090] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n[ 3787.085297] mce: Uncorrected hardware memory error in user-access at \\n200c9742380\\n[ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: \\nRecovered\\n\\nIt took us several weeks to pinpoint this problem,\\u00a0 but we eventually\\nused bpftrace to trace the page fault and mce address and successfully\\nidentified the issue.\\n\\n\\nJoao added:\\n\\n; Likely we never reproduce in production because we always pin\\n: device-dax regions in the region align they provide (Qemu does\\n: similarly with prealloc in hugetlb/file backed memory).  I think this\\n: bug requires that we touch *unpinned* device-dax regions unaligned to\\n: the device-dax selected alignment (page size i.e.  4K/2M/1G)\"}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2024-11-05T09:53:39.491Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2024-50022\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2024-11-05T09:53:39.491Z\", \"dateReserved\": \"2024-10-21T12:17:06.064Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-10-21T19:39:27.873Z\", \"assignerShortName\": \"Linux\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}


Log in or create an account to share your comment.




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.