Poc for CVE-2024-36971# CVE-2024-36971 — Proof of Concept (Research & Analysis Only)
> ⚠️ **DISCLAIMER — READ BEFORE USING THIS REPOSITORY**
> This repository is intended **only** for **defensive research, analysis, and responsible reporting**.
> It contains a non-exploitable proof of concept file named `CVE-2024-36971` and a publicly available Android kernel header snippet (`sock.h`) to illustrate the affected area.
> **No exploit code, reproduction commands, or step-by-step instructions are provided.** Do **not** run any files from this repository on production devices, third-party systems, or networks you do not control. The author disclaims any responsibility for misuse.
---
# Table of Contents
1. Overview
2. Repository contents
3. High-level technical summary
4. About the included `sock.h` snippet
5. Research environment (high-level, non-actionable)
6. Observed result (test device)
7. Responsible disclosure & contact
8. Legal & ethical notice
---
# 1. Overview
**CVE-2024-36971** is a Use-After-Free (UAF) vulnerability in the Android kernel network subsystem. The root cause is an unsafe order of operations when handling the destination cache (`dst`) used by socket routing (`sk->sk_dst_cache`), which can leave a dangling pointer accessible to concurrent code paths. This repository documents a defensive research PoC that demonstrates the *impact* (kernel instability and data corruption) without providing exploit primitives.
This README explains what the PoC demonstrates, why the included `sock.h` is relevant, and the responsible constraints around testing and sharing.
---
# 2. Repository contents
* `CVE-2024-36971` — PoC source file (kept in the repo for transparency). **Not** intended to be executed; included for archival/analysis purposes only.
* `sock.h` — public Android kernel header snippet showing the socket/destination structures and helpers relevant to the issue.
* `README.md` — this file (documentation and guidance).
---
# 3. High-level technical summary (non-actionable)
* **Root cause:** improper ordering of reference handling and release of `dst` objects in the routing/destination cache code path, allowing a Use-After-Free (UAF).
* **Trigger vector (high level):** a network-path that exercises the `__dst_negative_advice()` / destination cache code path in the kernel can cause the UAF condition to occur. This repository does **not** provide instructions to trigger it.
* **Observed impact:** kernel memory corruption, instability, and in tested circumstances, storage metadata corruption leading to a “data corrupted” boot state (soft-brick).
* **Exploitability status:** the PoC demonstrates impact and confirms the presence of a critical kernel bug. The observed corruption in testing was **non-deterministic and destructive**, not a stable, reliable exploit for code execution. Turning the bug into a reliable exploit would require advanced heap manipulation and allocator control — such work is outside the scope of this repository and is not provided.
---
# 4. About the included `sock.h` snippet
The `sock.h` header is a publicly available kernel header (sourced from Android kernel trees) that contains:
* definitions for `struct sock` and related networking structures;
* references to `sk_dst_cache` (the socket destination cache) and helpers to get/set destination references;
* RCU/refcount access patterns and `dst_release()` usage.
This snippet is included to show the exact structures and code locations that contextualize CVE-2024-36971. The header supports the explanation in this README by showing the data fields and functions whose ordering or synchronization is critical for correctness.
---
# 5. Research environment (high-level, non-actionable)
**Note:** The following is a list of typical capabilities and tools used by security researchers in a controlled lab. It is intentionally non-actionable — no commands, no scripts, no parameter values.
Recommended capabilities for safe, isolated kernel research:
* An **isolated test network** or air-gapped lab to ensure no accidental impact on third-party systems.
* Dedicated **test hardware** that you own and can fully reflash/wipe (do not use production or third-party devices).
* Virtualization (e.g., QEMU/KVM) for building and debugging kernel images in a controlled environment.
* The Android kernel source tree and a local build environment for compiling instrumented/debug kernels and generating symbol maps.
* Debug/logging tools and workflows: `adb`/fastboot for device access, collection of `dmesg`/`last_kmsg`, and tools to map kernel addresses to source lines (symbol files, `addr2line`, etc.).
* Kernel debugging and sanitizers (as appropriate) such as KASAN/KMSAN, ftrace, and other tracing facilities to detect memory safety violations without attempting exploitation.
* Secure artifact collection and storage for logs, backtraces, and photographic evidence.
---
# 6. Observed result (tested device)
* **Device tested:** Nothing Phone (1) — device owned and controlled by the researcher. The device was running a kernel revision that did not include the fix at the time of testing.
* **Test context:** the PoC was executed from the same local network as the target device in an isolated test environment.
* **Result:** after multiple sends of the PoC traffic, the device experienced severe kernel memory corruption. The corruption propagated to storage metadata and the device booted to an error indicating **“data corrupted”**. The device required repair/reflash to return to a usable state (soft-brick).
* **Important caveat:** this behavior was destructive and **non-deterministic**; the PoC produced corruption and data loss rather than a reliable code-execution primitive. The researcher **stopped** testing after observing destructive behavior — the goal was to verify impact, not to develop a working exploit.
# 7. Responsible disclosure & contact
This project follows responsible disclosure principles. If you are a vendor, maintainer, or security contact and require additional non-actionable diagnostic artifacts (full backtraces, sanitized logs, or forensic dumps) to validate or remediate the issue, please contact the repository owner via a secure channel. Preferred approaches include:
* opening a private GitHub issue and indicating a secure communication channel, or
* direct contact via PGP-encrypted email (provide your public key or request the researcher’s key).
The researcher will cooperate with validated vendors/maintainers and share additional diagnostic material under secure, appropriate terms. **Reproducible reproduction steps will not be published publicly.**
---
# 8. Legal & ethical notice
* This repository is provided **as-is** for **research, educational, and defensive** purposes only.
* The author does **not** condone malicious use and disclaims responsibility for any misuse.
* Do **not** use the contained materials on systems you do not own or manage.
* Always follow applicable laws, institutional policies, and vendor coordinated disclosure processes.
Log in to view the POC file snapshot cached by Shenlong Bot
Log in to view