{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2024-50250", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-10-21T19:36:19.979Z", "datePublished": "2024-11-09T10:14:59.003Z", "dateUpdated": "2024-12-19T09:36:32.859Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-12-19T09:36:32.859Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfsdax: dax_unshare_iter needs to copy entire blocks\n\nThe code that copies data from srcmap to iomap in dax_unshare_iter is\nvery very broken, which bfoster's recent fsx changes have exposed.\n\nIf the pos and len passed to dax_file_unshare are not aligned to an\nfsblock boundary, the iter pos and length in the _iter function will\nreflect this unalignment.\n\ndax_iomap_direct_access always returns a pointer to the start of the\nkmapped fsdax page, even if its pos argument is in the middle of that\npage. This is catastrophic for data integrity when iter->pos is not\naligned to a page, because daddr/saddr do not point to the same byte in\nthe file as iter->pos. Hence we corrupt user data by copying it to the\nwrong place.\n\nIf iter->pos + iomap_length() in the _iter function not aligned to a\npage, then we fail to copy a full block, and only partially populate the\ndestination block. This is catastrophic for data confidentiality\nbecause we expose stale pmem contents.\n\nFix both of these issues by aligning copy_pos/copy_len to a page\nboundary (remember, this is fsdax so 1 fsblock == 1 base page) so that\nwe always copy full blocks.\n\nWe're not done yet -- there's no call to invalidate_inode_pages2_range,\nso programs that have the file range mmap'd will continue accessing the\nold memory mapping after the file metadata updates have completed.\n\nBe careful with the return value -- if the unshare succeeds, we still\nneed to return the number of bytes that the iomap iter thinks we're\noperating on."}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["fs/dax.c"], "versions": [{"version": "1bec6782a25c9b92c203ea7a1b3e3dc6a468cbc4", "lessThan": "bdbc96c23197d773a7d1bf03e4f11de593b0ff28", "status": "affected", "versionType": "git"}, {"version": "d984648e428bf88cbd94ebe346c73632cb92fffb", "lessThan": "9bc18bb476e50e32e5d08f2734d63d63e0fa528c", "status": "affected", "versionType": "git"}, {"version": "d984648e428bf88cbd94ebe346c73632cb92fffb", "lessThan": "8e9c0f500b42216ef930f5c0d1703989a451913d", "status": "affected", "versionType": "git"}, {"version": "d984648e428bf88cbd94ebe346c73632cb92fffb", "lessThan": "50793801fc7f6d08def48754fb0f0706b0cfc394", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["fs/dax.c"], "versions": [{"version": "6.2", "status": "affected"}, {"version": "0", "lessThan": "6.2", "status": "unaffected", "versionType": "semver"}, {"version": "6.1.116", "lessThanOrEqual": "6.1.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.6.60", "lessThanOrEqual": "6.6.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.11.7", "lessThanOrEqual": "6.11.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.12", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "references": [{"url": "https://git.kernel.org/stable/c/bdbc96c23197d773a7d1bf03e4f11de593b0ff28"}, {"url": "https://git.kernel.org/stable/c/9bc18bb476e50e32e5d08f2734d63d63e0fa528c"}, {"url": "https://git.kernel.org/stable/c/8e9c0f500b42216ef930f5c0d1703989a451913d"}, {"url": "https://git.kernel.org/stable/c/50793801fc7f6d08def48754fb0f0706b0cfc394"}], "title": "fsdax: dax_unshare_iter needs to copy entire blocks", "x_generator": {"engine": "bippy-5f407fcff5a0"}}}}

{}

{"configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "0784ED09-D629-4871-A504-544E89D6604D", "versionEndExcluding": "6.1.116", "versionStartIncluding": "6.1.113", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "75088E5E-2400-4D20-915F-7A65C55D9CCD", "versionEndExcluding": "6.6.60", "versionStartIncluding": "6.2", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "E96F53A4-5E87-4A70-BD9A-BC327828D57F", "versionEndExcluding": "6.11.7", "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}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc3:*:*:*:*:*:*", "matchCriteriaId": "3C95E234-D335-4B6C-96BF-E2CEBD8654ED", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc4:*:*:*:*:*:*", "matchCriteriaId": "E0F717D8-3014-4F84-8086-0124B2111379", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc5:*:*:*:*:*:*", "matchCriteriaId": "24DBE6C7-2AAE-4818-AED2-E131F153D2FA", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfsdax: dax_unshare_iter needs to copy entire blocks\n\nThe code that copies data from srcmap to iomap in dax_unshare_iter is\nvery very broken, which bfoster's recent fsx changes have exposed.\n\nIf the pos and len passed to dax_file_unshare are not aligned to an\nfsblock boundary, the iter pos and length in the _iter function will\nreflect this unalignment.\n\ndax_iomap_direct_access always returns a pointer to the start of the\nkmapped fsdax page, even if its pos argument is in the middle of that\npage. This is catastrophic for data integrity when iter->pos is not\naligned to a page, because daddr/saddr do not point to the same byte in\nthe file as iter->pos. Hence we corrupt user data by copying it to the\nwrong place.\n\nIf iter->pos + iomap_length() in the _iter function not aligned to a\npage, then we fail to copy a full block, and only partially populate the\ndestination block. This is catastrophic for data confidentiality\nbecause we expose stale pmem contents.\n\nFix both of these issues by aligning copy_pos/copy_len to a page\nboundary (remember, this is fsdax so 1 fsblock == 1 base page) so that\nwe always copy full blocks.\n\nWe're not done yet -- there's no call to invalidate_inode_pages2_range,\nso programs that have the file range mmap'd will continue accessing the\nold memory mapping after the file metadata updates have completed.\n\nBe careful with the return value -- if the unshare succeeds, we still\nneed to return the number of bytes that the iomap iter thinks we're\noperating on."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fsdax: dax_unshare_iter necesita copiar bloques enteros El c\u00f3digo que copia datos de srcmap a iomap en dax_unshare_iter est\u00e1 muy, muy roto, lo que los cambios recientes de fsx de bfoster han expuesto. Si la posici\u00f3n y la longitud pasadas a dax_file_unshare no est\u00e1n alineadas con un l\u00edmite de fsblock, la posici\u00f3n y la longitud de iter en la funci\u00f3n _iter reflejar\u00e1n esta desalineaci\u00f3n. dax_iomap_direct_access siempre devuelve un puntero al inicio de la p\u00e1gina fsdax kmapped, incluso si su argumento pos est\u00e1 en el medio de esa p\u00e1gina. Esto es catastr\u00f3fico para la integridad de los datos cuando iter->pos no est\u00e1 alineado con una p\u00e1gina, porque daddr/saddr no apuntan al mismo byte en el archivo que iter->pos. Por lo tanto, corrompemos los datos del usuario copi\u00e1ndolos en el lugar equivocado. Si iter->pos + iomap_length() en la funci\u00f3n _iter no est\u00e1 alineado con una p\u00e1gina, entonces no copiamos un bloque completo y solo rellenamos parcialmente el bloque de destino. Esto es catastr\u00f3fico para la confidencialidad de los datos porque exponemos contenidos pmem obsoletos. Solucione ambos problemas alineando copy_pos/copy_len con un l\u00edmite de p\u00e1gina (recuerde, esto es fsdax, por lo que 1 fsblock == 1 p\u00e1gina base) de modo que siempre copiemos bloques completos. A\u00fan no hemos terminado: no hay ninguna llamada a invalidate_inode_pages2_range, por lo que los programas que tienen el rango de archivos mmap seguir\u00e1n accediendo al mapeo de memoria anterior despu\u00e9s de que se hayan completado las actualizaciones de metadatos del archivo. Tenga cuidado con el valor de retorno: si la anulaci\u00f3n del uso compartido tiene \u00e9xito, a\u00fan necesitamos devolver la cantidad de bytes en los que el iter iomap cree que estamos operando."}], "id": "CVE-2024-50250", "lastModified": "2024-11-14T17:04:14.043", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "NONE", "baseScore": 7.1, "baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 5.2, "source": "[email protected]", "type": "Primary"}]}, "published": "2024-11-09T11:15:10.833", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/50793801fc7f6d08def48754fb0f0706b0cfc394"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/8e9c0f500b42216ef930f5c0d1703989a451913d"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/9bc18bb476e50e32e5d08f2734d63d63e0fa528c"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/bdbc96c23197d773a7d1bf03e4f11de593b0ff28"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Analyzed", "weaknesses": [{"description": [{"lang": "en", "value": "NVD-CWE-noinfo"}], "source": "[email protected]", "type": "Primary"}]}

