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.
CVSS Details
- CVSS 3.1 Base Score: 5.5
- CVSS 3.1 Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Covered by Rapid7
| 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-1009-awsUpgrade linux-image-6.11.0-1011-oracleUpgrade linux-image-genericUpgrade linux-image-azure-fdeUpgrade linux-image-lowlatency-64kUpgrade linux-image-realtime-hwe-24.04Upgrade linux-image-6.11.0-1010-lowlatencyUpgrade linux-image-6.11.0-1009-azure-fdeUpgrade linux-image-generic-64kUpgrade linux-image-generic-hwe-24.04Upgrade linux-image-6.11.0-1011-oracle-64kUpgrade linux-image-lowlatencyUpgrade linux-image-raspiUpgrade linux-image-6.11.0-1009-azureUpgrade linux-image-azureUpgrade linux-image-6.11.0-1015-oemUpgrade linux-image-6.11.0-1008-raspiUpgrade linux-image-oracle-64kUpgrade linux-image-virtual-hwe-24.04Upgrade linux-image-oem-24.04Upgrade linux-image-gcpUpgrade linux-image-oem-24.04bUpgrade linux-image-6.11.0-1005-realtimeUpgrade linux-image-generic-64k-hwe-24.04Upgrade linux-image-6.11.0-18-generic-64kUpgrade linux-image-realtimeUpgrade linux-image-oracleUpgrade linux-image-oem-24.04aUpgrade linux-image-6.11.0-1010-lowlatency-64kUpgrade linux-image-6.11.0-18-genericUpgrade linux-image-awsUpgrade linux-image-virtualUpgrade linux-image-6.11.0-1009-gcp | Feb 20, 2025 | Oct 21, 2024 |
Prioritise with Active Threat Intelligence
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