Linux Kernel CVE-2026-98520

Exploitation requires an AMD GPU operating in SRIOV (virtual function) mode with MULTIPLE containers each opening /dev/kfd - the description states both bugs 'manifest under SRIOV with multiple containers.' The use-after-free is triggered when the first /dev/kfd opener's container exits (releasing the inode whose address_space was cached in kfd_dev_mapping) and a GPU reset subsequently calls unmap_mapping_range() on the freed inode. Limiting factors that reduce real-world risk: the attacker needs local access to the /dev/kfd device (not remote), the deployment must use AMD KFD under SRIOV with container isolation (a datacenter-GPU-virtualization-specific configuration, not a default desktop/server setup), and the dangling-pointer dereference depends on a GPU reset occurring after container teardown. Single-container or non-SRIOV deployments are not affected by the manifested bugs.

Signals point consistently to a moderate, environment-specific priority rather than a broad emergency. The provided CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N, C:H/I:H/A:H = 7.8 High) establishes a local, authenticated attack surface - not network-reachable - which already caps real-world exposure. EPSS reinforces this: 0.20% (9th percentile) indicates very low predicted exploitation probability. There is no CISA KEV listing and no exploit/PoC reference in the input (the only references are the upstream kernel.org fix commits), so exploitation status is 'no public exploit identified at time of analysis.' The vuln.today decision label is 'this_week,' consistent with a patch-promptly posture rather than act_now/emergency. The crucial contextualizing fact from the description is that both bugs 'manifest under SRIOV with multiple containers' - the dangling address_space (use-after-free / i_mmap_rwsem deadlock) and the multi-container mapping gap are only reachable in AMD GPU SRIOV virtualization deployments where multiple containers open /dev/kfd. One tension to flag explicitly: the input Tags label this 'Information Disclosure,' but the description primarily documents a use-after-free leading to an uninterruptible kernel hang (NMI panic on the GPU reset workqueue) plus stale doorbell/MMIO exposure - the dominant observed impact is availability/DoS, with information exposure as a secondary effect. CWE is N/A in the input, so the weakness classification is not independently confirmed. Net: a legitimately serious kernel UAF for the narrow set of AMD datacenter-GPU SRIOV operators, but low urgency for the general Linux population.

In an AMD GPU SRIOV deployment running multiple containers, a local user in the first container opens /dev/kfd (caching its inode's address_space) and then that container exits, freeing the inode. A later GPU reset path calls unmap_mapping_range() on the now-dangling pointer, taking i_mmap_rwsem on freed memory and hanging the reset workqueue (NMI panic); separately, mappings from other containers are never zapped, leaving doorbell/MMIO pages accessible with no GPU behind them. No public exploit code is referenced - only the upstream fix commits are provided.