最近一段时间，一个诡异的内核问题困扰着格蠹的内核开发团队。在测试幽兰的系统镜像时，有一个随机的内核oops。
一旦这个oops发生，那么便产生一系列连锁的不良反应：比如声音无法播放，reboot失败等等。
内存越界
7月30日那天，我一边准备关于Windows 719大蓝屏的讲义，一边看这个oops，并在直播中提到了这个诡异的oops。
这个oops与719大蓝屏类似，也是非法访问内存，也就是通常所说的越界。内存是软件的舞台，内存问题就是人类社会的住房问题，千头万绪，盘根错节。
有趣的是，越界访问的内存地址非常奇怪，不是一般的0指针，也不是明显的小指针（小于4096的地址），而是一个很长的地址：
003a72656c646e69
根据多年的经验，我一眼看出这个地址中包含很多可读的ASCII字符，使用windbg的.formats命令转换，果然如此：
0:000> .formats 203a72656c646e69
Evaluate expression:
Hex: 203a7265`6c646e69
Decimal: 2322294337798696553
Octal: 0200723446255431067151
Binary: 00100000 00111010 01110010 01100101 01101100 01100100 01101110 01101001
Chars: :reldni
Time: Wed Jan 23 00:02:59.869 8960 (UTC + 8:00)
Float: low 1.10463e+027 high 1.57927e-019
Double: 1.9725e-153
也就是错误地址刚好对应的是" :reldni"这8个字符。把字节序调整一下，就是"indler: "。注意冒号后面还有一个空格（在栈上找到，有时体现在寄存器里）。
对于这个indler: ，如果加上一个h那么就很像软件世界里非常常用的一个单词：“handler: ”
这个oops是随机的，根据oop提供的函数地址，发生崩溃的内核函数名叫：sysfs_file_ops，源代码如下：
static const struct sysfs_ops *sysfs_file_ops(struct kernfs_node *kn)
{
struct kobject *kobj = kn->parent->priv;
if (kn->flags & KERNFS_LOCKDEP)
lockdep_assert_held(kn);
return kobj->ktype ? kobj->ktype->sysfs_ops : NULL;
}
但是大家都知道，对于这样的内存溢出问题，这肯定不是第一现场。这只是一个受害者。
全城搜索
对于内存越界这样的问题，因为溢出时常常无声无息，不知过了多久，才有现象，所以很难定位。
为了找到产生溢出的元凶，小伙伴们想了很多办法，比如根据使用UEFI启动没有oops，而使用u-boot启动有oops的现象，找u-boot的问题，修改了几版u-boot，看似有所缓解，其实是假象，因为本来就是个随机的问题。换了u-boot后，没看到oops，但过了几天又发生了。
上法器
对于越界这样的内存顽症，直接的方法就是上内存检查工具，比如ASAN（Address Sanitizer）。
Linux内核具有ASAN支持，称为KASAN，但是默认不启用，因为会影响性能。
为了抓到越界元凶，我一开始就建议启用KASAN，但是小伙伴启用KASAN编译出内核后，启动失败，上挥码枪调试，发现卡死在u-boot阶段。
第一次尝试KASAN失败后，小伙伴又想了一些其它排查手段，包括增加内核消息打印等，但都没有找到真正的凶手。
前天晚上，我亲自测试新版内核镜像，再次遇到开篇说的oops，很是恼火。
再上法器
昨天，我再次强推KASAN方法，坚定方向，一定要把这个方向走通。
大约一个小时后，好消息接连而至。
第一个好消息是小伙伴通过修改u-boot，成功把启用了KASAN的内核运行起来了。
第二个好消息是KASAN成功找到了一个内存越界写。
KASAN报告
听到这个消息，我立刻停下手上的其它工作。让小伙伴发我内核消息，凝神静气，仔细阅读。
内核时间戳25秒时，KASAN报告初始化完毕。
[ 25.146063] kasan: KernelAddressSanitizer initialized (generic)
33秒时，KASAN抓到越界写。
[ 33.918201] ==================================================================
[ 33.918234] BUG: KASAN: slab-out-of-bounds in __memcpy_fromio+0x8c/0x100
[ 33.918259] Write of size 8 at addr ffffff8101838afc by task systemd/1
[ 33.918283] CPU: 5 PID: 1 Comm: systemd Not tainted 6.1.43-rockchip-rk3588-taiyi #1.0.8
[ 33.918300] Hardware name: YourLand CodeBook (DT)
[ 33.918312] Call trace:
[ 33.918324] dump_backtrace+0xd0/0x130
[ 33.918338] show_stack+0x20/0x30
[ 33.918350] dump_stack_lvl+0xac/0xe0
[ 33.918368] print_report+0x164/0x464
[ 33.918384] kasan_report+0xc8/0x1a0
[ 33.918400] __asan_store8+0x80/0xa4
上面的调用栈省略了很多，因为涉及到敏感的安全问题（下文介绍）。
调用栈下面，有关于这次非法方法的详细细节。
[ 33.919049] The buggy address belongs to the object at ffffff8101838000
which belongs to the cache kmalloc-4k of size 4096
[ 33.919061] The buggy address is located 2812 bytes inside of
4096-byte region [ffffff8101838000, ffffff8101839000)
[ 33.919082] The buggy address belongs to the physical page:
[ 33.919094] page:00000000663e5886 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x101838
[ 33.919109] head:00000000663e5886 order:3 compound_mapcount:0 compound_pincount:0
[ 33.919123] flags: 0x8000000000010200(slab|head|zone=2)
[ 33.919146] raw: 8000000000010200 0000000000000000 dead000000000122 ffffff8100002a80
[ 33.919159] raw: 0000000000000000 0000000000040004 00000001ffffffff 0000000000000000
[ 33.919172] page dumped because: kasan: bad access detected
[ 33.919192] Memory state around the buggy address:
[ 33.919205] ffffff8101838a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 33.919218] ffffff8101838a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 33.919234] >ffffff8101838b00: 01 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 33.919246] ^
[ 33.919255] ffffff8101838b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 33.919270] ffffff8101838c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 33.919282] ==================================================================
安全问题
为什么上面故意省略了一些函数名呢？因为昨天夜里我仔细看了元凶代码后，觉得事情非常蹊跷。
为了方便描述，姑且把这个漏洞称为indler漏洞，根据就是最先发现它端倪的那个越界访问地址对应的是indler: 。
经过我们初步分析，indler漏洞的代码至少在2013年就已经存在，而且至今仍在内核主代码树。
这意味着，从2013年到今天的几乎所有Linux内核都有这个漏洞在。跨度长度十几年。
让我感觉不安的第二个特征是，这个漏洞可以在用户空间通过Linux的虚文件机制触发。这意味着黑客可以使用用户空间的某个应用做跳板，转而轻松攻击内核。
第三个关键特征是，这个漏洞可能导致的溢出可以非常大，可以长达数千字节。
查看这个漏洞代码的来源，它来自Google。这更让我觉得这个漏洞来头很大。
综合以上特征，黑客可以使用indler漏洞，实施多种攻击，包括向内核空间注入代码，实现远程代码执行（RCE）。至少，黑客可以通过这个漏洞，做DOS攻击，促发溢出，让内核崩溃，停止工作。
想到这个漏洞代码存在于从终端到云的数以亿计的计算机系统上，一旦被黑客利用，后果不堪设想。
因为此，我们故意隐藏了indler漏洞的具体函数名。正在与专业的安全团队合作，商讨下一步的计划。