{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2024-50022", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-10-21T12:17:06.064Z", "datePublished": "2024-10-21T19:39:27.873Z", "dateUpdated": "2024-11-05T09:53:39.491Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-11-05T09:53:39.491Z"}, "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->address not aligned to fault_size will be aligned to the next\nalignment, that can result in memory failure getting the wrong address.\n\nIt's 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's 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)"}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["drivers/dax/device.c"], "versions": [{"version": "b9b5777f09be", "lessThan": "9c4198dfdca8", "status": "affected", "versionType": "git"}, {"version": "b9b5777f09be", "lessThan": "b822007e8db3", "status": "affected", "versionType": "git"}, {"version": "b9b5777f09be", "lessThan": "e877427d2181", "status": "affected", "versionType": "git"}, {"version": "b9b5777f09be", "lessThan": "7fcbd9785d4c", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["drivers/dax/device.c"], "versions": [{"version": "5.17", "status": "affected"}, {"version": "0", "lessThan": "5.17", "status": "unaffected", "versionType": "semver"}, {"version": "6.1.113", "lessThanOrEqual": "6.1.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.6.57", "lessThanOrEqual": "6.6.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.11.4", "lessThanOrEqual": "6.11.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.12-rc3", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "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-9e1c9544281a"}}, "adp": [{"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"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-10-22T13:28:47.118Z"}}]}}

{"dataType": "CVE_RECORD", "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->address not aligned to fault_size will be aligned to the next\nalignment, that can result in memory failure getting the wrong address.\n\nIt's 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's 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"}, "dataVersion": "5.1"}

{"configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "09358D68-A717-469E-B900-8002A642E29A", "versionEndExcluding": "6.1.113", "versionStartIncluding": "5.17", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "05D83DB8-7465-4F88-AFB2-980011992AC1", "versionEndExcluding": "6.6.57", "versionStartIncluding": "6.2", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "AA84D336-CE9A-4535-B901-1AD77EC17C34", "versionEndExcluding": "6.11.4", "versionStartIncluding": "6.7", "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", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "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->address not aligned to fault_size will be aligned to the next\nalignment, that can result in memory failure getting the wrong address.\n\nIt's 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's 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->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)"}], "id": "CVE-2024-50022", "lastModified": "2024-10-25T15:05:57.403", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 5.5, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 3.6, "source": "nvd@nist.gov", "type": "Primary"}]}, "published": "2024-10-21T20:15:15.690", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "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"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Analyzed", "weaknesses": [{"description": [{"lang": "en", "value": "NVD-CWE-noinfo"}], "source": "nvd@nist.gov", "type": "Primary"}]}

{"bugzilla": {"description": "kernel: device-dax: correct pgoff align in dax_set_mapping()", "id": "2320598", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2320598"}, "csaw": false, "cvss3": {"cvss3_base_score": "5.5", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "details": ["In the Linux kernel, the following vulnerability has been resolved:\ndevice-dax: correct pgoff align in dax_set_mapping()\npgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise,\nvmf->address not aligned to fault_size will be aligned to the next\nalignment, that can result in memory failure getting the wrong address.\nIt's 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's 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.\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[ 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\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.\nJoao added:\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)"], "name": "CVE-2024-50022", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Will not fix", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-10-21T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2024-50022\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-50022\nhttps://lore.kernel.org/linux-cve-announce/2024102129-CVE-2024-50022-0531@gregkh/T"], "threat_severity": "Moderate"}