CVE-2021-4034 PwnKit Explained: Linux Root Privilege Escalation, Detection, and Fixes

CVE-2021-4034, widely known as PwnKit, is one of the most consequential Linux local privilege escalation vulnerabilities disclosed in the past decade. The flaw affects pkexec, a privileged executable belonging to the Polkit authorization framework, and allows an unprivileged local attacker to gain root access on vulnerable Linux systems. What makes PwnKit particularly significant is that the affected utility was installed by default on many major Linux distributions, creating a broad attack surface even on systems where administrators had never explicitly configured or used pkexec.

The vulnerability was publicly disclosed on January 25, 2022, following research by the Qualys Research Team. Although assigned a CVSS v3.1 score of 7.8, categorized as High severity, its practical implications extend beyond the numerical rating. An attacker who has already compromised an application account, obtained a low-privilege shell, or gained access to a shared Linux system may be able to use PwnKit to cross the boundary between ordinary user privileges and complete administrative control. The National Vulnerability Database confirms the local privilege escalation behavior, while the original Qualys technical advisory documents the underlying memory-safety failure.

PwnKit is not a newly discovered zero-day in 2026. Vendor patches have been available since January 2022. Nevertheless, understanding CVE-2021-4034 remains valuable for administrators managing legacy systems, security engineers validating Linux privilege boundaries, and incident responders investigating potentially compromised hosts. The central question today is not simply whether an exploit exists, but whether a particular Linux environment still contains the vulnerable execution path and whether an attacker could have used it to turn an existing foothold into root access.

What Is CVE-2021-4034?

CVE-2021-4034 is a local privilege escalation vulnerability in the pkexec program distributed with Polkit, formerly known as PolicyKit. Polkit provides an authorization framework that enables unprivileged processes to request controlled privileged operations. The pkexec executable is one mechanism within that framework, allowing authorized users to execute programs under another user’s identity, commonly root.

Unlike an ordinary executable, pkexec traditionally runs with the set-user-ID (SUID) permission bit enabled. This means the program can execute with the effective privileges of its owner, typically root, even when launched by an unprivileged user. That behavior is intentional, but it makes correct validation of command-line arguments, environment variables, and authorization state essential.

The vulnerability occurs because affected implementations fail to handle an unusual argument vector correctly. Under certain conditions, this causes out-of-bounds memory access and allows attacker-controlled environment data to influence privileged execution. Qualys demonstrated that the resulting primitive could be used to execute arbitrary code with root privileges, bypassing the authentication and policy checks that pkexec would normally enforce.

속성	CVE-2021-4034 details
CVE identifier	CVE-2021-4034
Common name	PwnKit
영향을 받는 구성 요소	Polkit pkexec
취약점 유형	Local privilege escalation
Technical root cause	Improper argument vector validation and out-of-bounds memory access
CVSS v3.1	7.8 — High
공격 벡터	Local
Required privileges	낮음
사용자 상호 작용	없음
Potential impact	Arbitrary code execution as root
Public disclosure	January 25, 2022
Known exploited status	Added to CISA KEV in June 2022
해결 방법	Install the distribution’s patched Polkit package

The CVSS vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Its local attack vector is an important qualification: PwnKit does not, by itself, provide an unauthenticated remote entry point. However, its low attack complexity and potentially complete impact on confidentiality, integrity, and availability make it a serious vulnerability whenever an attacker can already execute code locally.

How Polkit and pkexec Work on Linux

Understanding the PwnKit vulnerability requires distinguishing Polkit’s authorization framework from the privileged executable at the center of the exploit.

Polkit provides a structured way for unprivileged applications to request actions that require elevated permissions. On a typical Linux workstation, an ordinary user may need to modify system settings, manage certain devices, or invoke administrative functionality without operating every application as root. Polkit allows these requests to be evaluated against system authorization policies.

그리고 pkexec utility provides command execution under this authorization model. For example, a system administrator might legitimately invoke a program using:

pkexec /usr/bin/id

On a correctly configured system, the operation is subject to applicable Polkit authorization rules and may require authentication. The existence of pkexec does not normally mean that any user can execute an arbitrary program as root without authorization.

The security-sensitive behavior comes from the SUID permission model. A typical privileged installation might display permissions resembling:

-rwsr-xr-x 1 root root ... /usr/bin/pkexec

