CVE-2022-48953

What it actually does

Incorrect call order causes acpi_install_fixed_event_handler to enable events before rtc_handler can safely retrieve the cmos object via dev_get_drvdata, resulting in NULL pointer dereference on RTC fixed event during early boot.

Why it matters to the business

Affected Linux systems risk boot-time crashes and service unavailability, with the issue now impacting more configurations after a prior change widened exposure.

How an attack unfolds

During kernel initialization an active RTC fixed event fires before driver data is populated; rtc_handler dereferences a NULL pointer and crashes the system. Threat actors in espionage and financially motivated campaigns have targeted similar Linux kernel initialization flaws.

How to fix it

Upgrade the rtc-cmos driver so that cmos_wake_setup is invoked only after a successful cmos_do_probe call; apply the ordering fix described in the resolution and any downstream package updates that include the corrected initialization sequence.

How to confirm the fix worked

Confirm the driver source calls cmos_do_probe before cmos_wake_setup, verify that dev_get_drvdata returns a valid pointer inside rtc_handler, and test boot on systems with ACPI fixed events enabled.

Typical attack path

1. Ensure RTC fixed event is active at boot
2. Trigger kernel initialization of rtc-cmos driver
3. Force NULL dereference in rtc_handler before cmos_do_probe completes
4. Crash the system

How to detect it

Inspect kernel boot logs and dmesg for NULL pointer dereference crashes originating from rtc_handler; correlate with ACPI fixed event activity at init time.

What your security team should do

• Prioritize patching Linux kernel packages containing the rtc-cmos fix
• Monitor boot logs for NULL pointer dereference in rtc_handler
• Review systems for recent ACPI-related changes that increased exposure
• Test the updated driver on representative hardware before broad deployment