CVE-2026-7867-disk2root

Filesystem.Mount → as-user Spoofing → Authorization Bypass → Root-context Mount → LPE

Overview

CVE-2026-7867 is a local privilege escalation vulnerability in udisks2 involving the Filesystem.Mount D-Bus method, the as-user option, fstab-managed mount flows, and flawed authorization handling.

This private repository contains the technical research notes and PoC scripts used to validate the issue in a controlled lab environment.

The vulnerability was discovered and reported by:

The issue was assigned:

CVE-2026-7867

Executive Summary

The vulnerability is caused by a flawed trust relationship between the real D-Bus caller UID and the computed/effective UID produced by the as-user mount option.

In vulnerable flows, an unprivileged local user can influence the mount execution path so that a filesystem mount is performed in a privileged/root context without the expected PolicyKit authorization behavior.

The core bug is not simply “user-controlled mount options.”

The real issue is:

udisks2 fails to consistently distinguish the original caller identity from the computed as-user identity during fstab mount authorization and execution.

Vulnerability at a Glance

Affected Area

The vulnerable logic is associated with the fstab mount handling path inside udisks2, especially when the mount request involves:

Filesystem.Mount
as-user
x-udisks-auth
user
users

The relevant security-sensitive areas are:

D-Bus caller identity
        ↓
as-user option handling
        ↓
fstab authorization logic
        ↓
PolicyKit decision flow
        ↓
root-context mount execution

Attack Flow

┌─────────────────────────────┐
│ Unprivileged Local User     │
└──────────────┬──────────────┘
               │
               │ Filesystem.Mount
               │ with as-user influence
               ▼
┌─────────────────────────────┐
│ udisks2 / udisksd           │
│ privileged system daemon    │
└──────────────┬──────────────┘
               │
               │ fstab logic evaluates
               │ user/auth options
               ▼
┌─────────────────────────────┐
│ Authorization Gap           │
│ mount_other_user not        │
│ enforced in skipped path    │
└──────────────┬──────────────┘
               │
               │ root-context branch reached
               ▼
┌─────────────────────────────┐
│ Filesystem Mounted          │
│ without expected auth flow  │
└──────────────┬──────────────┘
               │
               │ impact depends on mount flags
               ▼
┌─────────────────────────────┐
│ Local Privilege Escalation  │
│ controlled lab validation   │
└─────────────────────────────┘

Root Cause

The vulnerable behavior comes from an identity confusion bug.

The system has multiple identity concepts:

real D-Bus caller UID
computed as-user UID
effective mount UID
udisksd daemon privilege context

The vulnerable flow fails to enforce these identities consistently.

In particular:

• mount_other_user can become true because as-user is used
• fstab options such as x-udisks-auth, user, or users can affect the authorization path
• the authorization block can be skipped
• the mount_other_user check is not reliably enforced outside that block
• the mount path can reach a branch intended for genuine root/admin execution
• the mount is performed by the privileged daemon context

The result is a local privilege boundary bypass.

The x-udisks-auth Problem

The x-udisks-auth option is supposed to force an administrative PolicyKit authorization flow.

Expected behavior:

mount request
    ↓
attempt mount as caller
    ↓
permission/auth failure
    ↓
PolicyKit filesystem-fstab check
    ↓
admin approval
    ↓
mount as authorized privileged action

Vulnerable behavior:

mount request with as-user influence
    ↓
computed identity affects execution
    ↓
mount succeeds too early
    ↓
PolicyKit auth path is not reached as expected
    ↓
privileged mount state is achieved

This makes the security model around x-udisks-auth unreliable in the vulnerable path.

Security Model Violation

Expected model:

Unprivileged user
    ↓
D-Bus mount request
    ↓
PolicyKit / fstab authorization
    ↓
restricted mount behavior

Broken model:

Unprivileged user
    ↓
D-Bus mount request with as-user spoofing
    ↓
authorization logic mismatch
    ↓
root-context mount execution

The bug is especially serious because the affected service runs with elevated privileges.

Impact

Successful exploitation may allow a local unprivileged user to mount a filesystem through udisks2 in a root-context execution path without the expected authorization prompt.

Depending on the filesystem and mount flags, impact may include:

• local privilege escalation
• unauthorized root-context filesystem mounting
• bypass of expected PolicyKit authorization
• unsafe fstab-managed device mounting
• setuid-based escalation in affected lab configurations
• unexpected execution of files from attacker-controlled or prepared filesystems

Exploitation Conditions

This is a local vulnerability.

Relevant conditions include:

Repository Layout

.
├── README.md
├── disk2root.sh              ← main exploit (self-contained LPE)
└── poc/
    ├── setup_lpe_env.sh       ← lab environment setup
    ├── f2_mount_as_user_bypass.sh
    ├── f2_check_nosuid.sh
    ├── f2_suid_test.sh
    ├── f2_final.sh
    └── cleanup_lpe_env.sh

Exploit — disk2root.sh

Self-contained weaponized exploit. Builds its own SUID root payload, creates a prepared disk image, mounts it via the as-user=root polkit bypass, and drops into a root shell.

Quick Start

Option 1 — Run as root (works everywhere, including SSH):

./disk2root.sh

The script automatically:

1. Compiles a static SUID root shell binary
2. Creates a 32MB ext4 image on a loop device
3. Injects the binary with uid=0 mode=4755 via debugfs
4. Adds an fstab entry with x-udisks-auth
5. Drops to an unprivileged user via su
6. Calls Filesystem.Mount with as-user=root (polkit bypass)
7. Executes the SUID binary → root shell
8. Cleans up everything on exit

To specify which user to escalate from:

