CVE-2024-49926

What it actually does

Invalid memory access to a non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() when CONFIG_FORCE_NR_CPUS=y sets nr_cpu_ids to NR_CPUS instead of actual possible CPUs, resulting in page fault and kernel panic.

Why it matters to the business

Systems built with high NR_CPUS values experience unexpected kernel panics and crashes during RCU tasks operation, causing unplanned downtime and requiring reboots on affected Linux deployments.

How an attack unfolds

The condition is triggered internally by RCU tasks kthread on boot or during operation on misconfigured kernels; no remote attacker interaction is required, though listed threat actors have shown interest in similar Linux kernel memory issues.

How to fix it

Update Linux kernel to commit b3b2431ed27f4ebc28e26cdf005c1de42dc60bdf or later; rebuild with corrected maximum CPU number handling for enqueue/dequeue limits; apply vendor patches for affected distributions.

How to confirm the fix worked

Verify kernel source contains the fix commit; confirm nr_cpu_ids usage replaced by maximum possible CPU count in rcu_tasks_need_gpcb(); test boot on CONFIG_FORCE_NR_CPUS=y builds without panic.

Typical attack path

1. Kernel boots with CONFIG_FORCE_NR_CPUS=y and NR_CPUS exceeding actual CPUs
2. rcu_tasks_kthread invokes rcu_tasks_need_gpcb()
3. Function indexes into percpu array using nr_cpu_ids exceeding valid range
4. Page fault occurs on non-existent percpu address
5. Kernel oops and panic terminate the system

How to detect it

Search kernel logs and dmesg for oops involving rcu_tasks_need_gpcb, page_fault_oops on percpu addresses, and call traces containing rcu_tasks_one_gp or rcu_tasks_kthread; check for tainted kernel messages with G W flags around CPU setup.

• rcu_tasks_need_gpcb+0x25d/0x2c0
• BUG: unable to handle page fault for address: ffffffff9911c8c8
• rcu_tasks_trace Tainted: G W
• smpboot: Allowing .* CPUs, .* hotplug CPUs
• setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512

What your security team should do

• Prioritize kernel upgrade on all systems using CONFIG_FORCE_NR_CPUS=y
• Review kernel configs for NR_CPUS values exceeding hardware CPU count
• Monitor for related panics in production kernels built after 2024-10-21
• Apply fixed versions for dependent packages such as libserf and utf8proc where listed