[LINPEAS] Add privilege escalation check: From Chrome Renderer Code Execution to L...

[carlospolop]

🔧 Automated Privilege Escalation Check Addition

🤔 Privilege Escalation Reasoning

The blog post describes a local Linux kernel vulnerability (CVE‑2025‑38236) in AF_UNIX MSG_OOB handling that leads to a reliable privilege escalation path from an unprivileged sandboxed renderer to kernel code execution. This is a generic kernel bug, not a CTF‑style custom misconfiguration or a niche userspace package issue. The technique hinges on:

1. Kernel‑level LPE primitive: A reachable and fully weaponized UAF in the Linux kernel for versions >= 6.9 where CONFIG_AF_UNIX_OOB is enabled (which is the default when AF_UNIX is enabled prior to the later config prompt). The exploitation relies on only standard syscalls (socketpair, send, recv, clone, pipe, etc.) and default AF_UNIX behaviour, so it is representative of real environments.

2. Reachability from common sandboxes: The post explicitly shows that the bug is reachable from Chrome’s Linux Desktop renderer sandbox via stream AF_UNIX sockets and unfiltered send/recv flags. That means in practice it is a realistic route from low‑privileged code to root/kernel, not a lab‑only configuration.

3. Generalizable exploitation pattern: Beyond this specific CVE, the writeup documents reusable, environment‑agnostic exploitation patterns:

   • Using AF_UNIX MSG_OOB to get a 1‑byte arbitrary kernel read via forged SKBs and copy_to_user.
   • Tracking allocator and MMU state via usercopy‑constrained reads (vmemmap, per‑CPU data, pgd_list) to convert a read into controlled reallocation of a freed slab page.
   • Recycling a slab page first as a pipe buffer, then as the top page of a kernel stack by controlling allocation/free patterns.
   • Using CONFIG_RANDOMIZE_KSTACK_OFFSET as an alignment oracle to line up a sensitive stack local under a constrained write primitive.
   • Using a self‑looping skb frag_list to intentionally stall a kernel path until external userland changes a linked‑list pointer.
   • Using AF_UNIX datagram sendmsg() to place structured attacker‑controlled bytes on the kernel stack.

All of these are building blocks of a practical local privilege escalation exploit chain on a vanilla modern Linux distribution with a vulnerable kernel. They are not dependent on custom daemons, odd init scripts, or non‑standard third‑party software versions. As such, the core detection opportunity that is suitable for linpeas is the presence of the vulnerable kernel feature / version combination and configuration.

The exact exploit techniques (forging SKBs, vmemmap introspection, pipe/stack recycling) are too low‑level and exploit‑specific to codify directly into an automated enumeration script like linpeas. However, for linpeas' purpose (enumeration and vulnerability hinting), it is both feasible and valuable to:

• Detect vulnerable kernel versions where AF_UNIX MSG_OOB is present and not compiled out.
• Optionally, perform a very lightweight behavioral probe to see if the specific UAF trigger still exists (carefully and optionally, because it touches the kernel). This would allow linpeas to flag: "kernel appears vulnerable to CVE‑2025‑38236 – public exploits exist for local privilege escalation."

This is aligned with how linpeas already checks for known, high‑impact, broadly relevant local kernel LPE CVEs (e.g., Dirty Pipe, Dirty COW, overlayfs bugs), and this AF_UNIX MSG_OOB bug fits that same class: a widespread mainline kernel LPE condition, reachable from unprivileged code through standard interfaces on desktop/server Linux.

🤖 Implementation Details

PEASS linpeas agent completed successfully with 140 items. Agent Comment: Summary:

• Added a dedicated CVE-2025-38236 module (linPEAS/builder/linpeas_parts/1_system_information/18_CVE_2025_38236.sh) that highlights vulnerable Linux kernels (≥6.9) where AF_UNIX MSG_OOB is enabled, aligning with the Project Zero exploitation chain.
• The check now parses uname -r, compares versions, inspects kernel configs (CONFIG_AF_UNIX_OOB / CONFIG_UNIX) across common paths (including /proc/config.gz), and reports mitigations or confirms when MSG_OOB is disabled.
• Included detailed context for the vulnerability, exploitation summary, mitigation guidance, and heuristics clarification so operators understand potential false positives (e.g., vendor backports).

Testing:

• sh -n linPEAS/builder/linpeas_parts/1_system_information/18_CVE_2025_38236.sh

🏗️ Builder Agent Response

LinPEAS build agent completed successfully with 83 items. Agent Comment: ✅ LinPEAS build fixed and verified

What I did

1. Ran the official build command from /tmp/hacktricks_update_1961lfng/repo/linPEAS and reproduced the failure. The builder complained that several variables in linpeas_parts/1_system_information/18_CVE_2025_38236.sh were missing from the “Generated Global Variables” metadata.
2. Updated that module by:
   • Adding every CVE-specific variable the script creates ($cve38236_kernel_release, $cve38236_conf_file, etc.) to the Generated Global Variables metadata block so the builder knows they’re intentional.
   • Renaming helper variables inside _cve38236_cat_config_file and _cve38236_read_config_line to CVE‑specific names for uniqueness/clarity, and rewriting _cve38236_read_config_line to use the new names consistently.
3. Re-ran python3 -m builder.linpeas_builder --all --output /tmp/linpeas_fat.sh with a 600‑second timeout. This time the build completed successfully and produced /tmp/linpeas_fat.sh.

Result

• ✅ LinPEAS now builds end-to-end with no errors.
• ✅ Output binary: /tmp/linpeas_fat.sh

Let me know if you’d like me to run additional checks or commits.

---

This PR was automatically created by the HackTricks Feed Bot. Please review the implementation carefully and test thoroughly before merging.