그리고 s in the owner’s execute position indicates the SUID bit. When the executable is launched, its effective user identity can become that of the file owner rather than the invoking user. This is a legitimate Unix privilege mechanism, but it creates an especially dangerous trust boundary if the program mishandles input before completing its authorization checks.

PwnKit exploited exactly this kind of boundary. A flaw in early argument processing could be reached before pkexec had established the expected safe execution state. As a result, malicious data influenced privileged program behavior without the attacker successfully completing the normal authentication workflow.

An important technical detail from the original Qualys investigation is that the vulnerability could be exploited even when the Polkit daemon itself was not running. The vulnerable behavior existed inside the SUID executable, so disabling a related background service was not equivalent to removing the vulnerable attack surface.

The Technical Root Cause of CVE-2021-4034

The PwnKit vulnerability originates in how pkexec processes command-line arguments supplied through the execve() system call.

In a normal process execution, arguments are represented by the argc count and the argv array, while environment variables are supplied through envp. A conventional program starts with at least an argument identifying the executable. However, the original vulnerable implementation did not properly reject a process invocation with an empty argument vector.

The original source code assumed that a relevant command argument could be found at a position in argv. When argc was zero, that assumption became invalid. The processing logic could read from argv[1] despite that location being outside the legitimate argument array.

The problem was more consequential than an ordinary invalid read because of how the argument and environment pointer arrays were arranged in the process memory layout analyzed by Qualys. Under the vulnerable conditions, accessing argv[1] could effectively access envp[0], the first environment pointer. Later program logic could also write through that invalid argument position, modifying an environment pointer that should not have been writable through the argument array.

This created an unusual but powerful exploitation primitive: attacker-controlled environment data could be reintroduced into a privileged process after the system’s normal secure-execution handling had removed sensitive environment variables.

The original Qualys analysis of PwnKit identifies both the out-of-bounds read and the subsequent out-of-bounds write. The weakness is therefore better understood as a specific memory-safety and trust-boundary failure, rather than a generic authorization policy misconfiguration.

Why environment variables matter

Environment variables influence how programs locate executables, load libraries, select language settings, and interact with system resources. In ordinary applications, that flexibility is useful. Inside a SUID-root executable, however, environment-driven behavior can become dangerous if untrusted values reach functionality that loads or executes code.

The Linux dynamic loader already recognizes this risk and restricts certain environment variables when handling privileged execution. Variables capable of affecting dynamic library loading are particularly sensitive because they can change the code executed by a process.

PwnKit undermined this protection by manipulating process memory after the initial secure-execution filtering had occurred.

In the exploit path described by Qualys, the attacker abuses the interaction between pkexec environment handling and GLib’s character-set conversion behavior. The environment variable GCONV_PATH, associated with glibc character-set conversion module discovery, becomes relevant because improperly controlled conversion paths can influence which shared libraries are loaded.

When the vulnerable program reaches the appropriate error-handling and character-conversion paths, an attacker-controlled module can be loaded into the privileged process. Since pkexec is executing with elevated privileges, the injected code can inherit root-level execution authority.

The important security principle is that filtering dangerous environment variables at process startup does not protect a privileged executable if later memory corruption can reintroduce equivalent attacker-controlled state. PwnKit combined a malformed argument vector, an out-of-bounds write, and an environment-dependent library-loading mechanism to cross that boundary.

How the PwnKit Privilege Escalation Attack Works

The publicly documented exploitation mechanism can be understood as a sequence of trust-boundary failures without executing an exploit against a production host.

First, the attacker needs the ability to execute a process locally as an unprivileged user on a vulnerable Linux system. This access might come from a legitimate low-permission account or an earlier compromise involving a service, application, or remote-access credential. The original vulnerability does not itself provide that initial access.

Next, the attacker invokes the affected pkexec executable under abnormal argument conditions. Because the vulnerable implementation does not validate the argument count correctly, its processing logic interprets memory outside the expected argument array.

The resulting out-of-bounds access creates an opportunity to influence the process environment. A carefully constructed environment can then cause privileged code paths to consume attacker-controlled values that should not be trusted during SUID execution.

Finally, the attacker reaches a code-loading mechanism that allows arbitrary code to execute with the effective privileges of the vulnerable process. In the demonstrated PwnKit scenario, that means obtaining root privileges.

