CVE-2024-49885 is a vulnerability identified in the Linux kernel's memory management subsystem, specifically within the SLUB allocator, which is responsible for efficient kernel memory allocation. The issue arises from improper handling of the 'redzone' in kmalloc objects when the kernel is configured with SLUB debugging enabled (CONFIG_SLUB_DEBUG) and the init_on_free=1 option is set. The redzone is a protective buffer zone around allocated memory objects used to detect buffer overflows and memory corruption. Since commit 946fa0dbf2d8, the kernel treats the wasted space between the actual allocated object size and the originally requested size (orig_size) as a redzone. However, when init_on_free=1 is enabled, the entire allocated object size is zeroed out upon free, including the redzone area. Additionally, the orig_size metadata is cleared, causing the check_object() function to mistakenly treat the entire object as a redzone. This leads to kernel BUG reports indicating that the kmalloc redzone has been overwritten, which can cause system instability or crashes. The root cause is that the clearing operation does not respect the orig_size boundary, and the orig_size metadata is lost during the clearing process. The fix involves using orig_size to zero only the used portion of the object and restoring the orig_size value after clearing the remaining area. When SLUB debugging is disabled, orig_size defaults to the object size, simplifying the clearing process. This vulnerability affects Linux kernel versions containing the specified commit and can manifest during kernel memory deallocation, potentially leading to kernel panics or denial of service. There is no evidence of active exploitation in the wild at this time.

For European organizations, this vulnerability poses a risk primarily to systems running vulnerable Linux kernel versions with SLUB debugging and init_on_free enabled—configurations more common in development, testing, or specialized hardened environments rather than typical production servers. Exploitation can cause kernel crashes or instability, leading to denial of service conditions. Critical infrastructure, cloud providers, and enterprises relying on Linux-based systems for essential services could experience outages or degraded performance. Although this vulnerability does not directly lead to privilege escalation or remote code execution, the resulting system instability could be leveraged by attackers to disrupt services or as part of a multi-stage attack. The impact is more pronounced in environments where uptime and reliability are critical, such as financial institutions, healthcare providers, and industrial control systems prevalent in Europe. Furthermore, organizations employing custom kernel builds with debugging enabled may be more susceptible. Given the Linux kernel's widespread use across European industries and governments, unpatched systems could face operational risks and compliance challenges.

European organizations should first identify systems running affected Linux kernel versions with SLUB debugging and init_on_free enabled. Since this configuration is not default in most production environments, verifying kernel build options is essential. The primary mitigation is to apply the official patch that corrects the zeroing behavior to respect orig_size and preserves metadata during memory deallocation. Organizations should update to the latest stable Linux kernel releases that include this fix. For systems where upgrading the kernel is not immediately feasible, disabling SLUB debugging or the init_on_free option can serve as a temporary workaround, though this may reduce debugging capabilities or memory safety checks. Additionally, organizations should implement robust kernel crash monitoring and automated recovery mechanisms to minimize downtime in case of kernel panics. Regularly auditing kernel configurations and maintaining an inventory of kernel versions and build options will help prioritize patching efforts. Finally, integrating these checks into continuous integration pipelines for custom kernel builds can prevent vulnerable configurations from deployment.