CVE-2024-50023

What it actually does

Use-after-free via stale LED pointers remaining in the PHY LEDs list after unregister, causing kernel panic on subsequent port teardown when the list contains both freed and active entries.

Why it matters to the business

Unexpected kernel crashes and system instability on Linux hosts during repeated PHY port or driver module lifecycle events, increasing downtime risk for network-dependent services.

How an attack unfolds

An attacker with the ability to control PHY port state and kernel module loading triggers the race by bringing a port down (unregistering LEDs), removing the PHY kmod, re-adding the kmod, bringing the port up (re-registering LEDs), then bringing the port down again, leaving dangling list entries that panic the kernel on next access.

How to fix it

Update the Linux kernel to a version containing commit 143ffa7878e2d9d9c3836ee8304ce4930f7852a3 or later; for Rocky Linux 8 systems apply the fixed file-roller package version 0:3.28.1-4.el8 or newer equivalent kernel update from the distribution.

How to confirm the fix worked

Confirm the running kernel contains commit 143ffa7878e2d9d9c3836ee8304ce4930f7852a3, verify the PHY driver source no longer omits list removal on LED unregister, and test repeated port down/up plus module reload cycles without panic.

Typical attack path

1. Obtain local or container access sufficient to manipulate network interfaces and load/unload PHY modules
2. Bring the target PHY port administratively down to trigger LED unregistration
3. Unload the PHY kernel module
4. Reload the PHY kernel module and bring the port back up
5. Bring the port down a second time to traverse the now-corrupted LEDs list
6. Trigger kernel panic from use of previously unregistered list entries

How to detect it

Monitor kernel logs for oops or panic messages referencing phy_led or LED list traversal after PHY unregister; inspect dmesg and journalctl for repeated port down/up sequences followed by crashes; correlate with module load/unload events in audit logs.

What your security team should do

• Apply the referenced kernel commit or distribution package update immediately on all affected systems
• Prioritize patching hosts that frequently reload PHY drivers or toggle network ports
• Add kernel oops/panic monitoring for PHY-related list traversals to detect latent exposure
• Review and limit unprivileged access to network interface and module management where feasible