Conceptual attack chain

Low-privilege local executionExisting shell, user session, or compromised service account

Malformed pkexec invocationUnexpected argument count reaches vulnerable processing

Out-of-bounds environment manipulationPrivileged process environment becomes attacker-influenced

Privileged code loadingUnsafe environment state affects library-loading behavior

Root privilege escalationPotential arbitrary code execution as root

Figure: High-level CVE-2021-4034 exploitation sequence, based on the Qualys disclosure.

The practical consequence is much greater than executing a single administrative command. Root-level access can potentially permit an attacker to inspect protected files, extract secrets, alter service configurations, establish persistence, tamper with security instrumentation, or access data belonging to other users.

Nevertheless, the exact impact depends on the execution environment. Obtaining root inside a restricted container is not automatically equivalent to obtaining root on the underlying host. Namespace isolation, filesystem mounts, capabilities, and other security controls can affect the resulting privileges. Organizations should assess the privileges actually reachable in their environment rather than automatically treating every container-level compromise as a host escape.

The public disclosure also established that PwnKit was not merely a hypothetical vulnerability. Qualys demonstrated exploitation against representative Ubuntu, Debian, Fedora, and CentOS installations, and public exploit implementations subsequently became available. Those facts make the flaw relevant to both vulnerability management and post-compromise threat modeling.

Which Linux Distributions Are Affected by CVE-2021-4034?

PwnKit affected historical Polkit implementations across many major Linux distributions. The vulnerability existed in pkexec code dating back to its introduction in 2009, long before the coordinated public disclosure in January 2022.

Qualys demonstrated the flaw on several mainstream distributions, while vendors including Canonical, Red Hat, and Debian published patches and security notices. A vulnerable package may remain present on an older system that has not received the relevant security update, but the mere presence of Polkit does not establish vulnerability.

The following table contains historical vendor-fixed package versions for representative releases:

Distribution	Fixed package version	Vendor information
Ubuntu 18.04 LTS	0.105-20ubuntu0.18.04.6	USN-5252-1
Ubuntu 20.04 LTS	0.105-26ubuntu1.2	USN-5252-1
Ubuntu 21.10	0.105-31ubuntu0.1	USN-5252-1
Debian 10 Buster	0.105-25+deb10u1	DSA-5059-1
Debian 11 Bullseye	0.105-31+deb11u1	DSA-5059-1

These versions are drawn from Canonical’s USN-5252-1 security notice 및 Debian Security Tracker. They are historical remediation thresholds for the specified releases, not a universal list of safe Polkit versions for every Linux system.

Red Hat also issued fixes for affected RHEL release streams in January and February 2022. Administrators should use the Red Hat CVE-2021-4034 advisory to determine the correct erratum and package status for their particular product and maintenance channel.

One especially important complication is that Linux vendors frequently backport security fixes without adopting the newest upstream package version. An older-looking package version may already contain the relevant correction, whereas a locally compiled or unsupported package could remain vulnerable despite having an apparently newer version string.

This is why comparing version numbers across different distributions is unreliable. Vulnerability determination must account for the Linux release, package build, vendor security patches, and the actual installed executable.

By 2026, mainstream maintained Linux distributions generally include fixes for PwnKit, but legacy images, abandoned appliances, disconnected servers, unmaintained build environments, and manually deployed executables still require verification. Older operating systems that have reached the end of their normal support lifecycle deserve particular attention because access to security updates may depend on extended-support arrangements.

How to Check for CVE-2021-4034 Without Running an Exploit

A production vulnerability assessment should establish whether the affected executable is present, whether it can run with elevated privileges, and whether its installed package contains the security fix. None of these checks requires launching a publicly available privilege escalation exploit.

Step 1: Identify the Linux distribution

Run the following command on the system being assessed:

cat /etc/os-release

This provides the distribution identity and release information needed to interpret vendor package advisories correctly. A package version is meaningful only when compared with the correct distribution release and security update channel.

Step 2: Locate the pkexec executable

Check whether pkexec is available through the system’s executable search path:

command -v pkexec

On a typical installation, the executable may be located at /usr/bin/pkexec. If the command returns nothing, that indicates the executable was not found through the current PATH; it does not prove that no copy exists elsewhere on the filesystem.

For a known path, examine the ownership and permissions:

