In the Linux kernel, the following vulnerability has been resolved:
f2fs: check discard support for conventional zones
As the helper function f2fs_bdev_support_discard() shows, f2fs checks if the target block devices support discard by calling bdev_max_discard_sectors() and bdev_is_zoned(). This check works well for most cases, but it does not work for conventional zones on zoned block devices. F2fs assumes that zoned block devices support discard, and calls __submit_discard_cmd(). When __submit_discard_cmd() is called for sequential write required zones, it works fine since __submit_discard_cmd() issues zone reset commands instead of discard commands. However, when __submit_discard_cmd() is called for conventional zones, __blkdev_issue_discard() is called even when the devices do not support discard.
The inappropriate __blkdev_issue_discard() call was not a problem before the commit 30f1e7241422 ("block: move discard checks into the ioctl handler") because __blkdev_issue_discard() checked if the target devices support discard or not. If not, it returned EOPNOTSUPP. After the commit, __blkdev_issue_discard() no longer checks it. It always returns zero and sets NULL to the given bio pointer. This NULL pointer triggers f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the commands below at the umount step, where /dev/nullb0 is a zoned null_blk with 5GB total size, 128MB zone size and 10 conventional zones.
$ mkfs.f2fs -f -m /dev/nullb0 $ mount /dev/nullb0 /mnt $ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done $ umount /mnt
To fix the BUG, avoid the inappropriate __blkdev_issue_discard() call. When discard is requested for conventional zones, check if the device supports discard or not. If not, return EOPNOTSUPP.
| Product | Vendor Advisory | Solution File | Added | Published |
|---|---|---|---|---|
| Debian | — | Upgrade linux | Jul 27, 2026 | Jul 27, 2026 |
| Redhat_linux | — | No solution exists | Jul 9, 2025 | Oct 21, 2024 |
| Ubuntu | — | Upgrade linux-image-6.11.0-1011-oracle-64kUpgrade linux-image-lowlatencyUpgrade linux-image-raspiUpgrade linux-image-generic-hwe-24.04Upgrade linux-image-6.11.0-1009-azure-fdeUpgrade linux-image-lowlatency-64kUpgrade linux-image-6.11.0-1009-awsUpgrade linux-image-azureUpgrade linux-image-6.11.0-1010-lowlatencyUpgrade linux-image-6.11.0-1015-oemUpgrade linux-image-genericUpgrade linux-image-6.11.0-1008-raspiUpgrade linux-image-6.11.0-1009-azureUpgrade linux-image-azure-fdeUpgrade linux-image-realtime-hwe-24.04Upgrade linux-image-generic-64kUpgrade linux-image-6.11.0-1011-oracleUpgrade linux-image-realtimeUpgrade linux-image-oracle-64kUpgrade linux-image-oem-24.04bUpgrade linux-image-6.11.0-18-generic-64kUpgrade linux-image-6.11.0-1005-realtimeUpgrade linux-image-6.11.0-1009-gcpUpgrade linux-image-gcpUpgrade linux-image-virtual-hwe-24.04Upgrade linux-image-oem-24.04aUpgrade linux-image-6.11.0-1010-lowlatency-64kUpgrade linux-image-6.11.0-18-genericUpgrade linux-image-virtualUpgrade linux-image-awsUpgrade linux-image-oem-24.04Upgrade linux-image-oracleUpgrade linux-image-generic-64k-hwe-24.04 | Feb 20, 2025 | Oct 21, 2024 |
With curated Threat Intelligence, you can see which vulnerabilities truly put you at risk, prioritize what matters most, and act before attackers do.
Explore Intelligence Hub