CVE-2026-46161

Technical summary

The setup_geo() function in md/raid10.c processes layout parameters containing near_copies and far_copies values without validating them for zero. When far_copies=0 is supplied with the improved far set layout, the calculation 'geo->far_set_size = disks / fc' executes an integer division by zero, causing a kernel panic. The vulnerability stems from insufficient input validation on user-supplied layout configuration data passed through the RAID subsystem interface.

Business impact

Systems relying on RAID10 configurations for storage availability face denial-of-service risk if an unprivileged user with local shell access can reconfigure RAID geometry. The impact is constrained to availability (system crash and reboot required) with no data exfiltration or integrity compromise. For organizations running kernel versions prior to the fix, this represents a low but real uptime risk, particularly in multi-tenant or untrusted-user environments.

Affected systems

All versions of the Linux kernel running the RAID10 subsystem are potentially affected. The vulnerability requires local access and typically affects systems where non-root users can issue ioctl calls to reconfigure RAID devices. Server deployments, NAS appliances, and systems with shared shell access carry higher risk. Container environments may isolate exposure depending on device access controls.

Exploitability

Exploitation requires local system access and the ability to issue RAID configuration commands—typically restricted to root or the disk group on standard systems. However, if a system permits unprivileged users to modify RAID settings (through misconfigured sudo rules, for example), or if local privilege escalation exists elsewhere, the attack surface widens. No network exposure or special tools are necessary once local access is obtained; standard mdadm or ioctl-based tools suffice.

Remediation

Apply the kernel patch that adds validation of near_copies and far_copies immediately after extraction in setup_geo(), rejecting configurations where either value is zero. Verify against your Linux distribution's security advisories and kernel release notes for the specific patched version affecting your deployment. Until patched, restrict RAID configuration permissions strictly to root and trusted administrators.

Patch guidance

Check your distributor's kernel advisories (Red Hat, Canonical, SUSE, etc.) for the patched kernel version incorporating the fix to setup_geo(). Most distributions will backport the patch to stable kernel branches. Update kernel packages through standard package management; a system reboot is required for the new kernel to take effect. Verify the patch application by confirming the setup_geo() function now validates far_copies != 0 before division.

Detection guidance

Monitor kernel logs (dmesg, journalctl) for divide-by-zero exceptions or kernel panics originating from the md/raid10 code path. Audit RAID configuration commands and ioctl calls via auditd, focusing on mdadm invocations with suspicious layout parameters containing zero values. Alert on unexpected RAID subsystem errors or system reboots correlating with RAID reconfigurations. In compliance-heavy environments, periodically validate that no RAID configurations with zero far_copies values exist in active deployments.

Why prioritize this

Although the CVSS score is MEDIUM (5.5), this is a low-exploitation-probability vulnerability due to strict privilege requirements. Prioritize patching for systems where non-root RAID administration is permitted or where privilege escalation vulnerabilities exist. Standard server deployments with proper access controls can schedule updates in routine maintenance windows rather than emergency cycles. High-availability storage clusters dependent on RAID10 should coordinate updates with change control processes to minimize downtime.

Risk score, explained

The CVSS 3.1 score of 5.5 (MEDIUM) reflects high attack complexity due to local-only access requirement and elevated privileges needed to trigger the crash. The vulnerability scores purely on availability impact (denial of service via kernel panic), with no confidentiality or integrity dimension. The score does not account for the relatively low real-world exploitability in properly configured multi-user systems, which may justify lower practical risk for many deployments.

Frequently asked questions