Critical Bug: Secure Boot dbx update breaks battery EC & BitLocker on Lenovo Slim 7

Hardware Support
1

Captura desde 2026-07-23 12-02-28
Captura desde 2026-07-23 12-02-28834Ă—262 14.6 KB

:pushpin: Issue Summary

A critical hardware issue was encountered immediately after applying the Secure Boot dbx configuration update via the Zorin OS Software Store (fwupd / GNOME Software). The update broke communication between the motherboard’s Embedded Controller (EC) and the battery management subsystem, causing the laptop to abruptly stop charging. Simultaneously, the manual UEFI key reset performed in the BIOS to recover the system invalidated the TPM state, triggering a Windows 11 BitLocker recovery prompt on subsequent boots.

1. System Environment

  • Device: Lenovo Slim 7 (14ILL10)
  • OS Environment: Zorin OS (Dual Boot with Windows 11)
  • Subsystems Affected: Firmware / fwupd / UEFI / Power Management (upower) / TPM 2.0

2. Trigger Event & Package Details

  • Update Name: Secure Boot dbx configuration update
  • Version Transition: 20250507 $\rightarrow$ 20260402
  • Delivery Method: Zorin OS Software Store (GNOME Software)

3. Detailed Timeline & Symptoms

A. Abrupt Loss of Battery Power Management (Primary Hardware Issue)

  1. The laptop was being used on battery power (at approximately 79%–80% charge level) and was then connected to the AC power adapter.
  2. The system was actively charging while the Secure Boot dbx update finished applying in the background.
  3. Immediately upon completion of the firmware update, charging abruptly halted.
  4. The battery controller completely stopped reporting valid telemetry to the OS. Running upower -i /org/freedesktop/UPower/devices/battery_BAT0 produced the following anomalous state:
  • native-path: (null)
  • power supply: no
  • Outdated/invalid timestamp readings (e.g., Wed 31 Dec 1969).
  1. This behavior indicates a complete communication failure on the internal bus (I2C/SMBus) between the motherboard Embedded Controller (EC) and the battery management IC.

B. BitLocker Lockout on Windows (Recovery Side Effect)

  1. To recover battery communication and clear the broken firmware state, factory UEFI keys were restored in the BIOS settings.
  2. This necessary modification altered the NVRAM baseline and TPM 2.0 trust state.
  3. Consequently, Windows 11 detected a hardware security environment change and required the 48-digit BitLocker recovery key to unlock the drive on the next boot.

4. Workaround & Resolution Applied

To restore normal operation, the following manual steps were required:

  1. UEFI/BIOS Reset: Entered BIOS setup and executed "Restore Factory Keys" / cleared the updated Secure Boot key entries.
  2. Secure Boot Toggle: Set Secure Boot to Disabled to prevent MOK / signed loader conflicts with the dual-boot environment.
  3. Hardware Recovery: Immediately after resetting the keys, the Embedded Controller resumed communication with the battery. upower correctly detected BAT0 again (native-path restored), and AC charging resumed normally to 100%.
  4. Windows Recovery: Entered the 48-digit BitLocker key and disabled Device Encryption within Windows to prevent perpetual lockouts caused by the altered TPM/Secure Boot baseline.

5. Software Log Context (dpkg.log)

Around 14:35:37 – 14:36:42 UTC on the day of the incident, standard system maintenance updates were applied via dpkg (e.g., snapd, wget, remmina, libc-bin). None of these .deb packages interact with the EC or UEFI NVRAM. This confirms that the hardware disruption was exclusively caused by the parallel fwupd payload execution of the Secure Boot dbx update.

6. Impact & Escalation Request

Flashing this specific dbx revocation payload (20260402) via fwupd temporarily bricked the battery charging subsystem on this Lenovo hardware generation.

I kindly request the Zorin OS and fwupd maintainers to evaluate whether version 20260402 of the dbx payload requires hardware-specific blacklisting or modified flashing procedures for recent Lenovo Slim laptops to prevent user lockouts.

7. System Specs & Attachments

dpkg_incident.txt context:

Around 14:35:37 – 14:36:42 UTC, standard system maintenance updates were applied via dpkg (e.g., snapd, wget, remmina, libc-bin). None of these deb packages interact directly with the Embedded Controller or UEFI NVRAM. This confirms that the hardware disruption was uniquely triggered by the parallel fwupd execution of the Secure Boot dbx update.

system_specs.txt (Filtered inxi -Fz Output):

System:
  Kernel: 7.0.0-28-generic arch: x86_64 bits: 64
  Desktop: GNOME v: 46.0 Distro: Zorin OS 18.1 noble
Machine:
  Type: Laptop System: LENOVO product: 83MC v: Lenovo Slim 7 14ILL10
  Mobo: LENOVO model: LNVNB161216 v: SDK0T76574 WIN
  UEFI: LENOVO v: QSCN33WW date: 11/05/2025
Battery:
  ID-1: BAT1 charge: 54.0 Wh (77.1%) condition: 70.0/70.0 Wh (100.0%)
CPU:
  Info: 8-core model: Intel Core Ultra 7 258V bits: 64
Drives:
  ID-1: /dev/nvme0n1 vendor: SK Hynix model: HFS001TEM4X182N size: 953.87 GiB
Partition:
  ID-1: / size: 196.86 GiB used: 39.75 GiB (20.2%) fs: ext4 dev: /dev/nvme0n1p4
  ID-2: /boot/efi size: 256 MiB used: 49.1 MiB (19.2%) fs: vfat dev: /dev/nvme0n1p1
Info:
  Memory: total: 32 GiB used: 10.16 GiB (32.9%)