CVE-2024-50024

What it actually does

Unsafe iteration over a netlink multicast listener list during genetlink family unregistration allows element removal inside the loop, resulting in use-after-free and invalid memory access that crashes the kernel.

Why it matters to the business

Unpatched systems risk unexpected kernel crashes and reboots when genetlink families with active listeners are unregistered, causing service disruption and potential data loss in network-heavy workloads; low exploitation likelihood reduces immediate urgency but kernel stability remains critical for Linux hosts.

How an attack unfolds

An attacker with local privileges or control over module loading/unloading triggers genetlink family deletion (for example via rmmod or interface teardown) while multicast listeners remain registered; the unsafe list walk then dereferences freed memory, producing a kernel oops and denial of service.

How to fix it

Upgrade the Linux kernel to a build containing commit 464801a0f6ccb52b21faa33bac6014fd74cc5e10 or later; Rocky Linux 8 users should install gcc-toolset-10-gcc-0:10.3.1-1.2.el8_5 or newer equivalent package that incorporates the fix; reboot after kernel update.

How to confirm the fix worked

Confirm the running kernel contains commit 464801a0f6ccb52b21faa33bac6014fd74cc5e10 via uname or kernel source inspection; attempt to reproduce the original crash scenario with active listeners and family unregistration and verify the system remains stable.

Typical attack path

1. Obtain local access or ability to unload kernel modules on target Linux system
2. Ensure multicast listeners exist for a genetlink family
3. Initiate deletion or unregistration of that genetlink family
4. Trigger the unsafe list iteration that removes elements during traversal
5. Cause kernel access of freed memory leading to panic

How to detect it

Review kernel logs for oops or panic entries referencing netlink_update_socket_mc, __netlink_clear_multicast_users, or genl_unregister_family around the time of family unregistration; correlate with process activity that unloads modules or tears down genetlink interfaces.

What your security team should do

• Prioritize kernel updates on all production Linux systems within standard change windows
• Monitor vendor advisories for backported fixes in distribution kernels
• Restrict unprivileged module loading where feasible to reduce attack surface
• Include kernel oops logs in routine crash-dump review processes