]> git.ipfire.org Git - thirdparty/linux.git/commit
efivarfs: fix error on write to new variable leaving remnants
authorJames Bottomley <James.Bottomley@HansenPartnership.com>
Sun, 19 Jan 2025 15:12:12 +0000 (10:12 -0500)
committerArd Biesheuvel <ardb@kernel.org>
Sun, 19 Jan 2025 16:50:26 +0000 (17:50 +0100)
commit908af31f4896f2c0645031f8b74a89d3a8beb5b9
treea9a746d07e9db5900e6ecf920f992cabcdb46fd1
parenta58e954464db477307ac879d772a535deca8efb7
efivarfs: fix error on write to new variable leaving remnants

Make variable cleanup go through the fops release mechanism and use
zero inode size as the indicator to delete the file.  Since all EFI
variables must have an initial u32 attribute, zero size occurs either
because the update deleted the variable or because an unsuccessful
write after create caused the size never to be set in the first place.
In the case of multiple racing opens and closes, the open is counted
to ensure that the zero size check is done on the last close.

Even though this fixes the bug that a create either not followed by a
write or followed by a write that errored would leave a remnant file
for the variable, the file will appear momentarily globally visible
until the last close of the fd deletes it.  This is safe because the
normal filesystem operations will mediate any races; however, it is
still possible for a directory listing at that instant between create
and close contain a zero size variable that doesn't exist in the EFI
table.

Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
fs/efivarfs/file.c
fs/efivarfs/internal.h
fs/efivarfs/super.c