GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel AMD LBR: user-only branch sampling leaks kernel addresses to unprivileged users

CVE-2026-80602Kernel, userspace & hypervisorcurated

Impact

On AMD processors with LBR v2 the hardware branch filter only checks the privilege level of the branch target, so a branch stack requested with PERF_SAMPLE_BRANCH_USER still returns SYSRET/ERET records whose branch-from address is in kernel text. An unprivileged local user who can run perf branch sampling reads back raw kernel text addresses, which defeats KASLR and gives a reliable base for a follow-on privilege escalation exploit. On a GPU node this matters where tenants get real shell access on the host or in a privileged container: EPYC hosts are the standard head for MI300 and H100/H200 nodes, and KASLR is often the only thing standing between a local bug and root on a box shared by several jobs. This is an information disclosure only - it does not by itself give code execution.

Who can reach it

Local unprivileged user on an AMD host with X86_FEATURE_AMD_LBR_V2, able to open perf events with branch-stack sampling (kernel.perf_event_paranoid permissive enough, and perf_event_open reachable from the container's seccomp profile). No special privilege beyond that.

What to do

Take the stable kernel fix and reboot each affected AMD node; this is a kernel text change with no runtime knob, so it costs a drain and reboot per host. Until the reboot window, raise kernel.perf_event_paranoid (2 or 3) and block perf_event_open in container seccomp profiles so tenants cannot request branch stacks at all. The record lists stable commits only and names no distro-fixed version - check your vendor's kernel errata for the exact build.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.