本文主要面向对内核漏洞挖掘与调试没有经验的初学者，结合 CVE-2022-0847——著名的 Dirty Pipe 漏洞，带你从零开始学习 Linux 内核调试、漏洞复现、原理分析与漏洞利用。该漏洞危害极大，并且概念简单明了，无需复杂前置知识即可理解和复现。

文章涵盖以下主要内容：

环境搭建的调试脚本已经上传github：Brinmon/KernelStu

源码下载路径：Index of /pub/linux/kernel/v5.x/编译教程：kernel pwn从小白到大神(一)-先知社区

检查勾选配置：

构建最小根文件系统（基于BusyBox）

配置磁盘镜像配置rcS文件：

安装Qemu：

安装pwndbg：

gdb.sh

start.sh

系统调用实现原理Linux 系统调用是用户空间与内核交互的核心接口，其实现依赖于架构相关的中断机制（如 x86 的int 0x80或syscall指令）和系统调用表（sys_call_table）。每个系统调用通过唯一的系统调用号索引，对应内核中的sys_xxx函数。例如，open系统调用在内核中对应fs/open.c中的sys_open函数。

添加系统调用号

在linux源码中寻找到这个，手动添加系统调用号！

第一列是系统调用号，第二列表示该系统调用适用的架构类型（如common表示通用架构），第三列是系统调用的名称（在用户空间使用的名称），第四列是内核中对应的系统调用实现函数名。若要添加新的系统调用号，需按照此格式在文件中新增一行，并确保系统调用号的唯一性。

声明系统调用系统调用的声明通常位于include/linux/syscalls.h文件中。以read系统调用为例，其声明如下：

asmlinkage关键字用于指示编译器该函数是从汇编代码调用的，这在系统调用中很常见，因为系统调用的入口点通常由汇编代码处理。函数声明明确了系统调用的返回类型（这里是long）、参数类型及名称。其中，char __user 类型表示指向用户空间内存的指针，用于确保内核在访问该指针时进行必要的安全检查，防止内核非法访问用户空间内存。

定义系统调用系统调用的实现代码位置较为灵活。若不想修改makefile文件的配置，可将系统调用的实现放置在kernel/sys.c文件中。当然，为了更好的代码组织和管理，系统调用号也可分类放置在不同的文件夹中：1. 核心系统调用目录(1) kernel/：功能类型：进程管理、信号处理、定时器等核心功能。(2) fs/：功能类型：文件系统操作、文件读写、目录管理等。(3) mm/：功能类型：内存管理、映射、堆分配等。(4) net/：功能类型：网络通信、套接字操作。(5) ipc/ ：功能类型：进程间通信（IPC）。

SYSCALL_DEFINE 宏解析，系统调用号实现的具体，SYSCALL_DEFINE 宏 的书写规范与核心规则：

根据这个方法可以找到read系统调用的函数实现：

 f_op 结构体原理struct file_operations（简称f_op）定义了文件操作的函数指针，如open、read、write等。内核通过file->f_op调用这些函数，具体实现由文件系统（如 ext4、NFS）或设备驱动提供。

例如，在 ext4 文件系统中，当用户空间执行open操作打开一个文件时，内核会根据该文件对应的file结构体中的f_op指针，找到并调用 ext4 文件系统中定义的open操作函数。这个函数会处理诸如检查文件权限、打开文件描述符等具体操作。在设备驱动场景下，对于块设备驱动，其f_op中的read和write函数会负责与硬件设备进行数据交互，将数据从设备读取到内核缓冲区或从内核缓冲区写入设备。可以查看一下write的源码实现发现调用了，file->f_op->write_iter函数但是无法找到其源码实现！

下面结合源码进行讲解。假设我们要分析ext4文件系统中read操作的f_op函数实现。首先，在fs/ext4/file.c文件中，可以找到ext4_file_operations结构体的定义：

