该漏洞存在于带有 eBPF bpf(2)系统（CONFIG_BPF_SYSCALL）编译支持的Linux内核中，是一个内存任意读写漏洞。该漏洞是由于eBPF验证模块的计算错误产生的。普通用户可以构造特殊的BPF来触发该漏洞，此外恶意攻击者也可以使用该漏洞来进行本地提权操作。

原作者exp此处可下载(可能需要梯子，这里copy了一份)，然而直接运行，很多机器是无法提权成功的。

源代码注释头有说到:

if different kernel adjust CRED offset + check kernel stack size

针对这个魔鬼数字:CRED_OFFSET=0x5f8

![魔鬼数字:CRED_OFFSET]

这篇文章也说明了真相：

cred结构体的偏移量可能因为内核版本不同、内核编译选项不同而出现差异，作者给的exp偏移量是写死的

此文作者也给出了一种应对之策：

通过以下方法可获取这个cred offset:

该命令需要有sudo权限的用户执行，通过insmod命令将getCredOffset模块注入内核

另开一个命令行执行该命令即可获取到cred offset，最后替换掉原exp中的偏移量即可成功提权。

然而，虽提权成功了，但此法有点怪异，本来想普通用户提权，但却需要用root用户执行命令来协助，有点力不从心。

那么问题又来了，该如何在不同的机器上动态获取这个cred offset呢？

经过上文作者的点拨：

这个漏洞是个任意地址读写漏洞，所以也可以在确定task_struct地址之后，以当前用户的uid为特征去搜索内存，毕竟cred离task_struct不远。

加上代码中有多处__read命令，以及getuid()命令，这两个命令都可以读取uid。
首先想到的是在往uidptr对应的地址中写0之前获取此时的uid值，通过以上两种方式对比看有什么差异：

果然如下图所示：

![提权成功]
那么规律来了，我们可以尝试以不同的cred offset来获取两个uid来进行对比，一旦对比上，姑且就当做找到了这个“确定”的值，然后再去write(0)。修改pwn函数如下：

想到原作者Vitaly Nikolenko给的CRED_OFFSET=0x5f8，我这边通过rebeyond这里给出的方法获取的是0x670，猜测这个值应该范围不大，尝试了一下用0x400~0x800爆破，很不幸，第一次尝试失败，被系统给killed掉啦：

![系统不听话了]

调整一下范围：0x500~0x800，ok 搞定！

不同机器此CRED_OFFSET偏移量可能还有差异，可以视情况稍微调整一下范围，试出结果应该不难。

最后来体验一把提权后带来的快感，root用户想干嘛干嘛，如图：

完整代码见这里。

参考链接：

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