CVE-2025-38073 (GCVE-0-2025-38073)
Vulnerability from cvelistv5
Published
2025-06-18 09:33
Modified
2025-06-18 09:33
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: block: fix race between set_blocksize and read paths With the new large sector size support, it's now the case that set_blocksize can change i_blksize and the folio order in a manner that conflicts with a concurrent reader and causes a kernel crash. Specifically, let's say that udev-worker calls libblkid to detect the labels on a block device. The read call can create an order-0 folio to read the first 4096 bytes from the disk. But then udev is preempted. Next, someone tries to mount an 8k-sectorsize filesystem from the same block device. The filesystem calls set_blksize, which sets i_blksize to 8192 and the minimum folio order to 1. Now udev resumes, still holding the order-0 folio it allocated. It then tries to schedule a read bio and do_mpage_readahead tries to create bufferheads for the folio. Unfortunately, blocks_per_folio == 0 because the page size is 4096 but the blocksize is 8192 so no bufferheads are attached and the bh walk never sets bdev. We then submit the bio with a NULL block device and crash. Therefore, truncate the page cache after flushing but before updating i_blksize. However, that's not enough -- we also need to lock out file IO and page faults during the update. Take both the i_rwsem and the invalidate_lock in exclusive mode for invalidations, and in shared mode for read/write operations. I don't know if this is the correct fix, but xfs/259 found it.
References
Impacted products
Vendor Product Version
Linux Linux Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "block/bdev.c",
            "block/blk-zoned.c",
            "block/fops.c",
            "block/ioctl.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "64f505b08e0cfd8163491c8c082d4f47a88e51d4",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "8c5cf440a378801d313eb58be996fdc81a8878a4",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "c0e473a0d226479e8e925d5ba93f751d8df628e9",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "block/bdev.c",
            "block/blk-zoned.c",
            "block/fops.c",
            "block/ioctl.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.31",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.14.*",
              "status": "unaffected",
              "version": "6.14.9",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.15",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.31",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.14.9",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.15",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix race between set_blocksize and read paths\n\nWith the new large sector size support, it\u0027s now the case that\nset_blocksize can change i_blksize and the folio order in a manner that\nconflicts with a concurrent reader and causes a kernel crash.\n\nSpecifically, let\u0027s say that udev-worker calls libblkid to detect the\nlabels on a block device.  The read call can create an order-0 folio to\nread the first 4096 bytes from the disk.  But then udev is preempted.\n\nNext, someone tries to mount an 8k-sectorsize filesystem from the same\nblock device.  The filesystem calls set_blksize, which sets i_blksize to\n8192 and the minimum folio order to 1.\n\nNow udev resumes, still holding the order-0 folio it allocated.  It then\ntries to schedule a read bio and do_mpage_readahead tries to create\nbufferheads for the folio.  Unfortunately, blocks_per_folio == 0 because\nthe page size is 4096 but the blocksize is 8192 so no bufferheads are\nattached and the bh walk never sets bdev.  We then submit the bio with a\nNULL block device and crash.\n\nTherefore, truncate the page cache after flushing but before updating\ni_blksize.  However, that\u0027s not enough -- we also need to lock out file\nIO and page faults during the update.  Take both the i_rwsem and the\ninvalidate_lock in exclusive mode for invalidations, and in shared mode\nfor read/write operations.\n\nI don\u0027t know if this is the correct fix, but xfs/259 found it."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-06-18T09:33:49.393Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/64f505b08e0cfd8163491c8c082d4f47a88e51d4"
        },
        {
          "url": "https://git.kernel.org/stable/c/8c5cf440a378801d313eb58be996fdc81a8878a4"
        },
        {
          "url": "https://git.kernel.org/stable/c/c0e473a0d226479e8e925d5ba93f751d8df628e9"
        }
      ],
      "title": "block: fix race between set_blocksize and read paths",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-38073",
    "datePublished": "2025-06-18T09:33:49.393Z",
    "dateReserved": "2025-04-16T04:51:23.980Z",
    "dateUpdated": "2025-06-18T09:33:49.393Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-38073\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-06-18T10:15:40.720\",\"lastModified\":\"2025-06-18T13:46:52.973\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nblock: fix race between set_blocksize and read paths\\n\\nWith the new large sector size support, it\u0027s now the case that\\nset_blocksize can change i_blksize and the folio order in a manner that\\nconflicts with a concurrent reader and causes a kernel crash.\\n\\nSpecifically, let\u0027s say that udev-worker calls libblkid to detect the\\nlabels on a block device.  The read call can create an order-0 folio to\\nread the first 4096 bytes from the disk.  But then udev is preempted.\\n\\nNext, someone tries to mount an 8k-sectorsize filesystem from the same\\nblock device.  The filesystem calls set_blksize, which sets i_blksize to\\n8192 and the minimum folio order to 1.\\n\\nNow udev resumes, still holding the order-0 folio it allocated.  It then\\ntries to schedule a read bio and do_mpage_readahead tries to create\\nbufferheads for the folio.  Unfortunately, blocks_per_folio == 0 because\\nthe page size is 4096 but the blocksize is 8192 so no bufferheads are\\nattached and the bh walk never sets bdev.  We then submit the bio with a\\nNULL block device and crash.\\n\\nTherefore, truncate the page cache after flushing but before updating\\ni_blksize.  However, that\u0027s not enough -- we also need to lock out file\\nIO and page faults during the update.  Take both the i_rwsem and the\\ninvalidate_lock in exclusive mode for invalidations, and in shared mode\\nfor read/write operations.\\n\\nI don\u0027t know if this is the correct fix, but xfs/259 found it.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: corregir ejecuci\u00f3n entre set_blocksize y las rutas de lectura Con el nuevo soporte para tama\u00f1os de sector grandes, ahora es posible que set_blocksize cambie i_blksize y el orden de los folios de forma que entre en conflicto con un lector concurrente y provoque un fallo del kernel. Espec\u00edficamente, supongamos que udev-worker llama a libblkid para detectar las etiquetas en un dispositivo de bloque. La llamada de lectura puede crear un folio de orden 0 para leer los primeros 4096 bytes del disco. Pero entonces udev es interrumpido. A continuaci\u00f3n, alguien intenta montar un sistema de archivos de tama\u00f1o de sector de 8k desde el mismo dispositivo de bloque. El sistema de archivos llama a set_blksize, que establece i_blksize en 8192 y el orden m\u00ednimo de folio en 1. Ahora udev se reanuda, a\u00fan manteniendo el folio de orden 0 que asign\u00f3. Entonces intenta programar una biograf\u00eda de lectura y do_mpage_readahead intenta crear bufferheads para el folio. Desafortunadamente, bloques_por_folio == 0 porque el tama\u00f1o de p\u00e1gina es 4096, pero el tama\u00f1o de bloque es 8192, por lo que no se conectan bufferheads y el bh walk nunca establece bdev. Luego, enviamos la biograf\u00eda con un dispositivo de bloque nulo y se produce un fallo. Por lo tanto, truncamos la cach\u00e9 de p\u00e1ginas despu\u00e9s del vaciado, pero antes de actualizar i_blksize. Sin embargo, esto no es suficiente; tambi\u00e9n necesitamos bloquear la E/S de archivos y los fallos de p\u00e1gina durante la actualizaci\u00f3n. Use tanto i_rwsem como invalidate_lock en modo exclusivo para invalidaciones y en modo compartido para operaciones de lectura/escritura. No s\u00e9 si esta sea la soluci\u00f3n correcta, pero xfs/259 la encontr\u00f3.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/64f505b08e0cfd8163491c8c082d4f47a88e51d4\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/8c5cf440a378801d313eb58be996fdc81a8878a4\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/c0e473a0d226479e8e925d5ba93f751d8df628e9\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
  }
}


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.