Secure Boot dbx configuration Update: failed to write-firmware: failed to write data to efivarsfs: Error writing to file descriptor: Cannot allocate memory

Ask Fedora
1

Hello,

In Gnome firmware update, there is an Integrated Firmware update availaible for Secure Boot dbx Configuration Update 20250902 → 20260402.

When I click the update button, it shows an error:

failed to write-firmware: failed to write data to efivarsfs: Error writing to file descriptor: Cannot allocate memory

I tried the update from the terminal, same error:

> sudo fwupdmgr update
╔══════════════════════════════════════════════════════════════════════════════╗
║ Upgrade UEFI dbx from 20250902 to 20260402?                                  ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ This updates the list of forbidden signatures (the "dbx") to the latest      ║
║ release from Microsoft.                                                      ║
║                                                                              ║
║ Some insecure bootloaders were added, due to security vulnerabilities that   ║
║ allowed an attacker to bypass UEFI Secure Boot. The additional entries were  ║
║ from:                                                                        ║
║                                                                              ║
║ • Baramanudi Management Suite                                                ║
║ • EAZ EasyFix                                                                ║
║ • Finland Matriculation Examination Board                                    ║
║ • NTC IT ROSA Linux                                                          ║
║ • PC-Doctor                                                                  ║
║ • Spyrus WTGCreator                                                          ║
║ • WhiteCanyon blancco                                                        ║
║ • Some ancient shim releases for OpenSUSE, Oracle and Red Hat                ║
║                                                                              ║
╚══════════════════════════════════════════════════════════════════════════════╝
Perform operation? [Y|n]: 
Decompressing…           ▕⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿▏
failed to write-firmware: failed to write data to efivarsfs: Error writing to file descriptor: Cannot allocate memory

> fwupdmgr get-devices
LENOVO 30HACTO1WW
...
├─System Firmware:
...
│ └─UEFI dbx:
│       Device ID:        362301da643102b9f38477387e2193e57abaa590
│       Summary:          UEFI revocation database
│       Current version:  20250902
│       Minimum Version:  20250902
│       Vendor:           Microsoft (UEFI:Microsoft)
│       URL:              https://uefi.org/revocationlistfile
│       Install Duration: 1 second
│       Update State:     Failed
│       Update Error:     failed to write-firmware: failed to write data to efivarsfs: Error writing to file descriptor: Cannot allocate memory
│       Last modified:    2026-07-04 13:49:38
│       GUID:             f8ba2887-9411-5c36-9cee-88995bb39731 ← UEFI\CRT_A1117F516A32CEFCBA3F2D1ACE10A87972FD6BBE8FE0D0B996E09E65D802A503&ARCH_X64
│       Device Flags:     • Internal device
│                         • Updatable
│                         • Supported on remote server
│                         • Needs a reboot after installation
│                         • Device is usable for the duration of the update
│                         • Only version upgrades are allowed
│                         • Signed Payload
│                         • Can tag for emulation
│     
...

Computer is a Lenovo ThinkStation P3
running Fedora 44 workstation

How can I fix this error?
Thank you

2

The upstream project recommends first trying a BIOS reset, and also suggests some potential workarounds.

3

To add a bit of detail.
The bios has a limited space for storage of keys and dbx. If that space is filled up it cannot perform updates.

Resetting the bios to factory default wipes out the user added keys and extra dbx info as it resets everything to default.

Once the reset completes, the bios will likely be reset to secure boot enabled and secure boot will need to be switched to disabled if the user has any drivers installed that were locally compiled, at least until the signing keys are enrolled into bios again.

To see what keys, and how many, may be enrolled use the command mokutil --list-enrolled --short. On my system that shows 4; 2 default, one from grub and one for my locally compiled kernel modules.

After the reset you should be able to update the dbx and import any local keys needed, as well as changing any necessary local configs within the bios setup menu from default to your own settings.

4

Thank you. Very helpful detailed explanation.

Reboot after secure boot reset was veeeery long.
Then nothing was working in Gnome anymore. I didn’t see your message then and found the hardway I had to disable secureboot.

Finally, Secure Boot dbx Configuration updated.