CVE-2025-39903

What it actually does

Uninitialized memory nodes in of_numa device-tree handling allow use of invalid NUMA data, triggering kernel panic on affected Linux systems.

Why it matters to the business

Unexpected system crashes on servers or cloud instances can interrupt services, cause data loss during operations, and require emergency reboots or kernel updates, especially in SUSE OpenStack environments.

How an attack unfolds

An attacker with local access crafts or triggers device-tree configurations that expose uninitialized NUMA nodes during early kernel boot or memory initialization, leading to a panic; no public exploits or threat actors are known.

How to fix it

Apply kernel updates containing commit c2daa6eb4740720b5bd0e06267d7c93a3eed844e or upgrade affected packages to fixed versions: galera-3 to 25.3.23-8.3, mariadb to 10.2.15-7.1, mariadb-connector-c to 3.0.3-1.3.3, rubygem-mysql2 to 0.4.10-7.2, xtrabackup to 2.4.10-5.3 on SUSE OpenStack Cloud 7.

How to confirm the fix worked

Verify kernel version or package versions match fixed releases; test boot with NUMA-enabled device trees and confirm absence of panic in dmesg or logs.

Typical attack path

1. Obtain local code execution or shell access on target system
2. Trigger NUMA or device-tree parsing code path via workload or crafted configuration
3. Cause kernel to reference uninitialized memory nodes
4. Induce panic and system crash

How to detect it

Review kernel logs for NUMA-related panic messages or uninitialized variable warnings during boot; check system uptime and crash dumps for patterns matching memory node initialization failures.

What your security team should do

• Prioritize patching Linux kernel and listed SUSE packages within standard change windows due to low EPSS but kernel stability risk
• Monitor for kernel panics in logs across affected systems
• Restrict local access and device-tree modifications until updated