stat -c '%n %A %a %U:%G' /usr/bin/pkexec

A traditional SUID-root installation may show permission mode 4755, represented with an s in the owner’s execute position. This indicates a privileged execution surface, but it is not proof that the executable contains the PwnKit vulnerability.

A patched pkexec may still legitimately use SUID-root permissions. The critical distinction is whether the installed implementation has received the corrected argument-processing logic.

Step 3: Check installed Polkit packages

On Ubuntu or Debian, the package names vary across distribution generations. The following command queries two commonly relevant names without changing the system:

dpkg-query -W \
  -f='${binary:Package} ${Version}\n' \
  policykit-1 polkitd 2>/dev/null

On RHEL-compatible systems, use:

rpm -q polkit

These commands provide inventory evidence. The returned package version must then be compared against the applicable vendor advisory, including any distribution-specific security backports.

사용 pkexec --version alone is insufficient for this purpose because it may not expose the full distribution package revision or security patch history.

Step 4: Determine whether the system is actually vulnerable

An accurate assessment combines package ownership, installed version, SUID configuration, and authoritative vendor status. If the binary is not managed by the system package manager, additional verification may be required to establish its origin and patch state.

A reliable finding should also distinguish between a vulnerable package, a potentially reachable SUID execution path, and demonstrated exploitation. Those are different evidence categories. Treating all three as interchangeable can lead to incorrect vulnerability reports, wasted remediation effort, and false confidence after patching.

For enterprise fleets, the strongest practice is to inventory Linux hosts centrally, map each installed package to its vendor advisory, and preserve evidence showing that the relevant fixed build was deployed successfully.

How to Fix CVE-2021-4034 on Ubuntu and Debian

The recommended solution is to install a Polkit package containing the vendor’s security fix. The specific package and available update depend on the release and its support status.

For supported Ubuntu and Debian systems, a general security-update workflow is:

sudo apt update
sudo apt upgrade

On some older releases, the relevant package is named policykit-1, while newer distributions may use packaging that includes polkitd. Administrators should verify the installed package names rather than assuming that the same targeted upgrade command applies to every distribution.

After applying updates, follow the vendor’s reboot or service-restart guidance. A system may have a corrected package on disk while an older process remains active, so the operational completion of the update matters as much as successful package installation.

Canonical’s January 2022 security notices explicitly provided corrected package versions for affected Ubuntu releases. The original Ubuntu security announcement also instructed administrators to reboot after the update to complete the necessary changes.

For older Ubuntu releases that are no longer covered by standard security maintenance, a successful package-manager command is not proof that a current security fix is available. Administrators may need an applicable extended-security subscription, an approved vendor update source, or an operating-system upgrade.

How to Fix CVE-2021-4034 on RHEL and Related Systems

On RHEL-compatible distributions, the relevant component is usually managed through the polkit package.

Depending on the operating system generation, administrators can apply available package updates with:

sudo dnf upgrade polkit

For older systems using YUM:

sudo yum update polkit

The precise remediation should match the applicable Red Hat security advisory and package stream. Organizations running extended-update, long-term-support, or otherwise specialized maintenance channels should verify that the installed build includes the security correction rather than assuming that every published package has identical patch status.

Red Hat documented the issue under security bulletin RHSB-2022-001, describing how improper argument validation could cause environment-variable data to be processed as a command and lead to privileged code execution.

For production systems, the process should include change approval where applicable, package installation, validation of the installed build, verification that the expected executable is in use, and investigation of any suspicious activity that occurred before remediation.

A completed package update closes the known vulnerable condition. It does not retroactively establish that the system was never compromised.

Temporary PwnKit Mitigation When Patching Is Not Immediately Possible

When an affected system cannot be updated immediately, the original Qualys advisory and CERT-EU guidance describe removing the SUID bit from pkexec as a temporary mitigation.

For a confirmed installation at /usr/bin/pkexec, the command is:

sudo chmod 0755 /usr/bin/pkexec

This removes the executable’s SUID privilege, preventing it from acquiring root privileges through that mechanism under the usual file-permission model.

However, removing SUID can disrupt legitimate workflows that rely on pkexec to carry out administrative operations. The change should therefore be evaluated against the host’s operational requirements and applied through an approved configuration-management process.

