CVE-2025-38499

What it actually does

clone_private_mnt() omits a required CAP_SYS_ADMIN capability check against the userns owning the source mount namespace, allowing a process to clone a private mount that exposes resources hidden by MNT_LOCKED or namespace boundaries it could not otherwise access.

Why it matters to the business

Local users or container workloads can trigger availability impact by causing unexpected mount namespace states that disrupt service operation; the issue affects Debian-packaged Chromium and any downstream container images built from it.

How an attack unfolds

An attacker with a local account or compromised container process invokes clone_private_mnt() (directly or via a mount-related syscall) without holding CAP_SYS_ADMIN in the target userns; the missing check permits creation of a private mount view that bypasses intended isolation, leading to denial-of-service conditions in the affected namespace.

How to fix it

Upgrade chromium on Debian 12 to version 139.0.7258.66-1~deb12u1 or later; rebuild and redeploy any container images that embed the vulnerable package; verify the updated package is present on all affected hosts.

How to confirm the fix worked

Confirm the installed chromium package version is 139.0.7258.66-1~deb12u1 or newer via dpkg or apt; run kernel mount-namespace test suites that exercise clone_private_mnt() under reduced userns privileges to verify the capability check now occurs.

Typical attack path

1. Obtain local execution context (user shell or container escape foothold)
2. Locate or create a mount namespace with MNT_LOCKED children or differing userns privileges
3. Call clone_private_mnt() or equivalent mount API sequence without the required userns capability
4. Observe or trigger availability impact from the resulting inconsistent mount view

How to detect it

Search system and audit logs for mount-related syscalls originating from unprivileged processes that target namespaces they do not own; monitor for unexpected availability events in container workloads after mount operations.

What your security team should do

• Prioritize patching Debian 12 chromium installations within normal change windows given low EPSS and lack of KEV listing
• Audit container images for the vulnerable chromium package and rebuild with the fixed version
• Review local mount-namespace and capability policies to ensure least-privilege userns usage