Abstract:

This text details the process of analyzing and exploiting CVE-2025-21756, a Linux kernel vulnerability found in the vsock module. The bug is a Use-After-Free (UAF) resulting from incorrect reference counting when an unbound socket undergoes transport reassignment, leading to the premature freeing of the vsock_sock object while it remains linked in the vsock_bind_table. The author recounts the challenges faced, primarily AppArmor's LSM hooks preventing the use of the freed object (which panics when dereferencing a NULL sk->sk_security pointer) and Kernel Address Space Layout Randomization (kASLR). These were overcome by leveraging the unprotected vsock_diag_dump function as a side channel to brute force the init_net address (bypassing kASLR) and finding an unprotected code path within vsock_release that allows control flow redirection. Ultimately, the exploit overwrites the sk->sk_error_report function pointer on the reclaimed socket memory with a stack pivot gadget, leading to a ROP chain that calls commit_creds(init_cred) to gain root privileges before returning to userspace.

Summarizing the Linux Kernel Exploitation Write-up: CVE-2025-21756

• Identifying the Target: The author discovered the vulnerability (CVE-2025-21756) by examining a simple patch for a vsock bug submitted to KernelCTF. This inspired their first attempt at a Linux kernel exploit to gain root privileges.
• Setting up the Environment: An exploitation environment was established using QEMU, gef-kernel GDB extensions, and Linux kernel version 6.6.75, notably running within WSL.
• Vulnerability Analysis (UAF): Analysis of the patch revealed a Use-After-Free (UAF) in the vsock_remove_sock function. The bug occurs when a socket's transport is reassigned, incorrectly decreasing the reference count of an unbound vsock object, leading to its premature freeing while it remains in the vsock_bind_table. The goal is to trigger this free and reclaim the memory.
• Triggering a Kernel Panic: Running a slightly modified version of the test case provided by the kernel maintainers successfully caused a kernel panic. Debugging showed the vsock object was freed but still referenced in the vsock_bind_table, confirming the UAF.
• Roadblock #1: AppArmor and LSM: The kernel panic was traced to AppArmor (via LSM hooks like security_socket_bind) attempting to dereference a NULL sk->sk_security pointer, which is zeroed out when the socket structure is freed. Most socket functions are protected by these LSM hooks, making direct use of the freed object difficult without crashing.
• Bypassing AppArmor and kASLR: The author sought unprotected code paths. They discovered vsock_diag_dump, a function not protected by AppArmor. This function was used as a side channel: by spraying pipes to reclaim the freed vsock page and writing controlled data byte by byte, the author could detect when the vsock_diag_dump function's internal checks (like sock_net) were bypassed, indicating a successful overwrite of the skc_net pointer. This brute-force method also defeated kASLR by leaking the address of init_net.
• Achieving Control Flow (RIP): Control of the instruction pointer was achieved using the vsock_release function, which is also not protected by AppArmor. vsock_release calls sk->sk_prot->close(sk, 0). By forging the sk->sk_prot pointer to point to raw_proto, this call redirects to raw_abort.
• ROP Chain and Root: raw_abort calls sk_error_report(sk). The final step was to overwrite the sk->sk_error_report function pointer on the reclaimed vsock object with a stack pivot gadget (push_rbx_pop_rsp_ret). This redirects execution to a ROP chain crafted on the freed vsock object's memory. The ROP chain calls commit_creds(init_cred) to elevate privileges to root and then uses swapgs_restore_regs_and_return_to_usermode to return to userspace with root privileges.
• Success and Acknowledgement: The exploit was successful in obtaining a root shell. The author highlights the learning experience and thanks the #kernelctf discord community for their crucial assistance.