CVE-2026-43148

What it actually does

This is a local denial-of-service flaw in the Linux kernel on PowerPC systems. The vulnerable code path in the PowerPC SMP topology parsing logic allocates memory with kcalloc() in parse_thread_groups() and then passes the result to of_property_read_u32_array() without first confirming that allocation succeeded. If memory allocation fails, the kernel can dereference a NULL pointer, causing a kernel oops or panic. The impact is availability loss only; there is no expected confidentiality or integrity impact and no indication of privilege escalation or remote code execution.

Why it matters to the business

A low-privileged local user or workload on an affected PowerPC Linux system may be able to crash the host under memory-pressure conditions, causing service interruption, failed jobs, node reboots, or degraded platform availability. Risk is lower than many kernel issues because exploitation requires local access, the affected architecture is specific to PowerPC, EPSS is very low at 0.00128 with no upward 30-day trend, there is no known public exploit maturity, and it is not listed in CISA KEV or ransomware-associated KEV data. Organizations running PowerPC-based Linux infrastructure should still remediate through standard kernel update processes because kernel crashes can have significant operational impact on clustered, appliance, or specialized compute systems.

How an attack unfolds

An attacker first needs local execution capability on an affected PowerPC Linux system, such as access to a shell, compromised service account, or ability to run an untrusted workload. The attacker attempts to create or time severe memory pressure so that kcalloc() fails while the kernel is parsing PowerPC thread group topology information. If the vulnerable parse_thread_groups() path runs and the allocation returns NULL, the kernel passes that NULL pointer into of_property_read_u32_array(), resulting in a NULL pointer dereference. Depending on kernel panic settings and system configuration, this may crash the kernel, trigger a panic, reboot the machine, or leave services unavailable. There are no known named threat actors, KEV listing, or public exploit maturity associated with this CVE based on the provided intelligence.

How to fix it

Apply a vendor-supported Linux kernel update that includes the PowerPC SMP fix adding a kcalloc() return-value check in parse_thread_groups(). Because no exact fixed package versions were provided, use the relevant Linux distribution, appliance, or kernel maintainer advisory to identify the corrected kernel build for affected PowerPC systems. Prioritize PowerPC hosts that allow untrusted local users, shared workloads, interactive shell access, build jobs, batch compute, or containerized workloads. If immediate patching is not possible, reduce exposure by restricting local access, limiting untrusted workload execution, enforcing memory and CPU resource controls, monitoring for memory exhaustion, and scheduling controlled reboots only after maintenance windows. Generic mitigations cannot fully eliminate the issue because the flaw is in kernel error handling and requires a patched kernel to correct safely.

How to confirm the fix worked

Confirm whether systems are affected by identifying PowerPC Linux hosts and comparing their running kernel package and source patch level against the vendor advisory that contains the parse_thread_groups() kcalloc() failure check. On source-based or custom kernels, verify that arch/powerpc/kernel/smp.c checks the kcalloc() return value before calling of_property_read_u32_array(). After patching, confirm the corrected kernel is installed and running, not merely staged, by checking the active kernel version after reboot. Validate exposure reduction by confirming untrusted local access is restricted and resource limits are enforced for workloads that can create memory pressure. Review system logs after remediation for absence of recurring kernel oops or panic messages referencing parse_thread_groups(), of_property_read_u32_array(), NULL pointer dereference, or PowerPC SMP topology parsing.

Typical attack path

1. Gain local, low-privileged execution on an affected PowerPC Linux system.
2. Generate or wait for high memory pressure conditions so that a kernel kcalloc() allocation is more likely to fail.
3. Trigger the PowerPC SMP/thread topology parsing path, where applicable, such as during relevant CPU topology initialization or reconfiguration activity.
4. Cause parse_thread_groups() to pass a failed allocation result into of_property_read_u32_array().
5. Induce a NULL pointer dereference in kernel space, leading to a kernel oops, panic, reboot, or system unavailability.

How to detect it

To determine whether this issue may already have been exploited, review kernel and system logs for crashes or oops events involving NULL pointer dereferences in the PowerPC SMP topology code. Useful log sources include journald, syslog, /var/log/kern.log, /var/log/messages, dmesg output, crash dumps, kdump/vmcore analysis, hypervisor reset logs, and uptime/reboot telemetry. Look for temporal correlation between kernel crashes and high memory pressure, out-of-memory activity, local user sessions, batch jobs, containers, or workload launches. Specific artifacts of interest include stack traces naming parse_thread_groups(), of_property_read_u32_array(), arch/powerpc/kernel/smp.c, kcalloc allocation failure, or PowerPC SMP/thread group parsing. Because this is a local denial-of-service condition and no public exploit maturity or named threat actor activity is provided, detection should focus on unexplained PowerPC kernel crashes rather than network indicators.

• parse_thread_groups
• of_property_read_u32_array
• arch/powerpc/kernel/smp.c
• NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops: Kernel access of bad area
• powerpc/smp
• kcalloc
• thread-groups
• Out of memory
• invoked oom-killer

What your security team should do

• Inventory Linux systems running on PowerPC architecture and identify which kernels are affected according to vendor advisories.
• Patch affected PowerPC systems through normal kernel update channels and reboot into the fixed kernel.
• Prioritize systems with shared users, untrusted workloads, shell access, CI/build workloads, batch compute, containers, or other conditions where local users can intentionally create memory pressure.
• Until patched, restrict local login and workload execution to trusted users and enforce resource limits to reduce the chance of allocation-failure-triggered crashes.
• Configure monitoring and alerting for kernel oops, panic, unexpected reboot, and memory exhaustion events on PowerPC Linux systems.
• Correlate any crash events with local user activity, workload starts, memory-pressure events, and CPU hotplug or topology-related events where available.
• Treat this as an availability-risk kernel defect rather than a remote compromise indicator unless additional evidence of intrusion is present.