CVE-2024-50166

What it actually does

Reference leaks occur because mac_probe() calls of_find_device_by_node(), fman_bind() and fman_port_bind() that take references to of_dev->dev but the error paths and mac_remove() do not release all of them.

Why it matters to the business

Kernel memory resources for FMAN-related devices are not freed, which over time can exhaust memory and cause system instability or denial of service on affected Linux systems.

How an attack unfolds

An attacker with local access triggers repeated load/unload cycles or error paths in the FMAN MAC driver to accumulate unreleased device references, gradually consuming kernel memory until the system becomes unresponsive.

How to fix it

Update the Linux kernel to a version containing commit 5ed4334fc9512f934fe2ae9c4cf7f8142e451b8b or later; rebuild and reboot with the patched kernel image.

How to confirm the fix worked

Confirm the running kernel contains the referenced commit or a backport that releases all device references on error paths and in mac_remove(); inspect driver source for balanced of_device_put() calls.

Typical attack path

1. Obtain local access to a system using the vulnerable FMAN driver
2. Trigger mac_probe() error conditions or repeated module load/remove operations
3. Accumulate unreleased device references leading to memory pressure
4. Induce kernel memory exhaustion resulting in denial of service

How to detect it

Review kernel logs for repeated FMAN/MAC probe or remove messages; correlate with increasing slab or device reference counts via /proc/meminfo or kmemleak reports over time.

What your security team should do

• Prioritize kernel upgrade on all systems using the FSL FMAN driver
• Monitor memory usage on affected hosts for unexpected growth after driver probe/remove events
• Apply the fix within standard change windows given the local-only impact and absence from KEV