{"bugzilla": {"description": "kernel: fsdax: dax_unshare_iter needs to copy entire blocks", "id": "2324858", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2324858"}, "csaw": false, "cvss3": {"cvss3_base_score": "7.3", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H", "status": "draft"}, "cwe": "CWE-835", "details": ["In the Linux kernel, the following vulnerability has been resolved:\nfsdax: dax_unshare_iter needs to copy entire blocks\nThe code that copies data from srcmap to iomap in dax_unshare_iter is\nvery very broken, which bfoster's recent fsx changes have exposed.\nIf the pos and len passed to dax_file_unshare are not aligned to an\nfsblock boundary, the iter pos and length in the _iter function will\nreflect this unalignment.\ndax_iomap_direct_access always returns a pointer to the start of the\nkmapped fsdax page, even if its pos argument is in the middle of that\npage. This is catastrophic for data integrity when iter->pos is not\naligned to a page, because daddr/saddr do not point to the same byte in\nthe file as iter->pos. Hence we corrupt user data by copying it to the\nwrong place.\nIf iter->pos + iomap_length() in the _iter function not aligned to a\npage, then we fail to copy a full block, and only partially populate the\ndestination block. This is catastrophic for data confidentiality\nbecause we expose stale pmem contents.\nFix both of these issues by aligning copy_pos/copy_len to a page\nboundary (remember, this is fsdax so 1 fsblock == 1 base page) so that\nwe always copy full blocks.\nWe're not done yet -- there's no call to invalidate_inode_pages2_range,\nso programs that have the file range mmap'd will continue accessing the\nold memory mapping after the file metadata updates have completed.\nBe careful with the return value -- if the unshare succeeds, we still\nneed to return the number of bytes that the iomap iter thinks we're\noperating on.", "A buffer overrun exists in the Linux kernel. When pos and len are passed to dax_file_unshare, they are not aligned to an fsblock boundary, and the iteration of pos and length in the _iter function will reflect this."], "mitigation": {"lang": "en:us", "value": "Mitigation for this issue is either not available or the currently available options don't meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability."}, "name": "CVE-2024-50250", "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-11-09T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2024-50250\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-50250\nhttps://lore.kernel.org/linux-cve-announce/2024110936-CVE-2024-50250-eb8a@gregkh/T"], "threat_severity": "Moderate"}