This mitigation also has an important lifecycle limitation. Package replacement or reinstallation can restore the vendor’s default permissions, and an administrator might later re-enable SUID while the vulnerable executable is still present. For that reason, permission changes should be tracked explicitly and treated as temporary containment rather than a permanent substitute for installing the corrected software.

그리고 CERT-EU security advisory 2022-007 documents this workaround alongside the recommendation to update affected distributions.

How to Detect PwnKit Exploitation Attempts

Detecting historical exploitation of CVE-2021-4034 is more difficult than identifying an affected package. A version check can establish vulnerability exposure, but it cannot determine whether an attacker has already used the flaw.

Qualys described error conditions that could produce recognizable log messages during one exploitation technique. CERT-EU recommended searching for suspicious messages involving invalid shell values or abnormal environment-variable content.

A preliminary Linux journal search might look like:

sudo journalctl --since "30 days ago" \
  --no-pager | grep -Ei \
  'pkexec|GCONV_PATH|suspicious content|/etc/shells'

This command is intended for triage, not definitive detection. Matches may include legitimate Polkit activity, unrelated error messages, or administrative troubleshooting. Conversely, a system with no matching events may still have been compromised.

In its original advisory, Qualys specifically noted that while one exploitation approach produced log artifacts, the underlying vulnerability could also be exploited without leaving those particular messages. That limitation makes it inappropriate to build a detection policy around a single string or to interpret clean logs as proof of safety.

A stronger investigation correlates process-execution telemetry, unusual transitions from ordinary accounts to root, unexpected privileged child processes, abnormal shared-library activity, newly created SUID executables, and suspicious persistence artifacts. Evidence becomes more meaningful when it can be linked to a timeline of user sessions, service compromise, or filesystem changes.

For hosts running EDR or audit instrumentation, analysts should examine historical execution events involving pkexec and nearby process activity. Unusual parent-child process relationships may be worth investigating, but not every suspicious root process is evidence of PwnKit specifically.

The limitations of telemetry must remain explicit. Short journal retention, incomplete process auditing, deleted files, or attacker-controlled log manipulation may prevent a conclusive reconstruction. High-value systems with credible evidence of prior compromise may require a broader forensic investigation even after the vulnerable package has been patched.

Why CVE-2021-4034 Remains Relevant to Linux Security in 2026

PwnKit illustrates a recurring security problem: organizations often treat local privilege escalation vulnerabilities as secondary because they are not directly reachable from the internet.

That reasoning can be misleading.

A remote code execution flaw in a web application may initially give an attacker only the privileges of the service account running that application. A stolen SSH credential might permit access to a developer account without administrative rights. A malicious dependency executed in a build environment may begin with limited permissions.

In each scenario, the attacker has achieved some form of local code execution but may not yet control the host. A vulnerability such as CVE-2021-4034 can become the next stage of the attack, potentially converting restricted access into complete system control.

That changes the consequences of the initial compromise. The difference between executing code as a limited service account and executing code as root can determine whether an attacker can access system-wide secrets, manipulate privileged services, or establish durable persistence.

This is also why PwnKit’s inclusion in CISA’s Known Exploited Vulnerabilities Catalog is significant. Red Hat documented its addition to the catalog on June 27, 2022, following reports of exploitation in the wild. This is historical evidence of real-world exploitation, not a claim that a new exploitation campaign began in October 2026.

The vulnerability also belongs to a broader family of Linux privilege escalation problems involving trusted system components, privileged helper processes, and unsafe assumptions about execution environments. A more recent example involving a different mechanism is covered in Penligent’s analysis of CVE-2026-3888 and snapd privilege escalation. Although the root causes differ, both demonstrate why security boundaries around privileged system utilities deserve careful examination.

PwnKit remains a useful case study precisely because its exploitation depends on a chain of relatively small implementation details. A missing argument-count check, a memory-layout assumption, and a security-sensitive library-loading path together produced a route to root privileges.

For security engineers, the lasting lesson is not simply to patch Polkit. It is to assess privileged processes as complete execution systems, including how they handle arguments, environment variables, filesystem state, and external libraries before and after authorization checks.

How Security Teams Should Prioritize PwnKit Remediation

CVE-2021-4034 should be prioritized according to actual exposure and business impact, rather than solely by its historical CVSS score.

An unpatched internet-facing Linux application server deserves attention even though PwnKit itself is a local vulnerability. If another weakness or credential compromise provides local execution on that server, the local privilege escalation flaw may dramatically increase the impact of the incident.

