CVE-2024-42224

What it actually does

The mv88e6xxx_default_mdio_bus() function uses list_first_entry() to check the chip->mdios list instead of list_first_entry_or_null(), so an empty list produces an invalid pointer rather than NULL; subsequent dereference or list operations can corrupt kernel memory or cause crashes.

Why it matters to the business

Local users on systems using Marvell DSA switches can trigger kernel instability or local privilege escalation, leading to denial of service or full host compromise in multi-tenant or containerized Linux environments.

How an attack unfolds

An attacker with local access loads or configures a mv88e6xxx DSA device whose mdios list remains empty, invokes the defective function, obtains an invalid list entry pointer, and uses the resulting memory corruption to escalate privileges or crash the kernel.

How to fix it

Update the Linux kernel to the commit 47d28dde172696031c880c5778633cdca30394ee or later stable releases that replace list_first_entry() with list_first_entry_or_null() in the mv88e6xxx driver.

How to confirm the fix worked

Verify the running kernel contains commit 47d28dde172696031c880c5778633cdca30394ee by inspecting /proc/version or kernel source; confirm the function mv88e6xxx_default_mdio_bus() now uses list_first_entry_or_null().

Typical attack path

1. Obtain local shell on affected Linux host
2. Trigger DSA device initialization or MDIO bus enumeration with an empty mdios list
3. Call mv88e6xxx_default_mdio_bus() which mis-handles the empty list
4. Exploit resulting invalid pointer dereference for memory corruption
5. Escalate to root or cause kernel panic

How to detect it

Search kernel logs and dmesg for oops or warnings originating from mv88e6xxx_default_mdio_bus or list handling in the DSA driver; examine crash dumps for invalid pointer dereferences involving chip->mdios.

• mv88e6xxx_default_mdio_bus
• list_first_entry
• chip->mdios

What your security team should do

• Prioritize kernel upgrade on all systems exposing mv88e6xxx DSA hardware
• Restrict local user access until patched
• Monitor kernel logs for mv88e6xxx oops or list corruption warnings
• Apply the fix across all distribution kernels that incorporate the upstream change