CVE-2026-90383

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

The attacker supplies the faulting VA by writing a virtual-mode GRU vload/vstore/bcopy into the mmap'd GSEG on /dev/gru. gru_fault loads the context; the miss is handled by gru_intr (default GRU_OPT_MISS_FMM_INTR) or ioctl GRU_USER_CALL_OS (gru_handle_user_call_os), both of which called atomic_pte_lookup on that missvaddr.

AC:LAttack complexity, low

gru_create_new_context defaults to GRU_OPT_MISS_FMM_INTR, so a mapped-mode GRU instruction reliably hits gru_intr, which mmap_read_trylocks gts->ts_mm and runs atomic_pte_lookup. A 1GB hugetlb VMA is mis-walked with no race because pud_leaf is never checked; a second thread of the same process can also madvise/unmap during the unlocked walk.

PR:LPrivileges required, low

gru_fops has no .open method and gru_file_mmap/gru_file_unlocked_ioctl do not call capable(). An unprivileged process that can open miscdevice "gru" (/dev/gru) can mmap the GSEG, ioctl GRU_CREATE_CONTEXT, and issue GRU instructions that reach atomic_pte_lookup; only gru_unload_all_contexts requires CAP_SYS_ADMIN.

UI:NUser interaction, none

The attacker alone opens /dev/gru, maps the GSEG, calls GRU_CREATE_CONTEXT, and issues the GRU instruction or GRU_USER_CALL_OS ioctl; no other user needs to act.

S:UScope, unchanged

atomic_pte_lookup feeds a GPA to tfh_write_restart on the host GRU chiplet. A bad PFN lets GRU DMA into host kernel or other-process memory, which is privilege escalation in the same kernel authority, not a guest-to-host or IOMMU-domain crossing.

C:HConfidentiality impact, high

atomic_pte_lookup never tests pud_leaf, so pud_pgtable() on a 1GB hugetlb leaf treats attacker-controlled hugepage bytes as PMD/PTE entries. pte_pfn of that crafted entry is installed by tfh_write_restart, and gru_vload/bcopy then reads that physical page into the attacker-mapped GSEG. The walk also never pins the page, so a stale PFN can be read after reuse.

I:HIntegrity impact, high

gru_vstore, gru_bcopy, and AMO opcodes write through the GRU TLB entry programmed by tfh_write_restart. A PFN taken from the pud_leaf miswalk of attacker-controlled 1GB hugepage contents, or from an unpinned PTE reused after free, is therefore an arbitrary physical write.

A:HAvailability impact, high

pte_offset_kernel() on a pud_leaf 1GB mapping (or on a PMD that is not a table) computes __va of a non-page-table PFN and dereferences it in gru_intr/atomic_pte_lookup, oopsing the kernel. GRU DMA through a stale unpinned PFN can also panic.