CVE-2026-98634
NoneCVSS
—
EPSS
0.2%
Published
Oct 18, 2026
CISA due date
—
Cloudanix analysis
A rare flaw in how Linux handles certain advanced storage devices could let a specially crafted disk cause memory problems, but the issue is unlikely to affect normal systems and is already fixed in recent kernels.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Theoretical
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Improper Input Validation
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Integer truncation in sd_zbc_read_zones stores a 64-bit zone count into an unsigned int, and signed integer overflow occurs in sd_zbc_report_zones when counting zones past INT_MAX, allowing a device to report more zones than the kernel allocates resources for.
Why it matters to the business
Affects Linux systems using zoned SCSI devices; published only five days ago with negligible exploit probability and no known threat actor use, resulting in minimal operational disruption risk for the vast majority of deployments.
How an attack unfolds
An attacker supplies a malicious or emulated zoned SCSI disk that advertises more than INT_MAX zones; during device scan the kernel silently truncates the count, later uses the wrong size for per-zone structures, and triggers inconsistent bookkeeping or crashes when report-zones commands are processed.
How to fix it
Apply the upstream kernel commit that adds an explicit rejection of devices reporting more than INT_MAX zones at scan time; rebuild and deploy the updated kernel across all affected Linux distributions.
How to confirm the fix worked
Confirm the patch is present by checking the sd_zbc.c source for the INT_MAX zone-count guard; test with a synthetic device or qemu-scsi target advertising an oversized zone count and verify the kernel logs a rejection rather than accepting the device.
Typical attack path
- Present a zoned block device that reports >INT_MAX zones via its SCSI mode pages or zone descriptors
- Trigger kernel device enumeration and sd_zbc_read_zones during probe or rescan
- Cause truncation of nr_zones and subsequent integer overflow in zone_idx during sd_zbc_report_zones
- Induce resource misallocation or kernel inconsistency when the driver operates on the truncated zone map
How to detect it
Review kernel logs (dmesg, journalctl) around SCSI device probe events for messages indicating zone count truncation, overflow warnings, or unusually large zone reports; correlate with sd_mod or sd_zbc module activity.
What your security team should do
- Prioritize kernel updates on systems that expose zoned SCSI storage within the next maintenance window
- Monitor EPSS and KEV status for any future increase in exploit activity
- Add a kernel configuration or udev rule to ignore unknown or suspiciously large zoned devices if immediate patching is delayed
The record
In the Linux kernel, the following vulnerability has been resolved: scsi: sd_zbc: Reject disks with too many zones sd_zbc_read_zones() computes the number of zones with 64-bit arithmetic and stores the result in the unsigned int nr_zones field of struct zoned_disk_info, silently truncating counts that exceed 32 bits. The truncated count is later used to size per-zone resources, while the device may still report more zones than fit. Moreover, sd_zbc_report_zones() counts the reported zones with a signed int zone_idx, which overflows past INT_MAX. Reject devices reporting more than INT_MAX zones at scan time; such a device is not realistic for any medium that exists today, and accepting it produces inconsistent zone bookkeeping.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|