CVE-2024-49926 is a vulnerability identified in the Linux kernel related to the handling of CPU identifiers when the kernel is built with the CONFIG_FORCE_NR_CPUS=y configuration option. This option forces the kernel to support a fixed maximum number of CPUs (NR_CPUS), rather than dynamically determining the number of possible CPUs (nr_cpu_ids). The vulnerability arises because nr_cpu_ids is incorrectly defined as NR_CPUS instead of the actual number of possible CPUs, leading to improper handling of per-CPU variables in the rcu_tasks_need_gpcb() function. This misconfiguration can cause the kernel to access non-existent per-CPU variables, resulting in a system panic and a kernel oops (crash). The crash is triggered by a page fault when the kernel attempts to access an invalid memory address associated with the non-existent per-CPU variable. The vulnerability specifically affects the Read-Copy-Update (RCU) subsystem's task handling, which is critical for kernel synchronization and concurrency. The root cause is the assumption that CPU numbering is contiguous and matches NR_CPUS, which is not always true when CPU hotplugging or holes in CPU numbering exist. The fix involves using the maximum possible CPU number instead of nr_cpu_ids to configure enqueue and dequeue limits, preventing out-of-bounds access. This vulnerability can cause denial of service (DoS) through kernel panic, affecting system availability. No known exploits are reported in the wild as of the publication date. The vulnerability affects Linux kernel versions built with the specified configuration, which may be present in certain custom or enterprise Linux distributions. No CVSS score has been assigned yet.

For European organizations, the primary impact of CVE-2024-49926 is the potential for denial of service due to kernel panics on affected Linux systems. This can disrupt critical infrastructure, enterprise servers, cloud environments, and embedded systems running Linux kernels compiled with CONFIG_FORCE_NR_CPUS=y. Such panics can lead to unexpected system reboots or downtime, affecting availability of services and potentially causing operational disruptions. Organizations relying on high-availability Linux servers, especially those using customized kernels or large-scale multi-CPU systems, may experience instability or outages. While this vulnerability does not directly compromise confidentiality or integrity, the loss of availability can have cascading effects on business operations, data processing, and service delivery. Given the widespread use of Linux in European data centers, cloud providers, and industrial control systems, unpatched systems could face increased risk of service interruptions. The absence of known exploits reduces immediate risk, but the vulnerability should be addressed promptly to avoid accidental or targeted triggering of kernel panics.

1. Identify Linux systems compiled with CONFIG_FORCE_NR_CPUS=y, particularly those running kernels with large NR_CPUS values or customized builds. 2. Apply the official Linux kernel patches that fix the rcu_tasks_need_gpcb() function to correctly handle CPU numbering and prevent invalid memory access. 3. For distributions that do not provide immediate patches, consider recompiling the kernel without CONFIG_FORCE_NR_CPUS=y or with updated kernel sources that include the fix. 4. Implement robust monitoring of kernel logs and system stability to detect early signs of kernel panics related to this issue. 5. In virtualized or cloud environments, ensure hypervisor and guest kernel configurations avoid forced CPU counts that could trigger this vulnerability. 6. Test kernel updates in staging environments before deployment to production to verify stability and compatibility. 7. Maintain an inventory of Linux kernel versions and configurations across the organization to prioritize patching efforts. 8. Collaborate with Linux distribution vendors for timely updates and advisories related to this vulnerability.