CVE-2024-42138

What it actually does

Double free vulnerability in mlxsw_linecard_types_init() where memory is deallocated on invalid INI file but the pointer is not reset to NULL, allowing a subsequent call to mlxsw_linecard_types_fini() to free the same memory again.

Why it matters to the business

Kernel memory corruption can cause system instability, crashes, or potential local privilege escalation on affected Linux systems using mlxsw linecard functionality, though exploitation remains unlikely given low EPSS and no known campaigns.

How an attack unfolds

An attacker with local access supplies an invalid INI file to trigger the initial deallocation without pointer reset in mlxsw_linecard_types_init(), then induces a later error path in mlxsw_linecards_init() that calls the fini function for a second free, leading to memory corruption that may be leveraged for code execution.

How to fix it

Update the Linux kernel to the fixed commit ab557f5cd993a3201b09593633d04b891263d5c0 or later stable version containing the pointer reset to NULL after deallocation.

How to confirm the fix worked

Confirm kernel source includes the pointer reset after mlxsw_linecard_types_init() deallocation on invalid INI; verify module loads without double-free paths via static analysis or runtime testing with invalid INI inputs.

Typical attack path

1. Obtain local access or ability to influence mlxsw linecard initialization
2. Provide malformed INI file to trigger mlxsw_linecard_types_init() error path
3. Force subsequent error handling that invokes mlxsw_linecard_types_fini()
4. Exploit resulting double free for memory corruption or control-flow hijack

How to detect it

Review kernel logs and dmesg for double-free warnings or slab corruption messages during mlxsw linecard initialization; inspect for unexpected crashes or panics involving linecard types functions after invalid configuration attempts.

What your security team should do

• Prioritize kernel upgrade to version containing commit ab557f5cd993a3201b09593633d04b891263d5c0 across all affected systems
• Monitor for any local privilege escalation attempts targeting mlxsw modules
• Apply defense-in-depth such as kernel hardening features and restrict unprivileged local access where possible