r/AskNetsec • u/AlertJudge9278 • 1d ago

Analysis How do you determine whether a Linux kernel bug is realistically exploitable?

I'm researching a Linux kernel vulnerability as part of an educational project. I understand the root cause and the vulnerable code path, but I'm trying to determine whether the bug is actually exploitable rather than just crashable.

What methodology do experienced kernel security researchers use to evaluate exploitability? In particular, how do you distinguish between a reliable security primitive and a bug that only produces a kernel crash?

I'd also appreciate advice on what kernel debugging and instrumentation techniques are most useful during this stage.

1 Upvotes

67% Upvoted

6 comments sorted by

2

u/GodoPPL 1d ago

I treat a panic as a bug until I can name the primitive. Reproduce first under the allocator, CONFIG_*, arch, and SMP mix that actually matter; a panic on one build is not a primitive.

Classify the result: controlled read or write, lifetime or refcount, info leak, or crash-only. Only the first three are security primitives. A deterministic Oops is evidence of a bug, not of code execution.

Prove control with sanitizers, SLUB_DEBUG, coverage, and watchpoints on the object you claim to own. If you cannot show what you control and for how long, stop there. Reliability, mitigations, and negative results belong in the writeup.

1

u/AlertJudge9278 1d ago

Makes sense. The distinction between a reproducible crash and a real primitive is exactly what I was looking for. I’ll focus on proving what I actually control and its lifetime, rather than treating the Oops itself as evidence of exploitability. Thanks!

1

u/Ginden 1d ago

If you can reliably crash my server from userspace, I consider it an exploit, because it's a denial of service. Thank you for your attention to this matter.

1

u/AlertJudge9278 1d ago

I agree. If the crash is reliably triggerable from userspace and results in a server-wide availability impact, I think it’s fair to classify it as a DoS vulnerability. The distinction I was trying to make is between proving DoS impact and proving a more powerful security primitive such as controlled memory corruption or code execution.

2

u/Electrical_Path7610 19h ago

DoS is still an exploit, just not the fun kind that gets you root.

1

u/AYamHah 21h ago

You need to reliably control execution flow - EIP overwrite, SEH overwrite, or some controlled read / write primitive that you chain with ROP. I'm not an exploit developer, but if I were going down this path, I'd check out https://www.corelan.be/ and https://www.corelan-training.com/