CVE-2026-31431

Author: 0xShe

Language / 语言

• English: https://github.com/0xShe/CVE-2026-31431/blob/main/README.md
• 中文: https://github.com/0xShe/CVE-2026-31431/blob/main/README-CN.md

CVE-2026-31431 Kernel Privilege Escalation Tool Guide

0x01 Quick Start

Some target environments do not have Python installed, so this privilege escalation logic was rewritten in C.

1. Compile

Run the following command on your Linux machine or WSL (using -static is recommended to avoid GLIBC version issues):

gcc -static exploit.c -o exploit

2. Deploy and Execute

Upload the generated binary to the target machine:

chmod +x exploit
./exploit

If the exploit succeeds, the program will automatically execute su and spawn a root shell directly without requiring a password.

0x02 Privilege Escalation Logic: How Does It Work?

This exploit abuses a logic flaw in the Linux kernel’s AF_ALG interface (Kernel Crypto API).

1. Create a Crypto Socket The program creates an AEAD (Authenticated Encryption with Associated Data) socket using socket(AF_ALG, ...).

2. Memory Injection (Splice) By leveraging Linux’s splice system call, data from a file descriptor (in this case /bin/su) can be directly redirected into the kernel crypto buffer.

3. Payload Overwrite Using specific memory offsets, the exploit replaces part of /bin/su’s authentication logic with a privilege escalation payload (a minimal ELF program that launches /bin/sh).

4. Trigger Privilege Escalation After the kernel completes the series of crypto operations, the in-memory su process has already been tampered with. When system("su") is finally executed, the system actually runs the modified root shell payload instead.

0x03 Troubleshooting Guide: Why Does It Still Ask for a Password?

During debugging, if the program outputs Exploit finished but running su still requires a password, the issue is usually caused by one of the following details.

1. The Critical MSG_MORE Flag

This is the most common failure point. The sendmsg call must include the MSG_MORE flag.

• Reason: This flag tells the kernel that more data is coming and prevents the crypto buffer from being finalized too early.

• Consequence: Without this flag, the kernel immediately closes the current crypto context. As a result, the subsequent splice injection cannot enter the correct kernel buffer, making the overwrite impossible.

2. Associated Data Length (Assoclen)

The kernel is extremely strict about alignment and length checks for AEAD associated data.

• Pitfall: If ASSOCLEN in the C code is set to 4 bytes while the kernel expects 8 bytes (or vice versa), the kernel may either throw an invalid argument error or silently skip the injection logic entirely.

3. File Offset Reset

During the loop that modifies /bin/su, each splice operation must start reading from offset 0.

• Pitfall: If off_su is not explicitly reset to 0, splice behaves similarly to read() and continues advancing the file pointer. On the second iteration, the injected data becomes misaligned, which may corrupt su or break the exploit logic.

4. Kernel Patches

Some systems may already have silent security patches applied. This was confirmed during testing on multiple machines — certain targets had already received unofficial or backported fixes.

0x04 Notes

• Kernel Version: This vulnerability mainly affects early 5.x Linux kernels (such as the initial release of Ubuntu 20.04). If the kernel has already been patched, this method will no longer work.

• Path Differences: Different Linux distributions may store su in different locations (/bin/su or /usr/bin/su). The code attempts to detect the correct path automatically, but if neither exists, manually verify it using which su and modify the code accordingly.

• Disclaimer: This article is intended strictly for technical research and educational purposes. Do not use it for illegal activities. Users are solely responsible for any legal consequences resulting from misuse of the tool.