DBG-310 · Debugging & Tracing
Memory Corruption: KASAN & KFENCE
Finding use-after-free, out-of-bounds and uninitialised memory before they become a security advisory.
Who this course is for
Kernel and driver engineers who want use-after-free, out-of-bounds and uninitialised-memory bugs caught by tooling in development and production — before they become a corruption report or a security advisory.
Prerequisites
Course outline
Day 1 — KASAN
- What KASAN instruments and how shadow memory encodes object state
- Generic vs software-tag vs hardware-tag modes: coverage vs cost
- Enabling KASAN and pointing a test workload at a suspect driver
- Interpreting a KASAN report: access, allocation and free stacks, shadow bytes
- Use-after-free and out-of-bounds signatures side by side
Day 2 — Production and fallback detection
- KFENCE: low-overhead sampling detection designed for production
- KFENCE configuration: sampling rate, pool size and what it can and cannot catch
- KMSAN and uninitialised-memory tracking: the bug class nothing else sees
- Slab debugging, poisoning and redzones on kernels where sanitizers are not an option
- Choosing the detector per environment: development, CI, staging, production
Day 3 — From catch to regression
- Fault injection for memory paths: allocation failure and corruption injection
- Building a regression harness around a fixed bug
- Integrating sanitizer runs into a test pipeline without drowning in noise
- Triage discipline: deduplicating reports and ranking by exploitability-adjacent severity
- Workshop: three injected bugs taken from report to fix to regression test
Hands-on labs
Labs follow the academy model — 35% principles, 20% guided investigation, 45% engineering studio. Every claim you make in a lab is backed by a trace, a counter or a measurement you captured yourself. How we teach
- Lab: enable KASAN on a test kernel, run a corrupted module, and interpret the full report to its allocation and free stacks
- Lab: compare KASAN modes on one workload and measure the memory and CPU cost of each
- Lab: deploy KFENCE at a production-safe sampling rate and catch a latent bug a stress run surfaces
- Lab: use slab poisoning and redzones to catch corruption on a kernel where KASAN is not available
- Lab: wire a fault-injection point into a driver path and build a regression test around the bug you fixed
Capstone project
Design a memory-corruption defence-in-depth plan for a provided driver codebase: KASAN for development, a KFENCE policy for production, slab debugging as the fallback, and a fault-injection-backed regression harness. You demonstrate the plan by catching three injected bugs — use-after-free, out-of-bounds and uninitialised use — and deliver the sanitizer reports, the fixes and the harness for each.
What you leave with
- KASAN deployment and full report interpretation
- KASAN mode selection with measured costs
- KFENCE production configuration and its known limits
- Slab debugging and poisoning technique for constrained kernels
- A regression-harness pattern that keeps fixed corruption from returning
How it runs
Every course follows the same model: 35% principles, 20% guided investigation, 45% engineering studio. You leave with working code, raw measurements and an evidence-based report — not a certificate of attendance. Read the methodology or see a full sample lesson.
Material is adapted to your kernel version, hardware and workload before a private delivery. For public cohorts, the environment is provided and configured.
Questions
Who is this course for?
Kernel and driver engineers who want use-after-free, out-of-bounds and uninitialised-memory bugs caught by tooling in development and production — before they become a corruption report or a security advisory. It sits at advanced level within the Debugging & Tracing track.
What do I need to know already?
Specific prerequisites for this course: Kernel module development experience; Solid C (pointers, allocators, object lifetimes); Ability to build and boot custom kernels. We confirm levels before the cohort starts and adapt if a group is stronger or weaker than expected.
Can this run privately for my team?
Yes. Any course runs on-site at your offices anywhere, or live online for a distributed team, with labs adapted to your hardware and codebase.
What is the difference between in-person and online?
In person is 3 full days with hardware on your desk, capped at 14. Online is 6 half-day sessions across about two weeks so you can keep working, capped at 20, with remote lab access.
Do you invoice companies?
Yes. Purchase orders are accepted and invoicing is available in USD, EUR, GBP, SAR and CAD.
Upcoming dates
| Dates | Where | Seats | Early bird | Regular | |
|---|---|---|---|---|---|
| 1 Nov – 3 Nov 20263 full days | RiyadhIn person · KAFD Conference Centre | 7 of 14 | — | SAR 9,000 | |
| 8 Nov – 10 Nov 20263 full days | Kuwait CityIn person · Al Hamra Tower | 12 of 14 | KWD 670until 9 Oct | ||
| 15 Nov – 17 Nov 20263 full days | MuscatIn person · Knowledge Oasis Muscat | 7 of 14 | OMR 830until 16 Oct | ||
| 15 Nov – 22 Nov 20266 half-days | Gulf bandLive online · 09:00–13:00 GMT+3 | 17 of 20 | US$1,580until 16 Oct | ||
| 16 Nov – 18 Nov 20263 full days | OttawaIn person · Kanata North Tech Park | 12 of 14 | CAD 2,930until 17 Oct | ||
| 23 Nov – 25 Nov 20263 full days | TorontoIn person · MaRS Discovery District | 7 of 14 | CAD 2,930until 24 Oct | ||
| 23 Nov – 30 Nov 20266 half-days | Europe bandLive online · 09:00–13:00 CET | 6 of 20 | US$1,580until 24 Oct | ||
| 30 Nov – 2 Dec 20263 full days | LondonIn person · Shoreditch Works | 12 of 14 | GBP 1,680until 31 Oct | ||
| 30 Nov – 7 Dec 20266 half-days | Americas bandLive online · 13:00–17:00 ET | 11 of 20 | US$1,580until 31 Oct | ||
| 7 Dec – 9 Dec 20263 full days | BerlinIn person · Factory Görlitzer Park | 7 of 14 | EUR 1,990until 7 Nov |
Dates shown for the next few months. If nothing fits, tell us where and when — cohorts are added on demand, and private delivery can be scheduled any week.
More in Debugging & Tracing
DBG-1012 days
Reading an Oops & Panic Analysis
Turning a kernel splat into a precise location in the source, and knowing what the register dump is telling you.
Practitioner-taught
SAR 5,250Next 11 Oct
DBG-1103 days
kdump & the crash Utility
Capturing a crash dump in production and doing a real post-mortem on it.
Practitioner-taught
SAR 9,000Next 8 Nov
DBG-1203 days
kgdb & Live Kernel Debugging
Interactive kernel debugging over serial and network, plus dynamic debug for cases where stopping is not an option.
Practitioner-taught
SAR 9,000Next 25 Oct
DBG-2013 days
ftrace & trace-cmd
The kernel's built-in tracer, used properly: function graphs, events and latency tracers.
Practitioner-taught
SAR 7,880Next 1 Nov
DBG-2103 days
perf: Sampling to Flame Graphs
CPU and off-CPU analysis with perf, from first sample to a flame graph that tells you something actionable.
Practitioner-taught
SAR 7,880Next 11 Oct
DBG-2204 days
eBPF & bpftrace
Programmable observability: one-liners for immediate answers, custom programs for the questions nothing else answers.
Practitioner-taught
SAR 12,000Next 15 Nov
DBG-3013 days
Race Conditions & Lock Contention
The bugs that only appear under load on someone else's machine, and a method for actually finding them.
Practitioner-taught
SAR 10,120Next 22 Nov