GPU VulnDB

Database/Kernel, userspace & hypervisor

sudo: failed setuid/setgid/setgroups before running the mailer is non-fatal, allowing privilege escalation

CVE-2026-35535Kernel, userspace & hypervisorcurated

Impact

When sudo drops privileges before spawning its mailer, a failure of setuid(), setgid() or setgroups() is not treated as fatal, so the mailer can run with privileges it should have shed. A local user who can make those calls fail - the classic route is exhausting a process limit - gets the mailer executing at higher privilege, which the record rates as full local privilege escalation (confidentiality, integrity and availability all high). sudo is on every GPU node an operator manages, and the login nodes and interactive shells that HPC users share are exactly where untrusted local users already have a shell. Exposure depends on sudo being configured to send mail at all; a sudoers file with mailing disabled does not reach the affected path.

Who can reach it

A local user on the host with a shell and any sudoers entry that triggers the mailer. Authentication to the machine is required; no sudo rights on the target command are needed beyond whatever causes sudo to mail.

What to do

Update the sudo package to a build containing upstream commit 3e474c2 - versions through 1.9.17p2 are affected. Distribution updates are available via the Debian LTS announcement and Ubuntu tracker referenced in the record; Red Hat lists RHUI 5 and RHEL 6/7 ELS among affected products. A package update is enough - sudo is invoked fresh each time, so no reboot and no drain is needed, and running jobs are untouched. As an interim measure, disable sudo's mail options in sudoers so the vulnerable code path is not reached.

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.