ghsa-96w4-h9hj-8c4v
Vulnerability from github
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.
{
"affected": [],
"aliases": [
"CVE-2025-38073"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T10:15:40Z",
"severity": null
},
"details": "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.",
"id": "GHSA-96w4-h9hj-8c4v",
"modified": "2025-06-18T12:30:33Z",
"published": "2025-06-18T12:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38073"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/64f505b08e0cfd8163491c8c082d4f47a88e51d4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c5cf440a378801d313eb58be996fdc81a8878a4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c0e473a0d226479e8e925d5ba93f751d8df628e9"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.