Linux Kernel CVE-2026-74403

Exploitation requires a local account with at minimum low-privilege user rights (PR:L per provided CVSS vector). The target host must be equipped with AMD SEV-SNP capable hardware (AMD EPYC processors supporting SNP) and have the Linux kernel CCP driver active, as the vulnerable function __snp_alloc_firmware_pages() is only invoked during SNP Trusted I/O firmware initialization. Additionally, the attacker must induce memory pressure sufficient to cause the firmware page allocation to fail - this is not the default system state and requires the ability to consume kernel memory (achievable by an unprivileged local user but adds setup complexity). Systems built with HASHED_PAGE_VIRTUAL are not vulnerable because page_address(NULL) returns NULL correctly in that configuration. Non-AMD systems, systems without the CCP driver, and patched kernels (7.1.5+, 7.2-rc1+, 6.19+) are not affected.

The NVD CVSS 3.1 score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) correctly models local, low-privilege access with full kernel impact, but overstates ease of exploitation in practice. Reliably triggering the bug requires engineering sufficient memory pressure to cause __snp_alloc_firmware_pages() to fail - an attacker must first exhaust available kernel pages, which adds meaningful setup complexity not captured in AC:L. EPSS at 0.16% (5th percentile) strongly signals this has not attracted exploiter interest, and the absence from CISA KEV confirms no confirmed in-the-wild exploitation. The vulnerable code path is further gated behind AMD SEV-SNP hardware and an active CCP driver, limiting exposure to AMD EPYC-based confidential computing deployments rather than general Linux systems. For operators of SEV-SNP infrastructure the risk is materially higher due to elevated privilege on those hosts; for standard Linux deployments without AMD confidential computing hardware this is low practical priority. CVSS and EPSS signals are not conflicting - high CVSS correctly flags worst-case kernel impact; low EPSS correctly flags limited exploitation viability at scale.

A local attacker with a standard user account on an AMD EPYC host running an unpatched kernel with SEV-SNP support allocates large memory blocks to exhaust available page frames, then triggers the SEV-SNP TIO firmware initialization code path. With pages exhausted, __snp_alloc_firmware_pages() returns NULL; page_address(NULL) returns a non-NULL garbage virtual address that bypasses the tio_status guard; sev_tsm_init_locked() dereferences the invalid pointer, leading to kernel memory corruption, a system panic, or - under favorable heap layout - potential privilege escalation. No public POC exists at time of analysis.