CVE-2026-98635: scsi: block: Fix zones_cond out-of-bounds write on zone report
In the Linux kernel, the following vulnerability has been resolved:
scsi: block: Fix zonescond out-of-bounds write on zone report
blkrevalidatediskzones() sizes the zonescond array from the disk capacity and zone size, but the index used by blkrevalidatezonecond() comes from the device-driven reportzones() walk and is never checked against the array size. A device reporting more zones than fit the array makes blkzonesetcond() write out of bounds.
One way to reach this is a zone count exceeding 32 bits: both blkrevalidatezoneargs.nrzones and struct zoneddiskinfo.nrzones are unsigned int, so a disk advertising more than UINTMAX zones (e.g. 2^32 + 1024 zones of one 512-byte logical block) gets its zone count truncated to a small value, undersizing the array while the report walk keeps counting upward.
Check the index against the array size before storing the zone condition, and refuse to revalidate when the zone count does not fit 32 bits.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In blk_revalidate_disk_zones(), check the report_zones() index against the zones_cond array size before storing the zone condition, and refuse revalidation when the reported zone count does not fit in 32 bits.
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Systems using the Linux kernel with a zoned disk are exposed if the device can report more zones than the kernel's zone-condition array was sized to hold. The described trigger involves a disk advertising more than UINT_MAX zones, causing the stored zone count to truncate while zone reporting continues.
What does an attacker or malicious device need to do to trigger it?
The device must provide a zone report containing more zones than fit the array allocated from the disk capacity and zone size. In the described case, advertising more than 2^32 zones causes the zone count to be truncated and allows the report walk to reach an out-of-bounds array index.
How can this be mitigated if the fix cannot be deployed immediately?
Avoid attaching or revalidating zoned storage devices that advertise a zone count exceeding 32 bits. Do not trust zone reports from devices that can supply an inconsistent or excessively large zone count.
How does the resolved code prevent the out-of-bounds write?
The fix checks the zone-report index against the allocated array size before storing a zone condition. It also refuses zone revalidation when the reported zone count cannot fit in 32 bits.