CVE-2025-39772

What it actually does

NULL pointer dereference in hibmc_unload error path when mode.config mutexes are uninitialized after hibmc load failure.

Why it matters to the business

Systems using the hibmc driver may experience unexpected crashes or service disruption during driver initialization failures, with limited real-world exploit likelihood given low EPSS and no known campaigns.

How an attack unfolds

An attacker with local access triggers a hibmc load failure scenario that exercises the buggy error handling path, resulting in a kernel NULL dereference and potential denial of service; no named threat actors have been observed exploiting this specific issue.

How to fix it

Update to fixed kernel commit ddf1691f25345699296e642f0f59f2d464722fa3 or later; for argocd-fips-3.1 packages on MinimOS upgrade to 3.1.1-r3 or newer.

How to confirm the fix worked

Confirm kernel source contains the return statement change instead of goto in the hibmc load failure path and verify driver loads cleanly without triggering the NULL access.

Typical attack path

1. Obtain local access to a system with the hibmc driver present
2. Force or wait for a hibmc load failure condition
3. Trigger the hibmc_unload path that dereferences uninitialized mutexes
4. Cause kernel panic or system instability

How to detect it

Inspect kernel logs and dmesg for hibmc initialization failures followed by NULL pointer dereference oops; correlate with process crashes or system reboots on affected hardware.

What your security team should do

• Prioritize patching MinimOS argocd-fips deployments to 3.1.1-r3 within normal change windows
• Monitor upstream stable kernel updates for hibmc-related commits
• Review logs for hibmc load failures as part of routine kernel stability checks