./disk2root.sh testuser

If no user is specified, the script picks the first regular user on the system or creates a temporary one.

Option 2 — Run as unprivileged user (desktop / active session):

./disk2root.sh

On systems with an active polkit session (desktop login, GNOME/KDE), the script is fully self-contained — it creates its own loop device via udisksctl or D-Bus LoopSetup, mounts via as-user=root, and escalates without any prior setup.

Option 3 — Run as unprivileged user (SSH, after setup):

If the environment was already prepared (e.g. by running poc/setup_lpe_env.sh as root, or by a previous ./disk2root.sh run as root), any unprivileged user can re-exploit:

./disk2root.sh

The script detects vulnerable fstab entries automatically and uses them.

Cleanup

./disk2root.sh --cleanup

Removes all artifacts: fstab entry, loop device, mount point, temporary user.

Strategy Cascade

When run as unprivileged, the script tries multiple paths in order:

[A] Self-contained
    build payload → create ext4 image → debugfs inject SUID binary
    → loop-setup (python3 GIO / udisksctl) → mount as-user=root
    ✓ works on desktop sessions

[B] Fstab fallback
    scan /etc/fstab for x-udisks-auth / user / users entries
    → mount as-user=root → find SUID binary on mounted fs
    ✓ works on SSH when environment is prepared

Example Output

╔═════════════════════════════════════════════════════╗
║  CVE-2026-7867 — disk2root                          ║
║  udisks2 as-user polkit bypass → LPE root shell     ║
╚═════════════════════════════════════════════════════════╝

[*] uid=1002 (testuser) — exploiting...
    fstab: /dev/loop5 → /mnt/disk2root (x-udisks-auth)
    mounted: /mnt/disk2root
    nosuid: not set
    suid: pwn (4755 root:root)

╔═════════════════════════════════════════════════════╗
║  dropping into root shell — type 'exit' to return   ║
╚═════════════════════════════════════════════════════════╝

[+] root shell — uid=0 euid=0
root@target:/tmp#

Requirements

PoC Scripts (poc/)

Individual validation scripts used during research. These are the building blocks that led to disk2root.sh.

Lab Flow (using individual PoC scripts)

1. Run poc/setup_lpe_env.sh as root
2. su - testuser
3. Run poc/f2_mount_as_user_bypass.sh
4. Run poc/f2_final.sh for full validation
5. Run poc/cleanup_lpe_env.sh as root

Or simply use disk2root.sh which combines all of the above.

Technical Primitive

The primitive demonstrated by this research is:

as-user option spoofing inside privileged mount orchestration

The critical transition is:

unprivileged D-Bus caller
        ↓
spoofed/computed mount identity
        ↓
authorization path confusion
        ↓
root-context mount execution

This is why the issue qualifies as a local privilege escalation vulnerability.

Why This Bug Matters

udisks2 is commonly trusted as a privileged storage management daemon.

A bug in this layer is high-impact because it sits between:

desktop/session users
D-Bus method calls
PolicyKit authorization
filesystem mount operations
root daemon privileges

A flaw in identity handling here can directly affect local privilege boundaries.

Detection Ideas

Defenders can monitor suspicious udisks2 mount activity involving as-user.

Useful telemetry sources:

udisksd logs
D-Bus method calls
PolicyKit logs
mount table changes
/proc/mounts
/etc/fstab
journalctl

Useful commands:

findmnt
mount
cat /proc/mounts
journalctl -u udisks2
journalctl | grep -i udisks
journalctl | grep -i polkit

Suspicious patterns:

non-root user triggering Filesystem.Mount
as-user=root usage
unexpected mount without PolicyKit prompt
mounts lacking nosuid/noexec/nodev
setuid execution from recently mounted filesystems
unexpected loop device mounts

Mitigation

Update udisks2

Apply the vendor-provided fix once available.

Planned fixed release:

udisks 2.11.2

Review fstab Entries

Audit entries using:

x-udisks-auth
user
users

Especially review filesystems that can contain executable or setuid content.

Restrict Local Shell Access

Since this is a local vulnerability, reducing untrusted local access lowers exposure.

Monitor Mount Activity

Monitor unexpected mount operations through:

udisksd

especially when triggered by non-root users.

Enforce Safer Mount Flags

Where applicable, use:

nosuid
noexec
nodev

These flags may reduce post-mount impact.

Harden PolicyKit Rules

Review PolicyKit rules related to udisks mount actions.

Ensure unprivileged users cannot trigger sensitive mount paths without explicit authorization.

Fix Direction

A robust fix should ensure that:

• original D-Bus caller UID is preserved
• computed as-user UID does not replace caller identity for authorization
• mount_other_user always triggers proper PolicyKit checks
• root-context mount execution is limited to genuine authorized root/admin flows
• x-udisks-auth consistently enforces authentication
• related code paths such as encrypted filesystem handling are audited

Disclosure Timeline

Credits

Public Release Plan

After embargo lift, this repository can be converted into a public research repo with:

docs/
├── technical-analysis.md
├── root-cause.md
├── lab-setup.md
├── exploit-flow.md
├── detection.md
└── mitigation.md

Recommended public additions:

• official CVE link
• Red Hat advisory link
• upstream patch link
• affected/fixed version matrix
• safe reproduction guide
• controlled PoC usage notes
• detection and hardening guide

Disclaimer

This repository is for authorized security research, vendor coordination, and defensive validation only.

The PoC scripts are intended for isolated test environments.

Do not run these scripts on systems you do not own or do not have explicit permission to test.

The authors are not responsible for misuse of this research.

CVE-2026-7867
udisks2 Local Privilege Escalation Research