CVE-2023-52690

What it actually does

Missing null pointer check after kasprintf() in scom_debug_init_one() allows NULL dereference leading to kernel crash or memory leak on allocation failure in powerpc/powernv debug initialization path.

Why it matters to the business

Local users or processes can trigger denial of service via kernel panic on affected powerpc systems; low prevalence and no known active exploitation reduce immediate operational risk but still require patching to maintain stability.

How an attack unfolds

An attacker with local access invokes the scom debug initialization path where kasprintf fails to allocate memory; the unchecked NULL pointer is later dereferenced, causing a crash. No remote or unauthenticated vectors exist and no named threat actors are associated.

How to fix it

Update to fixed kernel versions containing the null check commit; for listed suricata packages apply 1:7.0.8-1 or GIT commit 6882bcb3e51bd3cf509fb6569cc30f48d7bb53d7 where applicable.

How to confirm the fix worked

Confirm presence of the null pointer check after kasprintf in scom_debug_init_one() via source inspection or kernel version comparison; test allocation failure paths under memory pressure.

Typical attack path

1. Obtain local user or process execution on powerpc/powernv system
2. Trigger scom_debug_init_one() via debugfs or kernel module load
3. Force kasprintf allocation failure through memory pressure
4. Trigger NULL dereference leading to kernel oops or panic

How to detect it

Review kernel logs for oops or panic messages referencing scom_debug_init_one or powernv; no widespread exploitation indicators exist.

What your security team should do

• Apply kernel updates containing the fix within standard maintenance windows
• Monitor for local denial-of-service reports on powerpc systems
• Review debugfs and powernv module loading policies to limit exposure