CVE-2025-38111

What it actually does

Lack of validation on mdio address parameter in mdiobus ioctl allows values exceeding PHY_MAX_ADDR, enabling out-of-bounds read/write on the stats array during read/write operations.

Why it matters to the business

Local attackers can trigger kernel memory corruption on affected Linux systems, risking system instability, information disclosure, or privilege escalation on network-enabled devices; low EPSS indicates limited observed exploitation but kernel exposure remains widespread.

How an attack unfolds

An attacker with local access invokes publicly available mdio-tools or equivalent ioctl calls against network interfaces, supplying an mdio address greater than 31 to bypass normal failure paths and hit the unprotected stats array for out-of-bounds access; related Linux kernel privilege-escalation campaigns demonstrate similar local attack patterns.

How to fix it

Update the Linux kernel to the fixed commit 19c5875e26c4ed5686d82a7d8f7051385461b9eb or later stable releases containing the address verification check before mdiobus read/write; rebuild and deploy custom kernels or apply distribution patches as available.

How to confirm the fix worked

Confirm kernel source contains the address verification guard before mdiobus operations; test ioctl calls with addresses above 31 to ensure they are rejected without accessing stats array; monitor for absence of related out-of-bounds crashes after update.

Typical attack path

1. Obtain local shell or execution context on target Linux system
2. Identify network interface exposing mdiobus via mdio-tools or custom ioctl
3. Issue read or write ioctl with mdio address exceeding PHY_MAX_ADDR
4. Trigger out-of-bounds access on mdiobus stats array
5. Observe resulting memory corruption, crash, or data leakage

How to detect it

Review kernel logs for mdiobus-related faults or out-of-bounds warnings; inspect audit logs for unusual ioctl activity on network devices; correlate with process execution of mdio-tools or similar utilities.

What your security team should do

• Prioritize kernel upgrade on all exposed Linux hosts within standard patching windows given local attack vector
• Restrict unprivileged access to mdio-tools and raw ioctl interfaces where possible
• Include kernel memory corruption indicators in existing anomaly detection rules
• Track EPSS trend and related kernel privilege-escalation activity for potential increase in targeting