CVE-2024-42123

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 vulnerable path is reached only through local GPU access — a compute job on /dev/kfd + /dev/dri/renderD* raising a per-PASID poison-consumption interrupt, or the driver's own page-retirement kthread. No network or adjacent-network input reaches amdgpu_umc_handle_bad_pages().

AC:HAttack complexity, high

Triggering requires a real uncorrectable ECC/poison event in GPU HBM and, on a later poll iteration, amdgpu_dpm_get_ecc_info() returning a value other than 0 or -EOPNOTSUPP so that neither allocation branch runs — both conditions are hardware/firmware state the attacker cannot manufacture. The ~100-iteration polling loop gives many attempts per event, but the initiating hardware fault remains outside attacker control.

PR:LPrivileges required, low

The consumption side is driven by an unprivileged userspace compute process — event_interrupt_poison_consumption_v11() dispatches on the job's PASID, and /dev/kfd and /dev/dri/renderD* are routinely granted to the render group on ML/HPC and multi-tenant GPU nodes and inside GPU containers. Root is not required (the debugfs ras_ctrl injection interface is merely a more reliable alternate route, and is itself created with world-writable S_IWUGO mode bits).

UI:NUser interaction, none

The double free happens autonomously inside the RAS interrupt handler and the amdgpu_ras_page_retirement_thread kthread once the poison event occurs. No victim action of any kind is needed.

S:UScope, unchanged

The corruption is confined to the host kernel's slab allocator, within the same security authority. The SR-IOV VF branch of amdgpu_umc_poison_handler() bypasses this code entirely, so no guest-to-host or IOMMU boundary is crossed.

C:HConfidentiality impact, high

Beyond the generic UAF read primitive from a double free, there is a concrete disclosure path: the stale err_addr is passed to amdgpu_ras_add_bad_pages() with a persisted err_addr_cnt, copying freed slab contents into con->eh_data->bps, which are then persisted to the RAS EEPROM and readable by any local user through the S_IRUGO gpu_vram_bad_pages sysfs binary attribute.

I:HIntegrity impact, high

Freeing the same kcalloc'd object twice corrupts the SLUB freelist and, if the object is reallocated between the two frees, releases a live in-use allocation — a standard route to a controlled arbitrary-write primitive. The stale-pointer data additionally drives amdgpu_vram_mgr_reserve_range() and permanent RAS EEPROM writes with garbage retired-page addresses.

A:HAvailability impact, high

With CONFIG_SLAB_FREELIST_HARDENED or SLUB debug the double free is detected and panics/BUGs immediately; without it the resulting freelist corruption and use-after-free crash the kernel. Either way the outcome is a full denial of service, compounded by the mode-2 GPU reset already in flight on this path.