In the Linux kernel, the following vulnerability has been resolved:
arm64: gcs: Do not set PTE_SHARED on GCS mappings if FEAT_LPA2 is enabled
When FEAT_LPA2 is enabled, bits 8-9 of the PTE replace the
shareability attribute with bits 50-51 of the output address. The
_PAGE_GCS{,_RO} definitions include the PTE_SHARED bits as 0b11 (this
matches the other _PAGE_* definitions) but using this macro directly
leads to the following panic when enabling GCS on a system/model with
LPA2:
Unable to handle kernel paging request at virtual address fffff1ffc32d8008
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
swapper pgtable: 4k pages, 52-bit VAs, pgdp=0000000060f4d000
[fffff1ffc32d8008] pgd=100000006184b003, p4d=0000000000000000
Internal error: Oops: 0000000096000004 [#1] SMP
CPU: 0 UID: 0 PID: 513 Comm: gcs_write_fault Tainted: G M 7.0.0-rc1 #1 PREEMPT
Tainted: [M]=MACHINE_CHECK
Hardware name: QEMU QEMU Virtual Machine, BIOS 2025.02-8+deb13u1 11/08/2025
pstate: 03402005 (nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : zap_huge_pmd+0x168/0x468
lr : zap_huge_pmd+0x2c/0x468
sp : ffff800080beb660
x29: ffff800080beb660 x28: fff00000c2058180 x27: ffff800080beb898
x26: fff00000c2058180 x25: ffff800080beb820 x24: 00c800010b600f41
x23: ffffc1ffc30af1a8 x22: fff00000c2058180 x21: 0000ffff8dc00000
x20: fff00000c2bc6370 x19: ffff800080beb898 x18: ffff800080bebb60
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000007
x14: 000000000000000a x13: 0000aaaacbbbffff x12: 0000000000000000
x11: 0000ffff8ddfffff x10: 00000000000001fe x9 : 0000ffff8ddfffff
x8 : 0000ffff8de00000 x7 : 0000ffff8da00000 x6 : fff00000c2bc6370
x5 : 0000ffff8da00000 x4 : 000000010b600000 x3 : ffffc1ffc0000000
x2 : fff00000c2058180 x1 : fffff1ffc32d8000 x0 : 000000c00010b600
Call trace:
zap_huge_pmd+0x168/0x468 (P)
unmap_page_range+0xd70/0x1560
unmap_single_vma+0x48/0x80
unmap_vmas+0x90/0x180
unmap_region+0x88/0xe4
vms_complete_munmap_vmas+0xf8/0x1e0
do_vmi_align_munmap+0x158/0x180
do_vmi_munmap+0xac/0x160
__vm_munmap+0xb0/0x138
vm_munmap+0x14/0x20
gcs_free+0x70/0x80
mm_release+0x1c/0xc8
exit_mm_release+0x28/0x38
do_exit+0x190/0x8ec
do_group_exit+0x34/0x90
get_signal+0x794/0x858
arch_do_signal_or_restart+0x11c/0x3e0
exit_to_user_mode_loop+0x10c/0x17c
el0_da+0x8c/0x9c
el0t_64_sync_handler+0xd0/0xf0
el0t_64_sync+0x198/0x19c
Code: aa1603e2 d34cfc00 cb813001 8b011861 (f9400420)
Similarly to how the kernel handles protection_map[], use a
gcs_page_prot variable to store the protection bits and clear PTE_SHARED
if LPA2 is enabled.
Also remove the unused PAGE_GCS{,_RO} macros.
What the EG score is made of (scorer v4.0: the three questions the 0–10 score mixes, published apart · methodology)
The EG score (5.5): severity, escalated by confirmed exploitation. This CVE's 5.5 is its impact severity (EG Severity), not escalated.
- EG Severity
- 5.5 MEDIUMCVSS-B, impact only: no KEV listing, EPSS or EG-KEV tier raises it.GitHub Security Advisory CVSS
- EG Likelihood
- 0.1% within 30 daysSource: FIRST EPSS (model v2026.06.15, score date 2026-10-24). FIRST's exploitation probability, not an EchelonGraph model.
- Confirmed exploitation
- None on record (CISA KEV, EG-KEV Tier 1)Reported apart from the likelihood: an observed fact, not a probability.
- EG Priority
- SSVC Track at medium mission impactTrack at low or medium mission impact; Track* at high (mission-essential systems).CISA BOD 26-04: 14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.Each input and its source, and whom BOD 26-04 binds: the SSVC and BOD 26-04 blocks below.
SSVC (CISA's decision table, applied by EchelonGraph)Track at low or medium mission impact; Track* at high (mission-essential systems).
A fix is available. Apply it within your standard update timelines.
Exploitation none (no CISA value, KEV listing or exploit code on record) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). EchelonGraph holds no SSVC assessment of this CVE from CISA: none of these inputs is from Vulnrichment. EchelonGraph applied CISA's decision table to them; CISA publishes SSVC inputs and the table, not a decision for each CVE. Mission impact is CISA's Mission & Well-being decision point, and only you can judge it. CISA's table makes it high when Mission Prevalence is Essential — the vulnerable component "directly provides capabilities that constitute at least one MEF for at least one entity" (MEF: mission essential function) — or when Public Well-Being Impact is Irreversible: "multiple fatalities are likely", the cyber-physical system "is likely lost or destroyed", "extreme or serious externalities" are imposed on other parties, or social systems such as elections or the financial grid "are destabilized and potentially collapse". CISA's decision table
BOD 26-04 (CISA's remediation timeline, Table 1)14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.
The score's inputs: In CISA KEV no (CISA's KEV catalog) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). Where an input reads “CISA's BOD 26-04 default”, no one has published it for this CVE, and CISA's implementation guidance says: “If “Automatable” and “Technical Impact” information items about a CVE ID are not available and the CVE ID is not in the KEV Catalog, CISA will treat its values as “no” and “total,” respectively, until CISA or a third party provides metadata about the CVE ID. CISA will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog.” Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it