cve-2023-52786
Vulnerability from cvelistv5
Published
2024-05-21 15:31
Modified
2024-12-19 08:25
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: ext4: fix racy may inline data check in dio write syzbot reports that the following warning from ext4_iomap_begin() triggers as of the commit referenced below: if (WARN_ON_ONCE(ext4_has_inline_data(inode))) return -ERANGE; This occurs during a dio write, which is never expected to encounter an inode with inline data. To enforce this behavior, ext4_dio_write_iter() checks the current inline state of the inode and clears the MAY_INLINE_DATA state flag to either fall back to buffered writes, or enforce that any other writers in progress on the inode are not allowed to create inline data. The problem is that the check for existing inline data and the state flag can span a lock cycle. For example, if the ilock is originally locked shared and subsequently upgraded to exclusive, another writer may have reacquired the lock and created inline data before the dio write task acquires the lock and proceeds. The commit referenced below loosens the lock requirements to allow some forms of unaligned dio writes to occur under shared lock, but AFAICT the inline data check was technically already racy for any dio write that would have involved a lock cycle. Regardless, lift clearing of the state bit to the same lock critical section that checks for preexisting inline data on the inode to close the race.
Impacted products
Vendor Product Version
Linux Linux Version: 6.5
Show details on NVD website


{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2023-52786",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-05-22T19:36:50.287766Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-06-04T17:23:16.597Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T23:11:35.517Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/e3b83d87c93eb6fc96a80b5e8527f7dc9f5a11bc"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/7343c23ebcadbedc23a7063d1e24d976eccb0d0d"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/ce56d21355cd6f6937aca32f1f44ca749d1e4808"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/ext4/file.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "e3b83d87c93eb6fc96a80b5e8527f7dc9f5a11bc",
              "status": "affected",
              "version": "310ee0902b8d9d0a13a5a13e94688a5863fa29c2",
              "versionType": "git"
            },
            {
              "lessThan": "7343c23ebcadbedc23a7063d1e24d976eccb0d0d",
              "status": "affected",
              "version": "310ee0902b8d9d0a13a5a13e94688a5863fa29c2",
              "versionType": "git"
            },
            {
              "lessThan": "ce56d21355cd6f6937aca32f1f44ca749d1e4808",
              "status": "affected",
              "version": "310ee0902b8d9d0a13a5a13e94688a5863fa29c2",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "fs/ext4/file.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.5"
            },
            {
              "lessThan": "6.5",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.5.*",
              "status": "unaffected",
              "version": "6.5.13",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.3",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.7",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix racy may inline data check in dio write\n\nsyzbot reports that the following warning from ext4_iomap_begin()\ntriggers as of the commit referenced below:\n\n        if (WARN_ON_ONCE(ext4_has_inline_data(inode)))\n                return -ERANGE;\n\nThis occurs during a dio write, which is never expected to encounter\nan inode with inline data. To enforce this behavior,\next4_dio_write_iter() checks the current inline state of the inode\nand clears the MAY_INLINE_DATA state flag to either fall back to\nbuffered writes, or enforce that any other writers in progress on\nthe inode are not allowed to create inline data.\n\nThe problem is that the check for existing inline data and the state\nflag can span a lock cycle. For example, if the ilock is originally\nlocked shared and subsequently upgraded to exclusive, another writer\nmay have reacquired the lock and created inline data before the dio\nwrite task acquires the lock and proceeds.\n\nThe commit referenced below loosens the lock requirements to allow\nsome forms of unaligned dio writes to occur under shared lock, but\nAFAICT the inline data check was technically already racy for any\ndio write that would have involved a lock cycle. Regardless, lift\nclearing of the state bit to the same lock critical section that\nchecks for preexisting inline data on the inode to close the race."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2024-12-19T08:25:56.852Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/e3b83d87c93eb6fc96a80b5e8527f7dc9f5a11bc"
        },
        {
          "url": "https://git.kernel.org/stable/c/7343c23ebcadbedc23a7063d1e24d976eccb0d0d"
        },
        {
          "url": "https://git.kernel.org/stable/c/ce56d21355cd6f6937aca32f1f44ca749d1e4808"
        }
      ],
      "title": "ext4: fix racy may inline data check in dio write",
      "x_generator": {
        "engine": "bippy-5f407fcff5a0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2023-52786",
    "datePublished": "2024-05-21T15:31:03.694Z",
    "dateReserved": "2024-05-21T15:19:24.241Z",
    "dateUpdated": "2024-12-19T08:25:56.852Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2023-52786\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-05-21T16:15:17.413\",\"lastModified\":\"2024-11-21T08:40:35.167\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\next4: fix racy may inline data check in dio write\\n\\nsyzbot reports that the following warning from ext4_iomap_begin()\\ntriggers as of the commit referenced below:\\n\\n        if (WARN_ON_ONCE(ext4_has_inline_data(inode)))\\n                return -ERANGE;\\n\\nThis occurs during a dio write, which is never expected to encounter\\nan inode with inline data. To enforce this behavior,\\next4_dio_write_iter() checks the current inline state of the inode\\nand clears the MAY_INLINE_DATA state flag to either fall back to\\nbuffered writes, or enforce that any other writers in progress on\\nthe inode are not allowed to create inline data.\\n\\nThe problem is that the check for existing inline data and the state\\nflag can span a lock cycle. For example, if the ilock is originally\\nlocked shared and subsequently upgraded to exclusive, another writer\\nmay have reacquired the lock and created inline data before the dio\\nwrite task acquires the lock and proceeds.\\n\\nThe commit referenced below loosens the lock requirements to allow\\nsome forms of unaligned dio writes to occur under shared lock, but\\nAFAICT the inline data check was technically already racy for any\\ndio write that would have involved a lock cycle. Regardless, lift\\nclearing of the state bit to the same lock critical section that\\nchecks for preexisting inline data on the inode to close the race.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: ext4: corrige la verificaci\u00f3n de datos en l\u00ednea de racy may en dio write syzbot informa que la siguiente advertencia de ext4_iomap_begin() se activa a partir de la confirmaci\u00f3n a la que se hace referencia a continuaci\u00f3n: if (WARN_ON_ONCE(ext4_has_inline_data(inode)) ) devolver -ERANGE; Esto ocurre durante una escritura dio, que nunca se espera que encuentre un inodo con datos en l\u00ednea. Para imponer este comportamiento, ext4_dio_write_iter() verifica el estado en l\u00ednea actual del inodo y borra el indicador de estado MAY_INLINE_DATA para volver a las escrituras almacenadas en el b\u00fafer o imponer que otros escritores en progreso en el inodo no puedan crear datos en l\u00ednea. El problema es que la verificaci\u00f3n de datos en l\u00ednea existentes y la bandera de estado puede abarcar un ciclo de bloqueo. Por ejemplo, si el ilock originalmente estaba bloqueado como compartido y posteriormente actualizado a exclusivo, es posible que otro escritor haya vuelto a adquirir el bloqueo y haya creado datos en l\u00ednea antes de que la tarea de escritura dio adquiera el bloqueo y contin\u00fae. El compromiso al que se hace referencia a continuaci\u00f3n afloja los requisitos de bloqueo para permitir que se produzcan algunas formas de escrituras de dio no alineadas bajo un bloqueo compartido, pero AFAICT, la verificaci\u00f3n de datos en l\u00ednea t\u00e9cnicamente ya era picante para cualquier escritura de dio que hubiera involucrado un ciclo de bloqueo. De todos modos, limpie el bit de estado en la misma secci\u00f3n cr\u00edtica de bloqueo que verifica si hay datos en l\u00ednea preexistentes en el inodo para cerrar la ejecuci\u00f3n.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/7343c23ebcadbedc23a7063d1e24d976eccb0d0d\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/ce56d21355cd6f6937aca32f1f44ca749d1e4808\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/e3b83d87c93eb6fc96a80b5e8527f7dc9f5a11bc\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/7343c23ebcadbedc23a7063d1e24d976eccb0d0d\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/ce56d21355cd6f6937aca32f1f44ca749d1e4808\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/e3b83d87c93eb6fc96a80b5e8527f7dc9f5a11bc\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

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.