CVE-2026-92476

What it actually does

Race condition allows interrupt handler to invoke complete() on an uninitialized completion structure during device probe, resulting in undefined kernel behavior.

Why it matters to the business

Systems using affected hardware may experience sudden crashes or instability during driver initialization, leading to unplanned downtime on servers or embedded devices.

How an attack unfolds

An attacker with the ability to trigger repeated device probe or unload events could attempt to win the narrow timing window between IRQ registration and completion initialization, though successful exploitation for code execution is considered unlikely.

How to fix it

Update to a Linux kernel version containing the fix that initializes irq_completion before requesting the IRQ; apply the same pattern used by the sibling OCS HCU and ECC drivers.

How to confirm the fix worked

Inspect the probe function source to confirm irq_completion initialization precedes the request_irq call; boot test on affected hardware while monitoring for kernel oops during module load.

Typical attack path

1. Obtain local or physical access sufficient to load/unload the keembay crypto driver
2. Trigger kmb_ocs_aes_probe() while simultaneously generating spurious interrupts
3. Cause the handler to execute complete() against the uninitialized object
4. Induce kernel panic or memory corruption

How to detect it

Review kernel logs for oops or warnings referencing ocs_aes_irq_handler or kmb_ocs_aes_probe around driver load events; examine stack traces showing use of uninitialized completion.

What your security team should do

• Prioritize kernel updates on any systems exposing the keembay driver
• Monitor vendor advisories for backported patches in LTS kernels
• Consider blacklisting the module if the hardware is not required