CVE-2019-20908

What it actually does

Incorrect access permissions on the efivar_ssdt ACPI variable in the EFI subsystem allow a privileged local process to modify boot-time ACPI tables and thereby bypass kernel lockdown or Secure Boot enforcement.

Why it matters to the business

Organizations running vulnerable kernels on UEFI systems face the risk that an already-privileged attacker can load unsigned or malicious code at boot, undermining platform integrity controls and potentially leading to persistent compromise.

How an attack unfolds

An attacker first obtains root on a running Linux system, then writes a malicious SSDT table into the efivar_ssdt EFI variable; on the next reboot the kernel loads the table without signature verification, defeating lockdown and Secure Boot.

How to fix it

Upgrade the Linux kernel to a version containing commit 219d54332a09e8d8741c1e1982f5eae56099de85 (5.4 or later) and rebuild any custom kernels with the corrected efi.c driver; ensure Secure Boot remains enabled after the update.

How to confirm the fix worked

Verify the running kernel is 5.4 or newer, inspect drivers/firmware/efi/efi.c for the permission mask change on efivar_ssdt, and confirm that efivar_ssdt writes are rejected under lockdown or Secure Boot enforcement.

Typical attack path

1. Obtain local root privileges on a target system
2. Write attacker-controlled data into the efivar_ssdt EFI variable
3. Trigger a reboot so the kernel loads the modified ACPI table
4. Execute unsigned or malicious code that would otherwise be blocked by lockdown or Secure Boot

How to detect it

Review system logs for unexpected writes to EFI variables around efivar_ssdt, monitor kernel audit events for attempts to modify ACPI tables, and examine boot logs for unsigned SSDT loading after a reboot on vulnerable kernels.

What your security team should do

• Prioritize kernel upgrades on all UEFI Linux systems within the next maintenance window
• Audit any custom or downstream kernel builds for the presence of the vulnerable efi.c code
• Re-test Secure Boot and lockdown policies after patching to confirm bypass is no longer possible