cve-2024-50250
Vulnerability from cvelistv5
Published
2024-11-09 10:14
Modified
2024-12-19 09:36
Severity ?
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
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/50793801fc7f6d08def48754fb0f0706b0cfc394Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/8e9c0f500b42216ef930f5c0d1703989a451913dPatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/9bc18bb476e50e32e5d08f2734d63d63e0fa528cPatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/bdbc96c23197d773a7d1bf03e4f11de593b0ff28Patch
Impacted products
Vendor Product Version
Linux Linux Version: 1bec6782a25c9b92c203ea7a1b3e3dc6a468cbc4
Version: d984648e428bf88cbd94ebe346c73632cb92fffb
Version: d984648e428bf88cbd94ebe346c73632cb92fffb
Version: d984648e428bf88cbd94ebe346c73632cb92fffb
 Create a notification for this product.
   Linux Linux Version: 6.2
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "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",
  "vulnerability-lookup: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\"]}]}}"
  }
}


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.