这里，.read_iter成员指向了ext4文件系统中read操作的具体实现函数ext4_file_read_iter。当用户空间执行read系统调用时，内核在处理过程中，若涉及到ext4文件系统的文件，就会通过file->f_op->read_iter来调用ext4_file_read_iter函数，从而完成read操作的具体功能，如从磁盘读取数据并填充到用户提供的缓冲区中。

GDB动态调试定位f_op 结构体所使用的函数定位一下：pipe_buf_confirm函数在源码下完断点之后，来到该调用的位置，在使用gdb命令就饿可以定位到buf->ops的具体值，从而在源码中定位函数的具体实现！

编译完成内核之后，可借助 AI 工具为内核源码添加代码注释，但需注意不能改变 Linux 源码的结构。由于动态调试时是直接索引到源码，如果改变源码的代码行数或者增加过多文本数量，都会打乱调试时的源码定位。因此，在使用 AI 添加提示词时，应将注释加在每行代码的后面。

常用的提示词，也可以自己优化:

在使用gdb调试源码时，常用的命令如下：

为了让gdb能正确索引到内核源码，需要修改.gdbinit文件添加源码索引。例如：

set disassembly-flavor intel命令设置gdb的反汇编风格为 Intel 格式，这样在调试时显示的汇编代码更易阅读。

在 Linux 系统中，pipe是一种进程间通信（IPC，Inter-Process Communication）机制。它允许两个或多个进程通过一个共享的缓冲区来传递数据，实现进程之间的通信。从系统调用的角度来看，通过pipe系统调用可以创建一个管道。

在终端中输入man 2 pipe可以查看其详细手册:

当调用pipe系统调用时，它会在内核中创建一个管道对象，并返回两个文件描述符，一个用于写入（通常称为写端，fd[1]），另一个用于读取（通常称为读端，fd[0]）。数据从写端写入管道，然后可以从读端读取出来，遵循先进先出（FIFO，First-In-First-Out）的原则。

从内核代码角度看，pipe系统调用的定义如下：

这里的SYSCALL_DEFINE1宏定义了一个接受一个参数的系统调用，该参数fildes是一个指向用户空间数组的指针，用于存储返回的文件描述符。实际的管道创建工作由do_pipe2函数完成：

do_pipe2函数首先调用__do_pipe_flags来创建管道，并获取两个文件描述符。如果创建成功，它会尝试将这两个文件描述符复制到用户空间的fildes数组中。若复制失败，函数会清理已分配的资源并返回错误。

进一步深入内核实现，__do_pipe_flags函数会调用create_pipe_files，最终调用到get_pipe_inode函数，该函数负责创建管道的核心数据结构：可以追踪到系统调用链：do_pipe2->__do_pipe_flags->create_pipe_files->get_pipe_inode

get_pipe_inode函数主要完成以下几个关键步骤：

在Linux内核中，管道（Pipe）通过struct pipe_inode_info和struct pipe_buffer两个核心结构体实现进程间通信（IPC）的底层管理。

1. 环形缓冲区与指针管理

在内核实现中，管道缓存空间总长度一般为 65536 字节，tp官方下载安卓最新版2025以页为单位进行管理， tp钱包安卓版下载总共 16 页（每页大小为 4096 字节）。这些页面在物理内存中并不连续，而是通过数组进行管理，从而形成一个环形链表。其中，维护着两个关键的指针：

2. 内存页与缓冲区数组

管道数据存储在离散的物理内存页中，通过struct pipe_buffer数组（bufs）管理：

管道本质是一个由内核维护的环形缓冲区，通过head和tail指针实现高效的数据读写：可以看一个Pipe缓冲区的实际示意图：这张图片展示了一个 pipe 的基本数据结构，具体是如何通过循环缓冲区（circular buffer）来管理数据传输。

或者参考一下这个结构图:

当我们使用read和write向pipe进行数据写入和读取的时候，read和write会寻找到pipe_write和pipe_read进行数据写入和读取!根据前面的管道结构体的讲解可知，pipe_write和pipe_read进行数据操作的时候实际都是对pipe->buf的内容进行写入和读取!

数据写入管道的操作由内核中的pipe_write函数负责。在数据写入过程中，pipe_write会调用copy_page_from_iter函数来完成从用户空间到内核管道缓冲区的实际数据复制。下面对pipe_write函数的执行流程进行详细拆解：

写入流程：数据按页写入bufs[head]，更新head指针；若缓冲区满，写进程进入睡眠。在pipe_write函数写入数据过程中，获取管道的写指针head，通过head & mask的运算，在pipe->bufs数组中定位当前用于写入的缓冲区buf。这里的mask是根据管道缓冲区总数计算得出的掩码，用于实现环形缓冲区的循环访问。最后调用copy_page_from_iter函数，将用户空间的数据从from迭代器中复制到内核分配的页面中，完成数据写入操作。

写入标记：

可以发现这里当第一次向管道写入数据的时候会将pipe->bufs[i]->flags字段赋值为PIPE_BUF_FLAG_CAN_MERGE，如果是网络数据通过pipe传输的话就会赋值PIPE_BUF_FLAG_PACKET;

如果想继续在管道写入数据会首先检查buf->flags字段和buf->page是否有剩余空间，再次调用pipe_write可以继续向这个buf->page写入数据!

数据从管道中读取的操作由内核中的pipe_read函数负责。在读取过程中，pipe_read会调用copy_page_to_iter函数来完成从内核管道缓冲区到用户空间的实际数据复制。下面对pipe_read函数的执行流程进行详细拆解：

读取流程：从bufs[tail]读取数据，更新tail指针；若缓冲区空，读进程阻塞。获取管道的读指针tail，通过tail & mask的运算，在pipe->bufs数组中定位当前用于读取的缓冲区buf。再调用copy_page_to_iter函数，将缓冲区buf中的数据从指定偏移量buf->offset开始，复制chars字节到用户空间的目标迭代器to中。最后将缓冲区的偏移量buf->offset向后移动已读取的字节数，减少缓冲区中剩余的有效数据长度buf->len。将读指针tail向后移动一位，并更新管道的读指针pipe->tail。

读取操作的通俗作用：可以将管道的内容读取出来，并且每次读取都可以算作清理管道数据!

Linux内核的Page Cache机制是操作系统中用于提升磁盘I/O性能的核心组件，它通过将磁盘数据缓存在内存中，减少对慢速磁盘的直接访问。以下是对其工作原理和关键特性的详细解释：

读操作

写操作1. 缓冲写入（Writeback）：当一个文件已经被打开过，那么应用程序的写操作默认修改的是Page Cache中的缓存页，而非直接写入磁盘。只在特定情况下，内核通过延迟写入（Deferred Write）策略，将脏页（被修改的页）异步刷回磁盘（由pdflush或flusher线程触发）。

优点：合并多次小写入，减少磁盘I/O次数。风险：系统崩溃可能导致数据丢失（需通过fsync()或sync()强制刷盘）。

https://www.zh-tpwallet.top

2. 直写（Writethrough）： 某些场景（如要求强一致性）会同步写入磁盘，但性能较低（较少使用）。

相关资料:

传统的文件拷贝过程（open()→read()→write()）需要在用户态和内核态之间多次切换，并进行 CPU 和 DMA 之间的数据拷贝，开销较大。而利用 splice 系统调用可以实现内核态内的“零拷贝”，只进行少量的上下文切换，从而极大提高数据传输效率。

传统拷贝： 4次上下文切换、2次 CPU 拷贝、2次 DMA 拷贝最简单的，就是open()两个文件，然后申请一个buffer，然后使用read()/write()来进行拷贝。但这样效率太低，原因是一对read()和write()涉及到4次上下文切换，2次CPU拷贝，2次DMA拷贝。

splice 零拷贝： 只需2次上下文切换再dirty_pipe使用splice进行0拷贝的话就可以实现极高的效率，只需要两次上下文切换即可完成拷贝!

