GPU VulnDB

Database/Kernel, userspace & hypervisor

sudo: intercept policy checks skipped for execveat, letting allowed users run denied commands

CVE-2026-82474Kernel, userspace & hypervisorcurated

Impact

On fleets that use sudo's intercept mode (ptrace-based sub-command interception) to constrain what an operator or on-call engineer may run, a user permitted to run one command can execute programs the policy denies by invoking execveat directly or via fexecve. The bypassed action is also not logged, so the sudo audit trail no longer reflects what actually ran on the node. On a shared GPU host this matters most where intercept mode is the control that keeps a limited operator away from full root-equivalent tooling - driver reload, nvidia-smi persistence changes, container runtime configuration. Systems that only use ordinary sudoers rules without intercept/log_subcmds are not affected by this bypass.

Who can reach it

Local, authenticated user who already holds a sudoers entry permitting at least one command under intercept mode. No remote reach and no additional privilege needed beyond that existing sudo grant.

What to do

Affected through sudo 1.9.17p2; the record links an upstream commit (71fbe42dcd5a1c8f799540583a2dfb2ae6221edf) but no fixed release number is stated, so track your distribution's sudo package advisory rather than assuming a version. Upgrading the sudo package takes effect for new invocations - no daemon restart and no reboot. Until a package is available, treat intercept mode as advisory rather than a security boundary and constrain the underlying sudoers rules instead.

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.