<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Linux on Prepakis Georgios | Kernelstub | Security Researcher</title><link>https://blog.kernelstub.dev/tags/linux/</link><description>Recent content in Linux on Prepakis Georgios | Kernelstub | Security Researcher</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Thu, 27 Mar 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.kernelstub.dev/tags/linux/index.xml" rel="self" type="application/rss+xml"/><item><title>Advanced Linux Kernel Exploitation Techniques</title><link>https://blog.kernelstub.dev/posts/advanced-linux-kernel-exploitation-techniques/</link><pubDate>Thu, 27 Mar 2025 00:00:00 +0000</pubDate><guid>https://blog.kernelstub.dev/posts/advanced-linux-kernel-exploitation-techniques/</guid><description>&lt;h2 id="introduction-to-linux-kernel-exploitation"&gt;Introduction to Linux Kernel Exploitation&lt;/h2&gt;
&lt;p&gt;Kernel exploitation sits at the top of the difficulty curve in offensive security, and for good reason. Userspace bugs get you code execution as some unprivileged process, but the kernel runs at Ring 0 (or EL1, if you&amp;rsquo;re on ARM) with unrestricted access to physical memory, every process&amp;rsquo;s address space, and every privilege check on the system. Pop a bug in the kernel and you&amp;rsquo;re not just compromising an application, you&amp;rsquo;re compromising the thing that enforces the rules for every application on the box. That&amp;rsquo;s why a single kernel LPE (local privilege escalation) bug is often worth more on the exploit market than a browser RCE: it&amp;rsquo;s the last mile between &amp;ldquo;I have a foothold&amp;rdquo; and &amp;ldquo;I own the machine.&amp;rdquo;&lt;/p&gt;</description></item><item><title>Linux Syscalls Table (x86-64)</title><link>https://blog.kernelstub.dev/posts/linux-syscalls-table-x86-64/</link><pubDate>Fri, 13 Sep 2024 00:00:00 +0000</pubDate><guid>https://blog.kernelstub.dev/posts/linux-syscalls-table-x86-64/</guid><description>&lt;h2 id="overview"&gt;Overview&lt;/h2&gt;
&lt;p&gt;Every time a program on Linux does something that touches the outside world, reading a file, allocating memory, sending a packet, spawning another process, it eventually has to ask the kernel to do it. User space code can&amp;rsquo;t just reach into the kernel&amp;rsquo;s data structures and start editing process tables or filesystem metadata; that would be a security and stability nightmare. Instead, it has to go through a narrow, well-defined door: the system call interface. This post is a reference table for that door on x86-64 Linux, listing every syscall number, its libc-facing name, its man page, and the kernel function that actually handles it once your program&amp;rsquo;s request lands.&lt;/p&gt;</description></item></channel></rss>