diff options
| author | Scott Moser <[email protected]> | 2026-07-28 12:33:28 -0700 |
|---|---|---|
| committer | Heinrich Schuchardt <[email protected]> | 2026-07-31 11:06:37 +0200 |
| commit | d78ba22ab2df094a659a7ffa85e0787037f7e3a7 (patch) | |
| tree | 942b8792e7ea70d5f88e15601df7b9af4eabbd29 /include | |
| parent | c9baa7611b2a00f31dc5855b9b3572bfac1fd0a8 (diff) | |
efi_loader: fix use of uninitialized guid in variable enumeration loops
efi_bootmgr_delete_invalid_boot_option(), eficonfig_show_boot_selection(),
and eficonfig_create_change_boot_order_entry() each enumerate all EFI
variables by repeatedly calling efi_next_variable_name() in a loop,
passing the same efi_guid_t as both input and output. GetNextVariableName()
needs the vendor GUID returned by the previous call, together with the
variable name it returned, to know where to resume.
In each of these loops the efi_guid_t was declared inside the loop body,
so a new instance comes into scope on every iteration. Relying on it to
still hold the previous iteration's value depends on the compiler reusing
the same stack slot across iterations, which is undefined behavior. With
a compiler that zero-initializes locals by default (e.g. clang, or gcc
configured with -ftrivial-auto-var-init=zero), the GUID is cleared on
every iteration, so the lookup of the variable name returned by the
previous call fails and efi_init_obj_list() aborts:
Cannot initialize UEFI sub-system
** Booting bootflow ... with efi
Boot failed (err=-22)
Move the efi_guid_t declarations out of the loops so the value written
by the previous efi_next_variable_name() call is preserved across
iterations.
Fixes: 140a8959d48f ("eficonfig: use efi_get_next_variable_name_int()")
Signed-off-by: Scott Moser <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions
