In the Linux kernel, the following vulnerability has been resolved: block: fix race between setblocksize and read paths With the new large sector size support, it's now the case that setblocksize can change iblksize 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 setblksize, which sets iblksize 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 dompagereadahead tries to create bufferheads for the folio. Unfortunately, blocksperfolio == 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 iblksize. However, that's not enough -- we also need to lock out file IO and page faults during the update. Take both the irwsem and the invalidatelock 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.