为了理解 splice 零拷贝的内部实现，我们可以通过动态调试定位到关键函数 copy_page_to_iter_pipe。在该函数设置断点，并使用 gdb 查看调用栈，可以看到整个 splice 的调用链条。调用栈大致分为以下几个层次：可以很快发现整个splice的调用链！

在 SYSCALL_DEFINE6(splice， ...) 中，主要完成文件描述符转换、参数合法性检查，并调用 do_splice 进行实际的数据处理。

根据输入和输出的文件是否与 pipe 相关，选择不同的处理分支：

在 dirty_pipe 漏洞中，重点就在文件 → pipe 的场景，因为利用了 splice 复制过程中对管道内部管理机制的不足，才使得漏洞得以被利用。

该函数验证读取权限，检查长度，之后调用文件操作中实现的 splice_read。如果文件操作没有自定义该接口，则使用 default_file_splice_read。

这里的关键是in->f_op->splice_read，此处调用的 generic_file_splice_read来从文件中读取页面，并填充到管道中。

也可以通过动态调试来定位in->f_op->splice_read调用的是什么函数:

如何通过动态调试定位源码：

该函数内部构造了一个 pipe 的迭代器 iov_iter，然后通过调用 call_read_iter 实际执行数据读取操作。读取成功后会更新文件位置并调用 file_accessed 更新访问时间。

可以发现调用了call_read_iter函数最后也可以通过动态调试定位到函数generic_file_read_iter.

generic_file_read_iter 是所有能够直接利用页缓存的文件系统的通用读取例程。该函数处理直接 I/O 与缓冲读取的场景，确保在非阻塞或阻塞模式下都能正确返回数据或错误码。

在 generic_file_buffered_read 中，内核先通过 find_get_page 查找所需的页面，然后将页面中的数据拷贝到用户提供的缓冲区中。实际的拷贝操作是由 copy_page_to_iter 完成的。

copy_page_to_iter 根据 iov_iter 的类型选择合适的拷贝方式。当数据拷贝的目标是管道时，就调用 copy_page_to_iter_pipe。

在 copy_page_to_iter_pipe 函数中，关键核心buf->page = page;，这段代码就是内核完成了将文件的page_cache直接替换掉管道page，实现了0拷贝!

更加详细的了解0拷贝机制:详解CVE-2022-0847 DirtyPipe漏洞 - 华为云开发者联盟 - 博客园

Dirty Pipe 是一个存在于 Linux 内核 5.8 及之后版本 中的本地提权漏洞（CVE-2022-0847）。攻击者可通过覆盖任意可读文件的内容（即使文件权限为只读），将普通用户权限提升至 root 。其原理与经典的 Dirty COW（CVE-2016-5195）漏洞类似，但利用更简单、影响范围更广.

漏洞源于 管道（Pipe）机制与 Page Cache 的交互缺陷 ，具体涉及以下关键点：1.管道的“零拷贝”特性当通过 splice 系统调用将文件内容写入管道时，内核会直接将文件的 Page Cache 页面 （内存中的文件缓存页）作为管道的缓冲区页使用，而非复制数据。这一过程通过 copy_page_to_iter_pipe 函数实现

此时，管道缓冲区的 flags 被错误地设置为 PIPE_BUF_FLAG_CAN_MERGE，允许后续数据合并到该页中。

2.未初始化的标志位漏洞管道缓冲区的 flags 变量在初始化时未正确重置。当攻击者通过 splice 将文件内容写入管道后，若再次向同一管道写入数据，内核会错误地认为该页是可写的，从而允许覆盖原文件的 Page Cache 页面.

3.Page Cache 的覆盖效果由于文件的 Page Cache 页面被直接关联到管道缓冲区，攻击者通过向管道写入数据，可覆盖 Page Cache 中的原始文件内容。当其他进程读取该文件时，会直接读取被篡改的缓存页，导致数据被永久修改（即使文件本身权限为只读）

攻击者可通过以下步骤实现提权：

根据漏洞原理及公开分析，Dirty Pipe 的利用存在以下核心限制：

当然这些限制如果结合其他内核利用完全可以绕过这些限制!!!参考链接:veritas501/pipe-primitive: An exploit primitive in linux kernel inspired by DirtyPipe

测试POC：

构造一下漏洞复现场景，创建一个secret.txt文件只有root权限可以读写，其他用户只可以读

利用poc向这个只读文件进行内容覆盖！可以发现最后成功覆盖了！

POC中尝试将一个只能够的读的文件打开：

在linux内核源码中可以找到open函数的具体实现代码：

可以具体观察一下struct file，使用gdb在内核源码中下断点：

打下断点可以发现f就是以只读模式打开的文件

这就是该漏洞需要篡改的只读文件，当用户通过open()系统调用打开文件时，内核会创建struct file对象，并建立文件的页缓存（page_cache）映射。而这个文件的具体内容就会存放在这个文件结构体下管理的一个page中，同样的当用户通过pipe创建管道时，同样会创建一个page来存储输入管道的内容！dirty_pipe漏洞最关键的地方就是将一个只读文件的page通过漏洞替换掉普通用户创建的管道的page，从而实现越权对只读文件进行写入！

POC中创建一个管道，返回的管道存放在p中有一个读管道和写管道：

在linux内核源码中可以找到open函数的具体实现代码：

其中关键函数get_pipe_inode()完成以下操作：

可以具体观察一下struct pipe_inode_info，使用gdb在内核源码中下断点：

在动态调试情况下查看管道结构体：

struct pipe_inode_info和struct pipe_buffer是管道功能的核心管理者，其字段直接控制数据流动、内存分配和进程同步。在dirty_pipe漏洞中，攻击者通过操纵该结构体的缓冲区和页指针，绕过了内核对只读文件的保护机制。理解这一结构体的设计与实现，不仅有助于掌握管道的工作原理，也为分析类似漏洞提供了关键切入点。

POC中调用write和read对管道pipe进行写入和读取操作：

虽然这里调用的是write和read，结合前文提到的，操作pipe管道看上去使用的是write和read，但是他们会自动调用pipe_write和pipe_read来操作管道中的内容！

使用gdb在关键函数打下断点：

动态调试可以定位到，当向pipe写入数据时候，pipe_write会将pipe_buffer结构体的flags字段进行初始化赋值为：

这个标记是dirty_pipe漏洞利用的核心！拥有这个标记后pipe_write向管道输入内容的时候，就会直接在原有的page上进行写入，也就是直接在只读文件中进行越权写入！

这里为pipe_read下个断点可以发现，该函数是通过pipe_inode_info结构体的tail字段来锁定要读取的buf内容的！

这里之所以需要调用这个pipe_read函数是为了清空pipe_write向管道写入的内容，确保splice函数可以在管道中寻找到剩余的空间进行零拷贝！

POC中调用splice将字读文件fd的一个字节拷贝进入管道p[1]中，从而成功构造出一个可以越权写的page

使用gdb在关键函数打下断点：

可以观察到generic_file_buffered_read获取到只读文件的struct file结构体！

继续动态调试可以发现:系统可以通过这个函数来寻找到实际存储文件内容的page：

这个page就是在dirty_pipe漏洞触发时获取只读文件page的源码，可以通过动态调试手动定位一下：

Page Cache的管理依赖于内核中的address_space结构体，该结构体通过i_pages字段以稀疏数组（xarray）的形式存储文件的页缓存。每个文件的address_space对象（通常通过inode->i_mapping关联）维护了文件所有缓存页的索引，键为文件的页偏移量（pgoff_t），值为对应的物理页（struct page）。例如，当进程通过read()系统调用读取文件偏移量offset处的数据时，内核会计算对应的页偏移pgoff = offset >> PAGE_SHIFT，并在i_pages中查找对应的页。若找到则直接使用，否则触发缺页中断，分配新页并调用文件系统提供的readpage()方法填充数据。

