kernel/linux.git/fs/efivarfs, branch v6.12.80

efivarfs: fix error propagation in efivar_entry_get()

2026-02-06T15:55:45+00:00

commit 4b22ec1685ce1fc0d862dcda3225d852fb107995 upstream. efivar_entry_get() always returns success even if the underlying __efivar_entry_get() fails, masking errors. This may result in uninitialized heap memory being copied to userspace in the efivarfs_file_read() path. Fix it by returning the error from __efivar_entry_get(). Fixes: 2d82e6227ea1 ("efi: vars: Move efivar caching layer into efivarfs") Cc: # v6.1+ Signed-off-by: Kohei Enju Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman

efivarfs: Fix slab-out-of-bounds in efivarfs_d_compare

2025-09-04T13:31:52+00:00

[ Upstream commit a6358f8cf64850f3f27857b8ed8c1b08cfc4685c ] Observed on kernel 6.6 (present on master as well): BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0 If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can become negative, leadings to oob. The issue can be triggered by parallel lookups using invalid filename: T1 T2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list lookup_open d_alloc_parallel __d_lookup_rcu __d_lookup_rcu_op_compare hlist_bl_for_each_entry_rcu // invalid dentry can be retrieved ->d_compare efivarfs_d_compare // oob Fix it by checking 'guid' before cmp. Fixes: da27a24383b2 ("efivarfs: guid part of filenames are case-insensitive") Signed-off-by: Li Nan Signed-off-by: Wu Guanghao Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin

efivarfs: Fix memory leak of efivarfs_fs_info in fs_context error paths

2025-07-24T06:56:36+00:00

[ Upstream commit 64e135f1eaba0bbb0cdee859af3328c68d5b9789 ] When processing mount options, efivarfs allocates efivarfs_fs_info (sfi) early in fs_context initialization. However, sfi is associated with the superblock and typically freed when the superblock is destroyed. If the fs_context is released (final put) before fill_super is called—such as on error paths or during reconfiguration—the sfi structure would leak, as ownership never transfers to the superblock. Implement the .free callback in efivarfs_context_ops to ensure any allocated sfi is properly freed if the fs_context is torn down before fill_super, preventing this memory leak. Suggested-by: James Bottomley Fixes: 5329aa5101f73c ("efivarfs: Add uid/gid mount options") Signed-off-by: Breno Leitao Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin

efivarfs: Fix error on non-existent file

2024-12-27T13:02:07+00:00

commit 2ab0837cb91b7de507daa145d17b3b6b2efb3abf upstream. When looking up a non-existent file, efivarfs returns -EINVAL if the file does not conform to the NAME-GUID format and -ENOENT if it does. This is caused by efivars_d_hash() returning -EINVAL if the name is not formatted correctly. This error is returned before simple_lookup() returns a negative dentry, and is the error value that the user sees. Fix by removing this check. If the file does not exist, simple_lookup() will return a negative dentry leading to -ENOENT and efivarfs_create() already has a validity check before it creates an entry (and will correctly return -EINVAL) Signed-off-by: James Bottomley Cc: [ardb: make efivarfs_valid_name() static] Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman

[tree-wide] finally take no_llseek out

2024-09-27T15:18:43+00:00

no_llseek had been defined to NULL two years ago, in commit 868941b14441 ("fs: remove no_llseek") To quote that commit, At -rc1 we'll need do a mechanical removal of no_llseek - git grep -l -w no_llseek | grep -v porting.rst | while read i; do sed -i '/\/d' $i done would do it. Unfortunately, that hadn't been done. Linus, could you do that now, so that we could finally put that thing to rest? All instances are of the form .llseek = no_llseek, so it's obviously safe. Signed-off-by: Al Viro Signed-off-by: Linus Torvalds

efivarfs: Convert to new uid/gid option parsing helpers

2024-07-02T04:21:18+00:00

Convert to new uid/gid option parsing helpers Signed-off-by: Eric Sandeen Link: https://lore.kernel.org/r/ff7c415c-43d4-4a1e-a987-246c781f8850@redhat.com Signed-off-by: Christian Brauner

efi: Clear up misconceptions about a maximum variable name size

2024-04-13T08:33:02+00:00

The UEFI specification does not make any mention of a maximum variable name size, so the headers and implementation shouldn't claim that one exists either. Comments referring to this limit have been removed or rewritten, as this is an implementation detail local to the Linux kernel. Where appropriate, the magic value of 1024 has been replaced with EFI_VAR_NAME_LEN, as this is used for the efi_variable struct definition. This in itself does not change any behavior, but should serve as points of interest when making future changes in the same area. A related build-time check has been added to ensure that the special 512 byte sized buffer will not overflow with a potentially decreased EFI_VAR_NAME_LEN. Signed-off-by: Tim Schumacher Signed-off-by: Ard Biesheuvel

efivarfs: Remove unused internal struct members

2024-04-13T08:33:02+00:00

The structure was moved to the efivarfs internals in commit 2d82e6227ea1 ("efi: vars: Move efivar caching layer into efivarfs") after previously being used as the data ABI for efivars until its removal in commit 0f5b2c69a4cb ("efi: vars: Remove deprecated 'efivars' sysfs interface"). As efivarfs only uses the structure for the variable name caching layer, the data-related members were never in use. Remove them to avoid implying that efivarfs is bound by the same restrictions that efivars once had. While at it, remove the packed attribute, since we no longer have to guarantee a stable layout. Signed-off-by: Tim Schumacher Signed-off-by: Ard Biesheuvel

efivarfs: Drop 'duplicates' bool parameter on efivar_init()

2024-02-25T08:43:39+00:00

The 'duplicates' bool argument is always true when efivar_init() is called from its only caller so let's just drop it instead. Signed-off-by: Ard Biesheuvel

efivarfs: Drop redundant cleanup on fill_super() failure

2024-02-25T08:43:38+00:00

Al points out that kill_sb() will be called if efivarfs_fill_super() fails and so there is no point in cleaning up the efivar entry list. Reported-by: Alexander Viro Signed-off-by: Ard Biesheuvel