CVE-2026-97441: ata: ahci: fail probe if BAR too small for claimed ports
In the Linux kernel, the following vulnerability has been resolved:
ata: ahci: fail probe if BAR too small for claimed ports
When an AHCI controller is disabled in BIOS, its HOSTCAP register may contain a bogus value, e.g. 0xFFFFFFFF.
Since CAP.NP (Number of Ports) is a zeroes based 5-bit register field, a value of 0x1f means 32 ports. If CAP.NP claims more ports than can physically fit within the mapped BAR region, accessing port registers beyond the BAR boundary causes a kernel panic.
Add validation in ahciinitone() to check that the BAR size is sufficient for the number of ports claimed in CAP.NP. The check calculates the required MMIO size as:
requiredsize = 0x100 (global registers) + maxports 0x80
If requiredsize exceeds the actual BAR size, the probe fails with -ENODEV, preventing the panic and providing a clear error message.
[cassel: commit log]
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In ahci_init_one(), validate that the actual BAR size is sufficient for the number of ports claimed by CAP.NP, calculating required_size as 0x100 (global registers) + max_ports * 0x80; if required_size exceeds the BAR size, fail the probe with -ENODEV.
Event History
Frequently Asked Questions
Which systems are exposed to the kernel panic?
Systems with an AHCI controller that reports more ports in its HOST_CAP CAP.NP field than fit in the controller's mapped BAR region are exposed. The described example is a controller disabled in BIOS whose HOST_CAP value is bogus, such as 0xFFFFFFFF.
Does exploitation require an attacker to send requests to the storage controller?
The panic occurs when the AHCI driver probes the controller and accesses port registers beyond the mapped BAR boundary. The provided information identifies malformed controller capability data and an undersized BAR as the trigger; it does not describe a remote or unprivileged attacker-controlled input.
What happens after the fix when the controller claims too many ports?
The AHCI probe calculates the MMIO space required for the claimed ports and compares it with the actual BAR size. If the required size exceeds the BAR size, probing fails with -ENODEV instead of accessing registers beyond the BAR boundary and panicking.
How can administrators identify the affected condition before a panic?
Check whether an AHCI controller's claimed port count requires more MMIO space than its mapped BAR: 0x100 bytes for global registers plus 0x80 bytes per claimed port. A mismatch means the controller should not be probed; with the fix, the driver emits a clear error and fails the probe.