Bug 2265797 (CVE-2023-52463)

Summary: CVE-2023-52463 kernel: efivarfs: force RO when remounting if SetVariable is not supported
Product: [Other] Security Response Reporter: Patrick Del Bello <pdelbell>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: acaringi, allarkin, aquini, bhu, chwhite, cye, cyin, dbohanno, debarbos, dfreiber, drow, dvlasenk, esandeen, ezulian, hkrzesin, jarod, jburrell, jdenham, jfaracco, jforbes, jlelli, joe.lawrence, jshortt, jstancek, jwyatt, kcarcia, kyoshida, ldoskova, lgoncalv, lzampier, mleitner, mmilgram, mstowell, nmurray, ptalbert, rparrazo, rrobaina, rvrbovsk, rysulliv, scweaver, sukulkar, tglozar, tyberry, vkumar, wcosta, williams, wmealing, ycote, ykopkova, zhijwang
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: kernel 6.8-rc1 Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in the Linux kernel, which involves the improper handling of the efivarfs filesystem when the firmware does not support the SetVariable function at runtime. Specifically, even if efivarfs is initially mounted as read-only (RO), it can be remounted as read-write (RW) without checking if the firmware can handle variable updates. This issue allows operations such as efi-updatevar to be executed, which leads to a crash due to a NULL pointer dereference. This crash occurs because the callback for SetVariable is not assigned, causing a level 0 translation fault.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2265809    
Bug Blocks: 2265790    

Description Patrick Del Bello 2024-02-24 11:20:13 UTC 
If SetVariable at runtime is not supported by the firmware we never assign
a callback for that function. At the same time mount the efivarfs as
RO so no one can call that.  However, we never check the permission flags
when someone remounts the filesystem as RW. As a result this leads to a
crash looking like this:

$ mount -o remount,rw /sys/firmware/efi/efivars
$ efi-updatevar -f PK.auth PK

[  303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[  303.280482] Mem abort info:
[  303.280854]   ESR = 0x0000000086000004
[  303.281338]   EC = 0x21: IABT (current EL), IL = 32 bits
[  303.282016]   SET = 0, FnV = 0
[  303.282414]   EA = 0, S1PTW = 0
[  303.282821]   FSC = 0x04: level 0 translation fault
[  303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000
[  303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
[  303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP
[  303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6
[  303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1
[  303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023
[  303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  303.292123] pc : 0x0
[  303.292443] lr : efivar_set_variable_locked+0x74/0xec
[  303.293156] sp : ffff800008673c10
[  303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000
[  303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027
[  303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000
[  303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000
[  303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54
[  303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4
[  303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002
[  303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201
[  303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc
[  303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000
[  303.303341] Call trace:
[  303.303679]  0x0
[  303.303938]  efivar_entry_set_get_size+0x98/0x16c
[  303.304585]  efivarfs_file_write+0xd0/0x1a4
[  303.305148]  vfs_write+0xc4/0x2e4
[  303.305601]  ksys_write+0x70/0x104
[  303.306073]  __arm64_sys_write+0x1c/0x28
[  303.306622]  invoke_syscall+0x48/0x114
[  303.307156]  el0_svc_common.constprop.0+0x44/0xec
[  303.307803]  do_el0_svc+0x38/0x98
[  303.308268]  el0_svc+0x2c/0x84
[  303.308702]  el0t_64_sync_handler+0xf4/0x120
[  303.309293]  el0t_64_sync+0x190/0x194
[  303.309794] Code: ???????? ???????? ???????? ???????? (????????)
[  303.310612] ---[ end trace 0000000000000000 ]---

Fix this by adding a .reconfigure() function to the fs operations which
we can use to check the requested flags and deny anything that's not RO
if the firmware doesn't implement SetVariable at runtime.
Comment 1 Patrick Del Bello 2024-02-24 11:26:50 UTC 
Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 2265809]
Comment 3 Justin M. Forbes 2024-02-27 00:06:17 UTC 
	Issue introduced in 5.8 with commit f88814cc2578 and fixed in 5.10.209 with commit 94c742324ed7
	Issue introduced in 5.8 with commit f88814cc2578 and fixed in 5.15.148 with commit 2aa141f8bc58
	Issue introduced in 5.8 with commit f88814cc2578 and fixed in 6.1.75 with commit d4a9aa7db574
	Issue introduced in 5.8 with commit f88814cc2578 and fixed in 6.6.14 with commit 0049fe7e4a85
	Issue introduced in 5.8 with commit f88814cc2578 and fixed in 6.7.2 with commit d4a714873db0
	Issue introduced in 5.8 with commit f88814cc2578 and fixed in 6.8-rc1 with commit 0e8d2444168d
Comment 4 Justin M. Forbes 2024-02-27 00:06:43 UTC 
This was fixed for Fedora with the 6.6.14 stable kernel updates.
Comment 7 Alex 2024-06-09 15:15:41 UTC 
The result of automatic check (that is developed by Alexander Larkin) for this CVE-2023-52463 is: CHECK	Maybe valid. Check manually. with impact MODERATE (that is approximation based on flags DANGER NULLPTR DISK INIT IMPROVEONLY  ; these flags parsed automatically based on patche data). Such automatic check happens only for Low/Moderates (and only when not from reporter, but parsing already existing CVE). Highs always checked manually (I check it myself and then we check it again in Remediation team). In rare cases some of the Moderates could be increased to High later.
Comment 13 errata-xmlrpc 2024-08-08 04:40:18 UTC 
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2024:5102 https://access.redhat.com/errata/RHSA-2024:5102
Comment 14 errata-xmlrpc 2024-08-08 04:52:06 UTC 
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2024:5101 https://access.redhat.com/errata/RHSA-2024:5101
Comment 15 errata-xmlrpc 2024-08-21 00:14:51 UTC 
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.2 Extended Update Support

Via RHSA-2024:5673 https://access.redhat.com/errata/RHSA-2024:5673
Comment 16 errata-xmlrpc 2024-08-21 00:26:11 UTC 
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.2 Extended Update Support

Via RHSA-2024:5672 https://access.redhat.com/errata/RHSA-2024:5672
Comment 17 errata-xmlrpc 2024-09-11 00:56:50 UTC 
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2024:6567 https://access.redhat.com/errata/RHSA-2024:6567