CVE-2024-50002: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-2024-50002

In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; }; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.

AI Analysis

Technical Summary

CVE-2024-50002 is a vulnerability in the Linux kernel related to the handling of static calls during module initialization and cleanup. Specifically, the issue arises in the static_call_del_module() function, which is responsible for cleaning up static call module entries if module initialization fails. During module insertion, static_call_add_module() initializes static calls by invoking __static_call_init(), which allocates a struct static_call_mod to encapsulate static call sites or append the module to a module chain. If this allocation fails, __static_call_init() returns an error, and the module core calls static_call_del_module() to clean up. However, static_call_del_module() incorrectly assumes that the key::mods pointer is always valid and dereferences it without verifying whether it actually points to a struct static_call_mod or a struct static_call_site. This pointer is part of a union differentiated by a bit flag (bit 0), where the pointer can either be to mods or sites. If the pointer is actually to sites (indicating built-in static call sites), dereferencing it as mods leads to a general protection fault (#GP), causing a kernel crash. The vulnerability stems from the failure to check the pointer type before dereferencing, which can cause system instability or denial of service during module insertion failure scenarios. The fix involves adding a check to determine whether the pointer is a sites or mods pointer and only proceeding with cleanup if it is a mods pointer. If it is a sites pointer, the cleanup is skipped or terminated early to avoid dereferencing invalid memory. This vulnerability affects specific Linux kernel versions identified by commit hashes and does not require user interaction but does require module insertion privileges. No known exploits are reported in the wild as of the publication date.

Potential Impact

For European organizations, this vulnerability poses a risk primarily to systems running affected Linux kernel versions where kernel modules are dynamically inserted. The impact is mainly a potential denial of service due to kernel crashes triggered by module insertion failures. This could affect servers, embedded devices, or workstations that rely on dynamic kernel modules for functionality or hardware support. Critical infrastructure, cloud providers, and enterprises using Linux-based systems for networking, virtualization, or container orchestration could experience service disruptions. Although the vulnerability does not directly lead to privilege escalation or remote code execution, the resulting kernel panic could cause downtime, impacting availability and operational continuity. Organizations with automated deployment or update systems that insert kernel modules dynamically may see increased risk if error handling triggers this flaw. Given the Linux kernel's widespread use in European data centers, telecom infrastructure, and industrial control systems, the vulnerability could have a broad operational impact if exploited or triggered inadvertently.

Mitigation Recommendations

1. Apply the official Linux kernel patch that addresses CVE-2024-50002 as soon as it becomes available from trusted sources or distribution vendors. 2. Monitor kernel module insertion logs and system crash reports to detect any occurrences of general protection faults related to static calls. 3. Limit kernel module insertion privileges strictly to trusted administrators and processes to reduce the risk of triggering the vulnerability. 4. Where possible, avoid dynamic module insertion on critical systems or use statically compiled kernels to reduce exposure. 5. Implement robust testing and validation of kernel modules before deployment to minimize insertion failures that could trigger this issue. 6. Employ kernel live patching solutions that may provide interim fixes without requiring full system reboots. 7. Maintain up-to-date backups and high availability configurations to mitigate the impact of potential downtime caused by kernel crashes. 8. Coordinate with Linux distribution vendors for timely updates and advisories specific to affected kernel versions.