Shared development environments, build servers, jump hosts, and systems storing production credentials may present similarly high consequences. Their risk is influenced by the likelihood of an attacker gaining an initial low-privilege foothold and by the assets accessible after privilege escalation.

Conversely, an asset with a verified patched Polkit package should not remain open as an unresolved PwnKit finding merely because its pkexec executable retains the expected SUID permission. Accurate vulnerability management requires interpreting the executable and package evidence together.

The same principle matters for automated penetration testing. A scanner that observes pkexec with elevated permissions has identified a potentially sensitive component, not necessarily an exploitable CVE. A useful security assessment should distinguish vulnerable builds, applicable mitigations, the privileges available to an attacker, and the effect of any surrounding isolation controls.

For teams using AI-assisted security validation workflows, including platforms such as 펜리전트, the important outcome is an evidence-backed understanding of the complete attack path rather than an isolated vulnerability label. Package evidence, effective permissions, initial-access assumptions, and remediation verification all matter when deciding whether an apparent local escalation issue presents a credible path to host compromise.

Frequently Asked Questions About CVE-2021-4034

Is CVE-2021-4034 remotely exploitable?

CVE-2021-4034 is classified as a local privilege escalation vulnerability, not a standalone remote code execution vulnerability. Exploitation requires the ability to execute code locally on a vulnerable system. However, remote attackers who have already obtained a low-privilege foothold through another vulnerability or compromised credential may be able to use PwnKit as a subsequent privilege escalation stage. The distinction matters because local access is a prerequisite, not a guarantee that the attacker’s presence originated locally.

Can CVE-2021-4034 be exploited without sudo access?

Yes. The vulnerability does not depend on the attacker possessing sudo permissions or knowing the root password. The original Qualys disclosure demonstrated that an unprivileged local account could exploit the vulnerable SUID-root pkexec executable and obtain root access. This is one reason the vulnerability attracted substantial attention: it bypassed the expected authorization boundary rather than relying on a user already having administrative rights.

Are patched Linux systems still vulnerable to PwnKit?

A system running the vendor’s corrected Polkit implementation is not vulnerable to this specific flaw merely because pkexec exists or uses SUID permissions. Nevertheless, patch status must be verified against the distribution’s own security advisories, particularly when vendor backports are involved. Other Linux privilege escalation vulnerabilities may still exist, so remediation of CVE-2021-4034 should not be interpreted as a comprehensive security assessment.

Can removing the SUID bit permanently fix PwnKit?

Removing the SUID bit from the vulnerable executable can provide an effective temporary mitigation for the documented escalation path, but it is not equivalent to correcting the underlying code. It may interfere with legitimate administrative functionality and can be reversed by later configuration changes or package operations. Installing a vendor-patched package remains the preferred long-term solution.

Does patching CVE-2021-4034 eliminate an existing compromise?

No. Patching prevents future exploitation of the corrected vulnerability, but it does not automatically remove attacker-created accounts, persistence mechanisms, stolen credentials, altered files, or other consequences of an earlier compromise. Where exploitation is suspected, teams should combine remediation with incident investigation and recovery procedures appropriate to the affected host’s trust level.

Final Assessment

CVE-2021-4034 demonstrates how a comparatively small error in argument handling can undermine a fundamental Linux privilege boundary. The vulnerability in Polkit’s pkexec utility allowed an unprivileged local user to influence privileged execution through an out-of-bounds memory access and unsafe environment-variable handling. Successful exploitation could result in arbitrary code execution as root.

The vulnerability was disclosed and patched in 2022, and it should not be misrepresented as a new 2026 zero-day. Its continued relevance comes from the security risks posed by unmaintained Linux systems, legacy deployments, and multi-stage intrusions in which local privilege escalation follows an initial foothold.

For administrators, the correct response is to identify the actual Polkit package in use, verify its vendor patch status, apply supported updates, and confirm the final installed state. For defenders investigating suspicious activity, package remediation should be accompanied by an assessment of historical access and potential post-exploitation activity.

Ultimately, PwnKit remains an enduring example of why Linux security depends not only on authentication policies but also on the correctness of the privileged code that enforces them. A trusted SUID executable is only as secure as its handling of the least trusted data it receives.