cve-2024-50250
Vulnerability from cvelistv5
Published
2024-11-09 10:14
Modified
2024-12-19 09:36
Severity ?
EPSS score ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
fsdax: dax_unshare_iter needs to copy entire blocks
The code that copies data from srcmap to iomap in dax_unshare_iter is
very very broken, which bfoster's recent fsx changes have exposed.
If the pos and len passed to dax_file_unshare are not aligned to an
fsblock boundary, the iter pos and length in the _iter function will
reflect this unalignment.
dax_iomap_direct_access always returns a pointer to the start of the
kmapped fsdax page, even if its pos argument is in the middle of that
page. This is catastrophic for data integrity when iter->pos is not
aligned to a page, because daddr/saddr do not point to the same byte in
the file as iter->pos. Hence we corrupt user data by copying it to the
wrong place.
If iter->pos + iomap_length() in the _iter function not aligned to a
page, then we fail to copy a full block, and only partially populate the
destination block. This is catastrophic for data confidentiality
because we expose stale pmem contents.
Fix both of these issues by aligning copy_pos/copy_len to a page
boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that
we always copy full blocks.
We're not done yet -- there's no call to invalidate_inode_pages2_range,
so programs that have the file range mmap'd will continue accessing the
old memory mapping after the file metadata updates have completed.
Be careful with the return value -- if the unshare succeeds, we still
need to return the number of bytes that the iomap iter thinks we're
operating on.
References
Impacted products
{ "containers": { "cna": { "affected": [ { "defaultStatus": "unaffected", "product": "Linux", "programFiles": [ "fs/dax.c" ], "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "versions": [ { "lessThan": "bdbc96c23197d773a7d1bf03e4f11de593b0ff28", "status": "affected", "version": "1bec6782a25c9b92c203ea7a1b3e3dc6a468cbc4", "versionType": "git" }, { "lessThan": "9bc18bb476e50e32e5d08f2734d63d63e0fa528c", "status": "affected", "version": "d984648e428bf88cbd94ebe346c73632cb92fffb", "versionType": "git" }, { "lessThan": "8e9c0f500b42216ef930f5c0d1703989a451913d", "status": "affected", "version": "d984648e428bf88cbd94ebe346c73632cb92fffb", "versionType": "git" }, { "lessThan": "50793801fc7f6d08def48754fb0f0706b0cfc394", "status": "affected", "version": "d984648e428bf88cbd94ebe346c73632cb92fffb", "versionType": "git" } ] }, { "defaultStatus": "affected", "product": "Linux", "programFiles": [ "fs/dax.c" ], "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "versions": [ { "status": "affected", "version": "6.2" }, { "lessThan": "6.2", "status": "unaffected", "version": "0", "versionType": "semver" }, { "lessThanOrEqual": "6.1.*", "status": "unaffected", "version": "6.1.116", "versionType": "semver" }, { "lessThanOrEqual": "6.6.*", "status": "unaffected", "version": "6.6.60", "versionType": "semver" }, { "lessThanOrEqual": "6.11.*", "status": "unaffected", "version": "6.11.7", "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\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\u0027s 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-\u003epos is not\naligned to a page, because daddr/saddr do not point to the same byte in\nthe file as iter-\u003epos. Hence we corrupt user data by copying it to the\nwrong place.\n\nIf iter-\u003epos + 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\u0027re not done yet -- there\u0027s no call to invalidate_inode_pages2_range,\nso programs that have the file range mmap\u0027d 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\u0027re\noperating on." } ], "providerMetadata": { "dateUpdated": "2024-12-19T09:36:32.859Z", "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux" }, "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" } } }, "cveMetadata": { "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "assignerShortName": "Linux", "cveId": "CVE-2024-50250", "datePublished": "2024-11-09T10:14:59.003Z", "dateReserved": "2024-10-21T19:36:19.979Z", "dateUpdated": "2024-12-19T09:36:32.859Z", "state": "PUBLISHED" }, "dataType": "CVE_RECORD", "dataVersion": "5.1", "meta": { "nvd": "{\"cve\":{\"id\":\"CVE-2024-50250\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-11-09T11:15:10.833\",\"lastModified\":\"2024-11-14T17:04:14.043\",\"vulnStatus\":\"Analyzed\",\"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\u0027s 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-\u003epos is not\\naligned to a page, because daddr/saddr do not point to the same byte in\\nthe file as iter-\u003epos. Hence we corrupt user data by copying it to the\\nwrong place.\\n\\nIf iter-\u003epos + 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\u0027re not done yet -- there\u0027s no call to invalidate_inode_pages2_range,\\nso programs that have the file range mmap\u0027d 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\u0027re\\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-\u0026gt;pos no est\u00e1 alineado con una p\u00e1gina, porque daddr/saddr no apuntan al mismo byte en el archivo que iter-\u0026gt;pos. Por lo tanto, corrompemos los datos del usuario copi\u00e1ndolos en el lugar equivocado. Si iter-\u0026gt;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.\"}],\"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:H/I:H/A:N\",\"baseScore\":7.1,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":1.8,\"impactScore\":5.2}]},\"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\":\"6.1.113\",\"versionEndExcluding\":\"6.1.116\",\"matchCriteriaId\":\"0784ED09-D629-4871-A504-544E89D6604D\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.2\",\"versionEndExcluding\":\"6.6.60\",\"matchCriteriaId\":\"75088E5E-2400-4D20-915F-7A65C55D9CCD\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.7\",\"versionEndExcluding\":\"6.11.7\",\"matchCriteriaId\":\"E96F53A4-5E87-4A70-BD9A-BC327828D57F\"},{\"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\"}]}]}],\"references\":[{\"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\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}" } }
Loading…
Loading…
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.