CVE-2026-80652 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp - Treat zero-length cert chain as query for blob lengths
When handling a PDH export, treat a zero-length userspace cert chain buffer as a request to query the length of the relevant blobs. Failure to account for the zero-length buffer trips a BUG_ON() when running with CONFIG_DEBUG_VIRTUAL=y due to trying to get the physical address of the ZERO_SIZE_PTR (returned by kzalloc() on the bogus allocation).
kernel BUG at arch/x86/mm/physaddr.c:28 ! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 30 UID: 0 PID: 28580 Comm: syz.2.18 Kdump: loaded Tainted: G W 6.18.16-smp-DEV #1 NONE Tainted: [W]=WARN
Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 RIP: 0010:__phys_addr+0x16a/0x180 arch/x86/mm/physaddr.c:28 RSP: 0018:ffffc9008329fc80 EFLAGS: 00010293 RAX: ffffffff8179110a RBX: 0000778000000010 RCX: ffff8884e6992600 RDX: 0000000000000000 RSI: 0000000080000010 RDI: 0000778000000010 RBP: ffffc9008329fdf0 R08: 0000000000000dc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff126d297 R12: dffffc0000000000 R13: 1ffff92010653fc8 R14: 0000000080000010 R15: dffffc0000000000 FS: 0000555556bec9c0(0000) GS:ffff88aa4ce1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd3159e7000 CR3: 00000004fbc44000 CR4: 0000000000350ef0 Call Trace: <TASK> [<ffffffff853d3869>] sev_ioctl_do_pdh_export+0x559/0x7a0 drivers/crypto/ccp/sev-dev.c:2308
[<ffffffff853d1fdd>] sev_ioctl+0x2cd/0x480 drivers/crypto/ccp/sev-dev.c:2556
[<ffffffff82549ebc>] vfs_ioctl fs/ioctl.c:52 [inline]
[<ffffffff82549ebc>] __do_sys_ioctl fs/ioctl.c:598 [inline]
[<ffffffff82549ebc>] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:584
[<ffffffff8630115f>] do_syscall_x64 arch/x86/entry/syscall_64.c:64 [inline]
[<ffffffff8630115f>] do_syscall_64+0x9f/0xf40 arch/x86/entry/syscall_64.c:98
[<ffffffff81000136>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7fd3158eac39 </TASK>
Thankfully, the bug is benign outside of CONFIG_DEBUG_VIRTUAL=y as getting the physical address is just arithmetic, and the PSP errors out before trying to write to the garbage address (which it must, otherwise querying the blob lengths would clobber memory at pfn=0).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability resides within the AMD Secure Encrypted Virtualization driver in the Linux kernel, specifically affecting the handling of Platform Development Key export operations. The core issue is a logic error in how the crypto: ccp subsystem processes user-supplied certificate chain buffers during PDH (Platform Health Document) exports. When an application provides a zero-length buffer for the certificate chain, the kernel incorrectly interprets this as a standard allocation request rather than recognizing it as a specific control signal to query blob lengths. This misinterpretation triggers an invalid memory access path that can lead to system instability or crashes under certain configuration conditions.
From a technical perspective, the flaw stems from insufficient validation of buffer sizes before invoking kzalloc for zero-length allocations. In Linux kernel development, allocating zero bytes typically returns a special pointer known as ZERO_SIZE_PTR rather than NULL. While this optimization is generally safe because no actual memory write occurs, it becomes problematic when subsequent code attempts to derive physical addresses from this pointer. The function __phys_addr, which converts virtual addresses to physical ones, does not handle the ZERO_SIZE_PTR correctly in all contexts, particularly when CONFIG_DEBUG_VIRTUAL is enabled. This configuration option adds extensive sanity checks for kernel address usage, and encountering an invalid base like ZERO_SIZE_PTR causes a BUG_ON assertion failure, resulting in a kernel panic or oops as evidenced by the provided stack trace showing execution halting at arch/x86/mm/physaddr.c:28.
The operational impact of this vulnerability is primarily localized to systems running with CONFIG_DEBUG_VIRTUAL=y, which are typically development or testing kernels rather than production deployments. In such environments, an unprivileged user can trigger a denial-of-service condition by sending a crafted ioctl request that results in the aforementioned kernel bug check failure. However, on standard production kernels without debug virtual address checking enabled, the vulnerability is considered benign. The underlying arithmetic operation to calculate physical addresses remains valid even if based on incorrect pointers, and the Secure Processor hardware itself validates inputs before writing data, preventing actual memory corruption or arbitrary code execution at pfn=0. Nevertheless, the potential for local denial of service through kernel panic constitutes a significant security risk in debug environments where stability is paramount for development workflows.
This issue aligns with CWE-252: Unchecked Return Value and CWE-476: NULL Pointer Dereference concepts, as it involves failing to properly validate input parameters before proceeding with memory operations that assume valid allocations. From an ATT&CK perspective, this represents a Local Privilege Escalation vector via Denial of Service against the kernel subsystem, specifically leveraging improper handling of API inputs within system calls. The attack path involves interacting with /dev/sev devices through ioctl interfaces to trigger the faulty code path in sev_ioctl_do_pdh_export.
Mitigation strategies focus on applying the upstream kernel patch that explicitly checks for zero-length buffers and treats them as requests to query blob lengths rather than attempting memory allocation. Administrators should ensure their systems are updated with the latest stable Linux kernel versions containing this fix. For environments where CONFIG_DEBUG_VIRTUAL is enabled, immediate patching is critical to prevent accidental system crashes during development or testing activities. Additionally, developers interacting with AMD SEV APIs should implement robust input validation on the client side to avoid sending malformed buffer sizes that trigger these edge cases in the driver logic.