freelist异常导致的异常地址访问
- 问题现象
- 初步分析
- 继续深入
- 新的发现
- 沙盘推演
- 寻找元凶
- 分析代码
- 后记
问题现象
项目一台设备几天内出现了两次crash，都是异常地址访问导致。
[66005.261660] BUG: unable to handle page fault for address: ffffff8881575110
初步分析
拿到coredump后，发现问题出在kmem_cache_cpu的freelist指针上。
crash> bt
PID: 4685 TASK: ffff88816f2b0000 CPU: 3 COMMAND: "mond"#0 [ffffc9000590f818] machine_kexec at ffffffff80284532#1 [ffffc9000590f898] __crash_kexec at ffffffff80383b82#2 [ffffc9000590f960] oops_end at ffffffff80248731#3 [ffffc9000590f980] page_fault_oops at ffffffff8028f0a6#4 [ffffc9000590f9a8] xas_create at ffffffff80f5272e#5 [ffffc9000590f9b0] brd_do_bvec at ffffffff809c9a60#6 [ffffc9000590fa08] kernelmode_fixup_or_oops at ffffffff8028f539#7 [ffffc9000590fa78] __bad_area_nosemaphore at ffffffff8028f9e3#8 [ffffc9000590faf8] exc_page_fault at ffffffff80f5adfc#9 [ffffc9000590fb20] asm_exc_page_fault at ffffffff81000b62[exception RIP: __kmem_cache_alloc_node+119]RIP: ffffffff80530257 RSP: ffffc9000590fbd0 RFLAGS: 00010246RAX: 0000000000000020 RBX: 0000000000000035 RCX: 0000000000000035RDX: 0000000001dfcf36 RSI: 0000000000000dc0 RDI: ffff888100041500RBP: ffffff88815750f0 R8: ffff888276dad410 R9: 0000000000000035R10: 0000000073646134 R11: 0000000004040404 R12: 00000000ffffffffR13: ffffffff80641477 R14: ffff888100041500 R15: 0000000000000dc0ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#10 [ffffc9000590fc00] __kmalloc at ffffffff804c9e77
#11 [ffffc9000590fc40] htree_dirblock_to_tree at ffffffff80641477
#12 [ffffc9000590fcc8] ext4_htree_fill_tree at ffffffff80640f75
#13 [ffffc9000590fdc8] ext4_readdir at ffffffff805f7c32
#14 [ffffc9000590fe88] iterate_dir at ffffffff80560d2b
#15 [ffffc9000590fed0] __x64_sys_getdents64 at ffffffff80561490
#16 [ffffc9000590ff28] do_syscall_64 at ffffffff80f57f28
#17 [ffffc9000590ff50] entry_SYSCALL_64_after_hwframe at ffffffff8100009bcrash> dis -l __kmem_cache_alloc_node+119
/code/FortiWEB/kernel/linux-6.1/mm/slub.c: 374 //获取内存ptr+offset位置保存的next空闲内存指针
0xffffffff80530257 <__kmem_cache_alloc_node+119>: mov 0x0(%rbp,%rax,1),%rbx通过上面基本能推断出是freelist地址异常导致的这次问题。
为了使大家看的更清晰，也把汇编代码列出，关键过程加备注解释，方便理解：
crash> dis -r __kmem_cache_alloc_node+119
0xffffffff805301e0 <__kmem_cache_alloc_node>: nopl 0x0(%rax,%rax,1) [FTRACE NOP]
0xffffffff805301e5 <__kmem_cache_alloc_node+5>: push %rbp
0xffffffff805301e6 <__kmem_cache_alloc_node+6>: push %r15
0xffffffff805301e8 <__kmem_cache_alloc_node+8>: push %r14
0xffffffff805301ea <__kmem_cache_alloc_node+10>: push %r13
0xffffffff805301ec <__kmem_cache_alloc_node+12>: push %r12
0xffffffff805301ee <__kmem_cache_alloc_node+14>: push %rbx
0xffffffff805301ef <__kmem_cache_alloc_node+15>: test %rdi,%rdi
0xffffffff805301f2 <__kmem_cache_alloc_node+18>: je 0xffffffff805302ae <__kmem_cache_alloc_node+206>
0xffffffff805301f8 <__kmem_cache_alloc_node+24>: mov %r8,%r13
0xffffffff805301fb <__kmem_cache_alloc_node+27>: mov %rcx,%r9
0xffffffff805301fe <__kmem_cache_alloc_node+30>: mov %edx,%r12d
0xffffffff80530201 <__kmem_cache_alloc_node+33>: mov %esi,%r15d
0xffffffff80530204 <__kmem_cache_alloc_node+36>: mov %rdi,%r14 //kmem_cache *s
0xffffffff80530207 <__kmem_cache_alloc_node+39>: cmpl $0x0,0x22f33f2(%rip) # 0xffffffff82823600 <kfence_allocation_key>
0xffffffff8053020e <__kmem_cache_alloc_node+46>: jle 0xffffffff8053021d <__kmem_cache_alloc_node+61>
0xffffffff80530210 <__kmem_cache_alloc_node+48>: cmpl $0x0,0x1a4da31(%rip) # 0xffffffff81f7dc48 <kfence_allocation_gate>
0xffffffff80530217 <__kmem_cache_alloc_node+55>: je 0xffffffff80530323 <__kmem_cache_alloc_node+323>
0xffffffff8053021d <__kmem_cache_alloc_node+61>: mov (%r14),%r8 //kmem_cache_cpu *cpu_slab
0xffffffff80530220 <__kmem_cache_alloc_node+64>: add %gs:0x7fae5360(%rip),%r8 # 0x15588
0xffffffff80530228 <__kmem_cache_alloc_node+72>: mov 0x8(%r8),%rdx
0xffffffff8053022c <__kmem_cache_alloc_node+76>: mov (%r8),%rbp //void **freelist
0xffffffff8053022f <__kmem_cache_alloc_node+79>: test %rbp,%rbp
0xffffffff80530232 <__kmem_cache_alloc_node+82>: je 0xffffffff805302be <__kmem_cache_alloc_node+222>
0xffffffff80530238 <__kmem_cache_alloc_node+88>: mov 0x10(%r8),%rax
0xffffffff8053023c <__kmem_cache_alloc_node+92>: test %rax,%rax
0xffffffff8053023f <__kmem_cache_alloc_node+95>: je 0xffffffff805302be <__kmem_cache_alloc_node+222>
0xffffffff80530241 <__kmem_cache_alloc_node+97>: cmp $0xffffffff,%r12d
0xffffffff80530245 <__kmem_cache_alloc_node+101>: je 0xffffffff80530253 <__kmem_cache_alloc_node+115>
0xffffffff80530247 <__kmem_cache_alloc_node+103>: mov (%rax),%rax
0xffffffff8053024a <__kmem_cache_alloc_node+106>: shr $0x3a,%rax
0xffffffff8053024e <__kmem_cache_alloc_node+110>: cmp %r12d,%eax
0xffffffff80530251 <__kmem_cache_alloc_node+113>: jne 0xffffffff805302be <__kmem_cache_alloc_node+222>
0xffffffff80530253 <__kmem_cache_alloc_node+115>: mov 0x28(%r14),%eax //offset
0xffffffff80530257 <__kmem_cache_alloc_node+119>: mov 0x0(%rbp,%rax,1),%rbx //*(freelist + offset) 获取内存ptr+offset位置保存的next空闲内存指针R14=RDI=(struct kmem_cache *)ffff888100041500
RAX=offset=0x20
RBP=freelist=ffffff88815750f0
为了严谨，通过kmem_cache确认一下。
struct kmem_cache {cpu_slab = 0x2d410,flags = 0x40001000,min_partial = 0x5,size = 0x40,object_size = 0x40,reciprocal_size = {m = 0x1,sh1 = 0x1,sh2 = 0x5},offset = 0x20, //RAXcpu_partial = 0x78,cpu_partial_slabs = 0x4,oo = {x = 0x40},min = {x = 0x40},allocflags = 0x0,refcount = 0x1,ctor = 0x0,inuse = 0x40,align = 0x40,red_left_pad = 0x0,name = 0xffffffff81582d0a "kmalloc-64", //通用的64字节的slab分配器crash> kmem_cache_cpu 0x2d410:3 //在问题CPU3上的 cpu_slab
[3]: ffff888276dad410
struct kmem_cache_cpu {freelist = 0xffffff88815750f0, //RBP 问题freelisttid = 31444790,slab = 0xffffea00055d43c0,partial = 0xffffea000400fac0,lock = {<No data fields>}
}也就是说 通用slab分配器 kmalloc-64在CPU3上的freelist异常，导致新申请内存时因为无法访问freelist+offset去获取下一个空闲object内存指针，导致了系统crash。
继续深入
接下来到比较头疼的地方了。freelist是怎么异常的？
是内核或者模块中有kfree(ptr=0xffffff88815750f0)将这个指针放回到freelist上的么？
答案是否定的！因为kfree释放地址时，slab会将原 freelist指针写到 ptr+kmem_cache.offset位置。而ptr=0xffffff88815750f0 是不可访问的地址，在kfree时就会出发地址访问异常。
我们再次审视 0xffffff88815750f0 这个异常地址，发现它比较怪异。它更像是一个正常地址的偏移。
从kmem_cache_cpu.slab我们可以知道slab对应的内存范围 ffff88815750f000 ~ ffff88815750ffff。
crash> kmem 0xffffea00055d43c0
CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME
kmem: kmalloc-64: slab: ffffea00055d43c0 invalid freepointer: ffffff8881575110
ffff888100041500 64 4063 4608 72 4k kmalloc-64SLAB MEMORY NODE TOTAL ALLOCATED FREE
kmem: kmalloc-64: slab: ffffea00055d43c0 invalid freepointer: ffffff8881575110ffffea00055d43c0 ffff88815750f000 0 64 63 1FREE / [ALLOCATED]
kmem: kmalloc-64: slab: ffffea00055d43c0 invalid freepointer: ffffff8881575110PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffea00055d43c0 15750f000 ffff888100041500 0 1 200000000000200 slabslab对应地址 ff ff 88 81 57 50 f0 00
异常freelist ff ff ff 88 81 57 50 f0
感觉像是 一个正常地址存在内存中，读取时偏移了一个字节。
00 f0 50 57 81 88 ff ff ff
0 1 2 3 4 5 6 7 8
从0-7 就是 ffff88815750f000 ， 从1到8 就是 ffffff88815750f0。
新的发现
异常内存地址的特点，基本指向了use_after_free，也就是说内存归还给slab分配器后，又对内存进行操作，导致异常。
但是如何推演出问题场景，还没有好的思路。另外kmalloc-64是通用的分配器，可能各种地方都在使用，一时不好去怀疑是哪个地方可能出了问题。
由于工作上同时有多个bug要处理，暂时搁置了下。然后QA报告该设备又出现一次crash，现象有些不同。
crash> bt
PID: 31715 TASK: ffff888106ef2e80 CPU: 2 COMMAND: "mond"#0 [ffffc90004f1f908] machine_kexec at ffffffff80284532#1 [ffffc90004f1f980] __crash_kexec at ffffffff80383b82#2 [ffffc90004f1fa48] oops_end at ffffffff80248731#3 [ffffc90004f1fa68] exc_general_protection at ffffffff80f588dd#4 [ffffc90004f1fb90] asm_exc_general_protection at ffffffff81000aa2[exception RIP: rb_insert_color+75]RIP: ffffffff80f4638b RSP: ffffc90004f1fc40 RFLAGS: 00010246RAX: ffff8881018bfdd0 RBX: 0000000000000005 RCX: ff88810242fd093aRDX: ffff8881274abe48 RSI: ffff88810242fa80 RDI: ffff888141437f88RBP: ffff88810242f0c8 R8: ffff88810242fd88 R9: ffff8881274ab180R10: 0000000070747962 R11: 0000000005050505 R12: ffff8881274ab180R13: 00000000454ccceb R14: 000000000d8620ac R15: ffff88817a984a60ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018#5 [ffffc90004f1fc40] htree_dirblock_to_tree at ffffffff80641531#6 [ffffc90004f1fcc8] ext4_htree_fill_tree at ffffffff80640f75#7 [ffffc90004f1fdc8] ext4_readdir at ffffffff805f7c32#8 [ffffc90004f1fe88] iterate_dir at ffffffff80560d2b#9 [ffffc90004f1fed0] __x64_sys_getdents64 at ffffffff80561490
#10 [ffffc90004f1ff28] do_syscall_64 at ffffffff80f57f28
#11 [ffffc90004f1ff50] entry_SYSCALL_64_after_hwframe at ffffffff8100009b这次是出在红黑树的插入时。巧的是错误地址 ff88810242fd093a 也像是读取发生偏移导致。
crash> dis -l rb_insert_color+75
/code/FortiWEB/kernel/linux-6.1/lib/rbtree.c: 115
0xffffffff80f4638b <rb_insert_color+75>: mov 0x8(%rcx),%rdxcrash> dis -r rb_insert_color+75
0xffffffff80f46340 <rb_insert_color>: mov (%rdi),%r8
0xffffffff80f46343 <rb_insert_color+3>: test %r8,%r8
0xffffffff80f46346 <rb_insert_color+6>: jne 0xffffffff80f4637f <rb_insert_color+63>
0xffffffff80f46348 <rb_insert_color+8>: mov %rdi,%rcx
0xffffffff80f4634b <rb_insert_color+11>: movq $0x1,(%rcx)
0xffffffff80f46352 <rb_insert_color+18>: ret
0xffffffff80f46353 <rb_insert_color+19>: nopw %cs:0x0(%rax,%rax,1)
0xffffffff80f4635d <rb_insert_color+29>: nopl (%rax)
0xffffffff80f46360 <rb_insert_color+32>: mov %rcx,%rax
0xffffffff80f46363 <rb_insert_color+35>: or $0x1,%rax
0xffffffff80f46367 <rb_insert_color+39>: mov %rax,(%rdx)
0xffffffff80f4636a <rb_insert_color+42>: mov %rax,(%r8)
0xffffffff80f4636d <rb_insert_color+45>: mov (%rcx),%r8
0xffffffff80f46370 <rb_insert_color+48>: and $0xfffffffffffffffc,%r8
0xffffffff80f46374 <rb_insert_color+52>: mov %r8,(%rcx)
0xffffffff80f46377 <rb_insert_color+55>: mov %rcx,%rdi
0xffffffff80f4637a <rb_insert_color+58>: test %r8,%r8
0xffffffff80f4637d <rb_insert_color+61>: je 0xffffffff80f4634b <rb_insert_color+11>
0xffffffff80f4637f <rb_insert_color+63>: mov (%r8),%rcx
0xffffffff80f46382 <rb_insert_color+66>: test $0x1,%cl
0xffffffff80f46385 <rb_insert_color+69>: jne 0xffffffff80f4649f <rb_insert_color+351>
0xffffffff80f4638b <rb_insert_color+75>: mov 0x8(%rcx),%rdx通过反汇编，找到红黑树的根节点。
crash> dir_private_info.root 0xffff88810242fa80 root = {rb_node = 0xffff88810242f688},crash> fname -x ffff88810242fd80
struct fname {hash = 0xb2f52600,minor_hash = 0x32115811,rb_hash = {__rb_parent_color = 0xff88810242fd093a, //这里就是异常发生的地址rb_right = 0xffff888141437f88,rb_left = 0xff88810242f0c8ff //异常},next = 0xff, //明显异常inode = 0x7a5900,name_len = 0x0,file_type = 0x5,name = 0xffff88810242fdae "\003ttyac" //明显异常
}然后试着将ffff88810242fd80 偏移1个字节，再按fname结构去读取
crash> fname -x ffff88810242fd81
struct fname {hash = 0x11b2f526,minor_hash = 0x3a321158,rb_hash = {__rb_parent_color = 0x88ff88810242fd09,rb_right = 0xffffff888141437f,rb_left = 0xffff88810242f0c8},next = 0x0,inode = 0x7a59,name_len = 0x5,file_type = 0x3,name = 0xffff88810242fdaf "ttyac"
}推断是申请fname时返回的是 ffff88810242fd81， 而在红黑树操作和旋转时，又以ffff88810242fd80去访问（最低位的1bit被当作红黑树的着色而或掉了）。
kmalloc时返回ffff88810242fd81，表明有use_after_free将 freelist+offset里的地址ffff88810242fd80改为了ffff88810242fd81。
要想满足这个并不容易，因为普通的覆写会整个破坏。像这种只改一个bit的，一般有两种情况：
- atomic_inc
- set_bit
也就是说存在一个结构，偏移0x20的位置是一个atomic或flags变量。当内存free后，这里保存的时next free object的地址指针。此时对这个结构加偏移位置内存的atomic_inc或set_bit，导致next free object地址指针的改变。此时kmalloc申请到的内存指针就会是正常指针ptr偏移1byte。
沙盘推演
kmallo获取地址偏移1byte的原因理清楚了。那么最早的 这个异常freelist = ffffff88815750f0 是怎么来的呢？
聪明的读者可能一下子就明白了。不明白的没关系，我也是又想了好久才弄清晰的。
答案就是next free的next free。
freelist--| |-----正确next----| 正确地址 v | v v---------------A--------------- -------------------B---------------------| |偏移1个byte| | |00| |00|f0|50|57|81|88|ff|ff|ff| |------------------------------- -----------------------------------------| ^ ^|-----错误next-------| 错误地址正常情况下freelist+offset位置存储着下一个free object的地址, 而free object+offset位置存储着下下一个free object的地址。
- 异常use_after_free, 修改了object A内存的 offset位置，导致此位置存储的next指针偏移。
- kmalloc申请内存，返回object A的地址。此时freelist=*(freelist + offset)位置得到错误的next object(向右偏移了一个byte)。
- kmalloc申请内存，返回object B+1的地址。一般为freelist向右偏移了1个byte，所以读取到的地址就会变成ffffff88815750f0 。
寻找元凶
思路通透以后，就是寻找元凶的时刻了。
kmalloc-64太通用了，不像其他特定的slab分配器，从代码上是不好定位的。
只能通过查看内存进行分析，好在这个分配器一个slab page包含64个object，不算很多。
比较幸运的是object中都留有有效信息，迅速帮我们找到内存的使用(或曾经使用)者。
crash> rd -s ffff88810bac50c0 8
ffff88810bac50c0: 0000000000000000 broad_proc_cleanup+10752
ffff88810bac50d0: ffff888101db68e8 ffff888101db68e8
ffff88810bac50e0: 0000000000000001 0000000000000000
ffff88810bac50f0: 0000000000000000 0000000000000000
//通过broad_proc_cleanup 找到这是个 team_item
crash> groups_item ffff88810bac50c0(4)
struct groups_item {hnode = {next = 0x0,pprev = 0xffffffffa03b1130 <borad_proc_cleanup+10752>},glist = {next = 0xffff888101db68e8,prev = 0xffff888101db68e8},list_account = {counter = 1 //atomic_t变量}
}这是一个业务模块，巧的是 list_account就是个atomic变量
基本上可以怀疑是这个业务模块对结构的user_after_free导致的。
为了全面，干脆把剩下的也看了。
crash> rd -s ffff88810bac5240 8
ffff88810bac5240: 0000000000000000 ffffc900098dc000
ffff88810bac5250: 0000000000005000 0000000000000002
ffff88810bac5260: ffff8881457d6de0 0000000400000000
ffff88810bac5270: 0000000000000000 copy_process+395 //通过copy_process找到这是个 vm_struct
crash> vm_struct ffff88810bac5240(10)
struct vm_struct {next = 0x0,addr = 0xffffc900098dc000,size = 20480,flags = 2,pages = 0xffff8881457d6de0,page_order = 0,nr_pages = 4,phys_addr = 0,caller = 0xffffffff8029cdab <copy_process+395>
}经过筛选，这个slab page 只有 fname，vm_struct和team_item在使用。
fname和vm_struct是内核代码， 出问题概率非常低，基本就是 业务模块了。
根据之前推导，应该是业务模块在释放 team_item后，又对其进行了 atomic_inc操作导致。
分析代码
找到元凶后，就剩下分析模块代码，找到出问题点。
代码问题比较隐蔽，初看没有问题。再仔细分析时，发现存在并发问题。
读写锁对事务的保护不够完善，查找和操作并没有完全保护起来，而是分成两部分保护了。
后记
因为是总结，所以条理相对清晰有序。实际分析这个问题是遇到不少困难，也走了一些弯路。一度有点沮丧，感觉找不到思路。还好最终找到问题原因。
其中也有一些幸运的地方，比如内存中留下了蛛丝马迹，帮助了解内存用途，如果没有这些，定位难度会大大提高。