参考资料：Linux系统的脏页机制：Linux 深入理解脏页(dirty page)-CSDN博客open系统调用讲解：Linux文件系统 struct file 结构体解析-CSDN博客

继续调试来到dirty_pipe漏洞的触发点，将只读文件的page直接赋值给buf->page字段，却未将buf->flags字段进行重新初始化为0，而是直接使用了旧的buf->flags值PIPE_BUF_FLAG_CAN_MERGE，导致用户再次调用pipe_write的时候会继续再只读文件的page进行内容修改，从而实现了越权修改内容！可以很快发现整个splice的调用链！

POC中调用write实际是pipe_write将要覆盖的字符串写入已经被dirty_pipe漏洞替换了page的管道之中，从而实现了越权写入！

使用gdb在关键函数打下断点：

可以发现buf确实是拥有PIPE_BUF_FLAG_CAN_MERGE字段的值，的成功向一个只读文件进行了修改操作！可以看看具体效果！一开始./secret.txt的内容是：This is a secret file!

发现如果读写都15次的话，pipe->head和pipe->tail都是15，但是由于pipe->max_usage为16，pipe的buf数量没有被用完!所以调用splice这里进行操作的时候会重新创建一个pipe_buffer buf->page用来存放0拷贝过去的只读文件，buf->flags没有被赋予PIPE_BUF_FLAG_CAN_MERGE标志，所以继续向管道写入的话无法在只读文件的page上面继续写!

提出疑问后直接修改POC进行测试:

发现关键点在：pipe_lock(opipe);这个函数会检测管道是否空闲，否则会一直等待！

找到源码：pipe.c

由于没有空闲的管道空间可以用所以会导致程序一直卡死！卡死原因 ：管道已满且未设置非阻塞标志，wait_for_space会调用pipe_wait等待，导致进程阻塞。

如何判断pipe是否有可用空间？

通过pipe_inode_info的head，tail和max_usage字段来判断是否存在可用空间所以我们需要解决的问题就是如何让程序认为管道有空闲的空间！通过动态调试确认，只需要调用至少一次pipe_read即可让程序判断管道有可用空间!

可以看看源码:

得出copy_page_to_iter_pipe的缓冲区索引计算方法:

所以如果只写满15次的话，那么调用splice的时候i->head是15的话那么获取到的buf就是&pipe->bufs[0]，而且splice结束后i->head的值也就变成了16!

再调用pipe_write向管道写入数据的话:

pipe_write的写入逻辑:

那么接着前面的head是16，buf获取到的序号就是&pipe->bufs[15]，和存放文件page的buf指向不同，所以无法覆盖!

但是如果我们将管道填满16次的话:漏洞利用成功的时候发现，在copy_page_to_iter_pipe的时候发现这个head值变为了17!通过计算可以发现copy_page_to_iter_pipe时候的buf和pipe_write的buf是同一个:pipe->buf[0]，所以可以对文件进行覆写!

可以弄清楚pipe_read的读取方式是通过buf->offest和buf->len来读取buf->page的数据的，即使page里面有完整的内容，由于其余两个字段的限制，所以只能输出一个字节!

在poc中调用splice的时候至少复制一个字节，由于管道的写入机制每次只能向管道后面追加数据，所以被写入管道的第一个字节是无法覆盖的！

参考链接：DirtyPipe(脏管道)提权_脏管道提权-CSDN博客

该程序通过dirty_pipe漏洞劫持拥有root权限的二进制程序，覆盖掉原有程序注入一个恶意的elf文件：

然后调用这个被覆盖掉的二进制程序进行执行，就可以向/tmp/sh注入一个拥有root权限的可执行提权程序！继续看另一个恶意程序elf_code：

最后执行这个程序就可以成功提权了！

可以修改rcS脚本来构造一个有root权限的程序，用来测试提权：

漏洞公告：

工具与代码：

技术分析：

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课