Proof-of-concept implementations for CVE research, vulnerability analysis and Linux security experimentation.
This repository contains C-based PoCs developed to study selected vulnerabilities affecting Linux subsystems and to explore their underlying mechanisms.
Depending on the vulnerability, implementations range from controlled user-space simulations to experiments interacting with real Linux interfaces and subsystems.
🔗 Background: this repository continues earlier work on the same research theme, initiated in the predecessor repository containers_for_faas_security, a set of PoCs covering CVEs from 2016 to 2024. It builds on that work and extends it.
Note
A PoC in this repository is not necessarily a complete or reliable exploit. Some implementations reproduce vulnerable logic in a controlled environment rather than triggering the vulnerability directly in the Linux kernel.
- Study the technical mechanisms behind Linux vulnerabilities
- Reproduce vulnerable conditions in controlled environments
- Analyze memory-safety and boundary-checking issues
- Explore kernel subsystem behavior
- Investigate the security implications of containerized environments
- Develop experimental PoCs for vulnerability research
- Document observations and limitations during security experiments
| Category | Topics |
|---|---|
| Memory safety | Use-after-free · Out-of-bounds access · Buffer overflows · Memory lifetime and object reuse |
| Integer & boundary handling | Integer wraparound · Allocation-size mismatches · Insufficient bounds checking · Invalid length calculations |
| Concurrency & state management | Race conditions · Reference and usage counters · Transaction rollback · Object lifecycle management |
Linux subsystems involved: io_uring · RxRPC · Netfilter / nftables · AMDGPU / debugfs · ALSA · HID / BPF · RAID5 · Netlink
| Subsystem | Scenario modeled | Approach |
|---|---|---|
| io_uring | Fixed-buffer registration involving page calculation and access beyond the intended buffer boundaries. Tracks pages of the registered buffer, pages outside the expected range, out-of-bounds accesses and corruption events. | User-space simulation |
| RxRPC / XDR | Integer wraparound during the calculation of aligned lengths (see diagram below). | Controlled user-space simulation |
| AMDGPU | Insufficient size validation during a GPR wave buffer operation. Compares the requested size with the simulated buffer capacity and records potential out-of-bounds writes. | User-space simulation |
| Netfilter / nftables | Object-lifecycle scenario with chains, catchall elements and transaction aborts, leading to a use-after-free. Tracks usage counters, rollback, chain deletion, access to released memory and potential object reuse. | User-space simulation |
| ALSA / Scarlett2 | Prepares control data intended to exercise a vulnerable driver path through the ALSA control interface. | Linux subsystem interaction |
| HID / BPF | A BPF-related return value exceeds the size of a destination buffer. Tracks returned length, buffer capacity, out-of-bounds writes and corruption indicators. | User-space simulation |
The ALSA PoC differs from the simulated ones by interacting with an actual Linux subsystem through the ALSA API.
RxRPC / XDR: size calculation flow
flowchart LR
A[Large requested size] --> B[32-bit wraparound]
B --> C[Incorrect allocation size]
C --> D[Out-of-bounds write]
flowchart LR
A[CVE identification] --> B[Technical analysis]
B --> C[Vulnerable mechanism identification]
C --> D[PoC development]
D --> E[Controlled experimentation]
E --> F[Behavior / anomaly observation]
F --> G[Results and limitations]
The goal is not simply to execute an exploit, but to understand why a vulnerability occurs, under which conditions it can be observed, and what security boundary may be involved.
Several experiments are designed with containerized environments in mind. Where relevant, the PoCs detect common container environments and record whether an experiment runs inside or outside a container.
This supports research questions such as:
- How do Linux kernel vulnerabilities behave from a container?
- Which kernel interfaces are accessible from containers?
- How does container isolation affect vulnerability exposure?
- Can a kernel vulnerability cross a container boundary?
- Which security mechanisms limit or prevent exploitation?
These observations are experimental and should not be interpreted as proof of container escape or host compromise unless independently demonstrated.
CVE_Pocs/
├── 2023/
│ └── ...
├── CVE-2023-0461.c
├── CVE-2023-1281.c
├── CVE-2023-2598.c
├── CVE-2023-3090.c
├── CVE-2023-3106.c
├── CVE-2023-3609.c
├── CVE-2024-23307.c
├── CVE-2024-49969.c
├── CVE-2024-50282.c
├── CVE-2024-53142.c
├── CVE-2026-23078.c
├── CVE-2026-23111.c
├── CVE-2026-23172.c
├── CVE-2026-23178.c
├── CVE-2026-23351.c
├── CVE-2026-23390.c
├── CVE-2026-31401.c
└── CVE-2026-31641.c
Security: CVE analysis · vulnerability research · memory-safety analysis · boundary-condition testing · kernel security · container security
Interfaces: io_uring · Netlink · Netfilter / nftables · ALSA · BPF · debugfs
Warning
Detection of a simulated corruption or vulnerable condition does not by itself demonstrate successful kernel exploitation, privilege escalation or container escape.
These PoCs have different levels of fidelity. Some implementations:
- Simulate vulnerable kernel logic in user space
- Use simplified representations of kernel structures
- Reproduce vulnerability conditions rather than the complete kernel execution path
- Interact with real Linux interfaces without necessarily demonstrating successful exploitation
Results should be interpreted together with the corresponding CVE description, affected kernel versions, source-code analysis and experimental environment.
These PoCs are intended for security research, vulnerability analysis, academic experimentation, defensive testing and isolated laboratory environments.
- Only run experiments against systems you own or have explicit authorization to test.
- For kernel-level experimentation, use isolated environments such as virtual machines or dedicated research systems.
For each vulnerability, consult the authoritative CVE record, vendor advisory, Linux kernel documentation and upstream security discussions where available. CVE identifiers connect each PoC with the vulnerability being investigated.
Related repository: containers_for_faas_security, the earlier work this repository continues (PoCs covering CVEs from 2016 to 2024).
Lumière Minka, Software Engineer interested in cybersecurity, Linux systems, container security, cloud computing and vulnerability research.
This repository is part of my broader exploration of Linux security, container isolation and cloud/serverless security, and supports my research work at IRISA / Inria Rennes on container security for FaaS platforms.
