CVE-2024-50137

What it actually does

Null pointer dereference when reset_control_status is called on JH7110 SoC because data->asserted remains uninitialized (NULL) after the JH7110 reset driver was added.

Why it matters to the business

Kernel instability or crashes on JH7110-based systems when reset status queries occur, potentially affecting device reliability in embedded and SoC deployments.

How an attack unfolds

An attacker with local access triggers code paths that invoke reset_control_status on a JH7110 system, causing the kernel to dereference the uninitialized asserted pointer and resulting in a crash or memory corruption.

How to fix it

Update the Linux kernel to the commit 3918b2016d28c9b2bddd5ab194ab366a4e2310f5 or later stable releases that include the added NULL check for data->asserted on JH7110.

How to confirm the fix worked

Confirm the presence of the NULL guard before accessing asserted in the starfive reset driver source and verify that reset_control_status succeeds without kernel faults on JH7110 hardware.

Typical attack path

1. Obtain local code execution on a JH7110-based Linux system
2. Trigger reset framework operations that call reset_control_status
3. Kernel dereferences NULL asserted member leading to oops or corruption

How to detect it

Review kernel logs for oops or NULL pointer dereference messages involving the starfive reset driver; no authenticated exploitation artifacts are known.

What your security team should do

• Prioritize kernel updates on all JH7110 deployments within normal patching cycles
• Monitor for kernel oops related to reset drivers in system logs
• Test reset framework functionality after applying the fix