CVE-2026-46161

What it actually does

This flaw is a local denial-of-service condition in the Linux kernel RAID10 md driver. The RAID10 geometry setup code derives near_copies and far_copies values from a user-supplied RAID layout parameter but previously failed to reject a zero far_copies value. When the “improved” far-set RAID10 layout is selected and far_copies is zero, the kernel evaluates disks / far_copies while computing the far set size, triggering a divide-by-zero exception. Depending on kernel configuration and runtime state, this can produce a kernel oops, crash the md operation, or panic/reboot the system, resulting in loss of availability. The issue does not provide confidentiality or integrity impact by itself and requires local access with the ability to exercise RAID/md configuration paths.

Why it matters to the business

A user or process with sufficient local access to manipulate Linux software RAID configuration could crash affected systems, interrupting workloads, storage availability, and dependent services. The highest risk is to systems that use or expose Linux md/RAID management capabilities, including virtualization hosts, storage appliances, CI/build systems, or administrative environments where local users or automation can run RAID configuration commands. This vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a very low EPSS score, so broad internet-scale exploitation is unlikely; however, a successful local exploit can still cause a high-impact outage on individual systems.

How an attack unfolds

An attacker first obtains local access to an affected Linux system and identifies a path to invoke md/RAID10 configuration, typically through administrative tooling, a privileged helper, container or namespace exposure, or another mechanism that can pass RAID layout parameters to the kernel. The attacker supplies a malformed RAID10 layout that selects the improved far-set layout while setting far_copies to zero. The vulnerable setup_geo() routine extracts the near_copies and far_copies fields but does not reject zero values before using far_copies as a divisor. When the kernel computes the RAID10 far set size, the divide-by-zero exception occurs. The result is a local availability impact, ranging from failed RAID setup to kernel oops or system panic, depending on the system’s panic-on-oops behavior and surrounding kernel state.

How to fix it

Apply a Linux kernel update that includes the md/raid10 fix validating both near_copies and far_copies immediately after extraction and rejecting zero values. If vendor fixed package versions are available, upgrade to the vendor-provided fixed kernel rather than relying on upstream commit state alone. Reboot into the updated kernel and ensure old vulnerable kernels are not selected by default in the bootloader. Where immediate patching is not possible, reduce exposure by restricting local shell access, limiting sudo/root and CAP_SYS_ADMIN privileges, preventing untrusted users or containers from accessing md devices or RAID management interfaces, and disabling or avoiding md/RAID10 administration on shared systems where it is not required.

How to confirm the fix worked

Confirm the running kernel is from a vendor release that contains the md/raid10 zero far_copies validation fix. Verify with uname -r, package-manager metadata, and vendor advisories for the installed kernel stream. After patching, reboot and confirm the active kernel is the fixed version, not merely installed on disk. Review bootloader entries to ensure vulnerable fallback kernels are not used by default. If safe in a non-production test environment, validate that attempts to create or configure RAID10 with an invalid zero near_copies or far_copies layout fail cleanly with an error rather than producing a kernel oops or panic. Production validation should avoid deliberately triggering the malformed layout on live systems.

Typical attack path

1. Gain local access to an affected Linux system.
2. Obtain or abuse the ability to perform md/RAID management operations, such as creating or reshaping a RAID10 array.
3. Submit a crafted RAID10 layout value that selects the improved far-set layout with far_copies set to zero.
4. Trigger RAID10 geometry initialization in the kernel md/raid10 code path.
5. Cause the kernel to divide by zero while calculating the far set size.
6. Induce a kernel oops, panic, reboot, or disruption of storage-related operations.

How to detect it

Look for evidence of attempted RAID10 creation or reconfiguration immediately before a kernel divide-by-zero, oops, panic, reboot, or md-related failure. Useful sources include kernel logs from journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore data, auditd command execution logs, sudo logs, shell history where available, and endpoint telemetry for mdadm or other RAID-management utilities. Focus on events involving md/raid10, setup_geo(), RAID10 layout parameters, and unexpected local execution of mdadm by non-storage-administration users or automation accounts. For already-exploited systems, correlate kernel crash timestamps with process execution records for mdadm, privileged helper tools, container runtime activity, sudo usage, or writes to md-related sysfs/proc interfaces. Because exploitation may only leave crash artifacts, absence of command logs does not rule it out if audit coverage was incomplete.

• divide error: 0000
• Oops: divide error
• kernel BUG at
• RIP: setup_geo
• setup_geo
• md/raid10
• raid10:
• mdadm --create
• mdadm --grow
• mdadm --layout
• /sbin/mdadm
• /usr/sbin/mdadm
• /proc/mdstat
• /dev/md
• /sys/module/raid10
• panic_on_oops

What your security team should do

• Prioritize patching Linux systems where local users, automation, containers, or tenants can influence md/RAID configuration.
• Inventory systems using the Linux md driver and RAID10, especially storage hosts, virtualization hosts, appliances, and administrative build or test systems.
• Restrict RAID management commands and device access to trusted administrators only; review sudo rules, privileged containers, and CAP_SYS_ADMIN assignments.
• Monitor kernel logs for divide-by-zero, oops, panic, or md/raid10-related errors that occur during RAID creation or reconfiguration.
• Reboot systems after kernel update and verify the fixed kernel is actively running.
• If patching is delayed, prevent untrusted local users from running mdadm or accessing /dev/md* and related block devices.
• Treat unexpected kernel crashes during RAID10 setup or reshape as potentially malicious until reviewed.