[内核内存] linux内核态内存检测技术

最新推荐文章于 2023-11-07 18:29:04 发布
最新推荐文章于 2023-11-07 18:29:04 发布
阅读量1.8k 收藏 8
点赞数 2
分类专栏： linux内存 文章标签： linux内核内存检测 KASAN slub_debug kmemleak 内存debug
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u010923083/article/details/117021755
版权

文章目录


linux常见的内存错误访问：

  • 越界访问(out of bounds)
  • 访问已经释放的内存(use after free)
  • 重复释放
  • 内存泄露(memory leak)
  • 栈溢出(stack overflow)
a. 对于内核内存泄露问题--->kmemleak工具

b. 对越界访问，重复释放，栈溢出和访问已经释放内存等问题：
	1.若是slab/slub分配器分配的内存：slub_debug
	2.KASAN是比slub_debug强大的功能，但资源消耗更大

1 slub_debug

slub_debug可以检测内核态内存越界（out-of-bounds）和访问已经释放的内存（use-after-free）等问题，部分的slub_debug问题需要通过slabinfo工具去发现（该工具在内核源码的tools/vm目录下gcc编译），但是仅仅针对从slub/slab分配器分配的内存,对于从栈中或者数据区中分配的内存，slub_debug就不能进行检测，可以利用KANSAN等其他内存检测工具。

内核配置

CONFIG_SLUB=y

CONFIG_SLUB_DEBUG=y

CONFIG_SLUB_DEBUG_ON=y

CONFIG_SLUB_STATS=y

slabinfo工具编译

在linux内核源码tools/vm目录下执行：
	***gcc -o slabinfo slabinfo.c
程序执行后，可以通过slabinfo -v查看日志结果

系统加载内核启动参数

​ 如qemu启动内核cmd的–append里面添加"slub_debug=UFPZ"如：

sudo qemu-system-x86_64 -kernel ./bzImage -initrd ./cgel-image-virt-generic-pc-x86-64.cpio -net nic -net 
	tap -m 1024M -smp 4 -append "root=/dev/ram rw console=ttyS0 slub_debug=UFPZ" -nographic  -cpu max
  • F：在free的时候会执行检查。
  • Z：表示Red Zone的意思。
  • P：是Poison的意思。
  • U：会记录slab的使用者信息，如果打开，会会显示分配释放对象的栈回溯。

功能

  1. 越界访问
    1. 左越界：Object padding overwritten
    2. 右越界：Redzone overwritten
  2. 重复释放：Object already free
  3. 访问已释放内存：Posion overwritten

实例

右越界访问：

  1. ​ 模块文件

    //slub_right_oob.c
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include<linux/delay.h>
MODULE_LICENSE("GPL");
MODULE_AUTHOR("JingTao");
MODULE_DESCRIPTION("A simple test program for slub right oob test");
MODULE_VERSION("0.01");

char *buf;
void create_slub_error(void)
{
	printk(KERN_INFO "hello, master!\n");  
	buf = kmalloc(32, GFP_KERNEL);
	if(!buf)
		return;
	buf[32] = 0x88;
	kfree(buf);
}

static int __init lkm_example_init(void) {
	create_slub_error();
	return 0;
}
static void __exit lkm_example_exit(void) {
	printk(KERN_INFO "Goodbye, master!\n");
}
module_init(lkm_example_init);
module_exit(lkm_example_exit);

  2. Makefile文件

    obj-m := mySkubRightOob.o

#和mo块c文件名一致
mySlabRightOob-objs := slub_right_oob.o

#内核源码路径（源码已经make all）
KERNELDIR := /home/taojing/linux5.11.2/src

ARCH := x86

#工具链路径
CROSS_COMPILE := /home/taojing/toolchain/x86_64/x86_64_gcc6.2.0_glibc2.24.0/bin/x86_64-pc-linux-gnu-

#当前路径，编译结果存放地，一般和模块c文件在一个目录
CURENTDIR := $(shell pwd)

default:
        make -C $(KERNELDIR) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) M=$(CURENTDIR) modules

clean:
        @rm -rf $(CURENTDIR)/*.ko
        @rm -rf *.order
        @rm -rf Module.symvers
        @rm -rf *.o
        @rm -rf *.mod*

    在上述模块c文件和Makefile所在目录执行make,就可生成mySkubRightOob.ko文件。然后将该模块文件插入qemu启动的内核中。

    slub_debug打印日志如下（有些时候需要执行slabinfo -v命令获取到日志信息）

    [  126.790861] mySlabRightOob: loading out-of-tree module taints kernel.
[  126.840081] hello, master!
[  126.841079] =============================================================================
#指明错误类型---Redzone overwritten，（kmalloc分配的内存区域）右越界访问
[  126.841920] BUG kmalloc-32 (Tainted: G           O     ): Redzone overwritten
[  126.841920] -----------------------------------------------------------------------------
[  126.841920]
[  126.841920] Disabling lock debugging due to kernel taint
#red zone开头两字节区域的magic num有0xcc变成0x88,异常
[  126.841920] INFO: 0x000000009363cedd-0x000000009363cedd @offset=3392. First byte 0x88 instead of 0xcc
#slab的分配栈回溯
[  126.841920] INFO: Allocated in create_slub_error+0x22/0x3c [mySlabRightOob] age=2 cpu=3 pid=207
[  126.841920]  __slab_alloc+0x9/0x10
[  126.841920]  kmem_cache_alloc_trace+0x177/0x1e0
[  126.841920]  create_slub_error+0x22/0x3c [mySlabRightOob]
[  126.841920]  lkm_example_init+0x5/0x1000 [mySlabRightOob]
[  126.841920]  do_one_initcall+0x47/0x1c0
[  126.841920]  do_init_module+0x56/0x1ff
[  126.841920]  load_module+0x25f4/0x2920
[  126.841920]  __do_sys_init_module+0x152/0x170
[  126.841920]  do_syscall_64+0x33/0x40
[  126.841920]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
#slab的释放栈回溯
[  126.841920] INFO: Freed in security_cred_free+0x37/0x50 age=87220 cpu=2 pid=0
[  126.841920]  security_cred_free+0x37/0x50
[  126.841920]  put_cred_rcu+0x1e/0x90
[  126.841920]  rcu_core+0x1cf/0x660
[  126.841920]  __do_softirq+0xf4/0x283
[  126.841920]  asm_call_irq_on_stack+0x12/0x20
[  126.841920]  do_softirq_own_stack+0x32/0x40
[  126.841920]  irq_exit_rcu+0x93/0xa0
[  126.841920]  sysvec_apic_timer_interrupt+0x2c/0x80
[  126.841920]  asm_sysvec_apic_timer_interrupt+0x12/0x20
[  126.841920]  default_idle+0xe/0x10
[  126.841920]  default_idle_call+0x2d/0xa0
[  126.841920]  do_idle+0x1ad/0x270
[  126.841920]  cpu_startup_entry+0x14/0x20
[  126.841920]  secondary_startup_64_no_verify+0xc2/0xcb
#slab的地址，以及其它信息。
[  126.841920] INFO: Slab 0x0000000005649ac3 objects=19 used=14 fp=0x000000002c2e8a49 flags=0x100000000010201
# 当前Object起始，及相关信息
[  126.841920] INFO: Object 0x00000000c5d6d5ae @offset=3360 fp=0x0000000000000000
[  126.841920]
# 问题slab对象内容，打印问题slab对象内容之前一些字节。前面的Redzone用于检测左越界访问，magic num为oxcc
[  126.841920] Redzone 0000000083d35604: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
[  126.841920] Redzone 00000000218c6dd9: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
[  126.841920] Object 00000000c5d6d5ae: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[  126.841920] Object 00000000121b8350: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  kkkkkkkkkkkkkkk.
#该Redzone用于检测右越界访问，前两个字节为0x88，不为默认的0xcc，说明右访问越界，问题出在这，容易看出就越界访问了两个字节。
[  126.841920] Redzone 000000009363cedd: 88 cc cc cc cc cc cc cc                          ........
# Padding内容，为了对象对齐而补充
[  126.841920] Padding 00000000a38a7a7b: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
[  126.841920] Padding 00000000893bf7b2: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
#检查问题点的栈打印，这里是由于slabinfo找出来的。
[  126.841920] CPU: 3 PID: 207 Comm: insmod Tainted: G    B      O      5.11.2 #2
[  126.841920] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[  126.841920] Call Trace:
[  126.841920]  dump_stack+0x57/0x6a
[  126.841920]  check_bytes_and_report+0xe6/0x120
[  126.841920]  check_object+0x1c3/0x270
[  126.841920]  ? lkm_example_init+0x5/0x1000 [mySlabRightOob]
[  126.841920]  free_debug_processing+0x136/0x330
[  126.841920]  __slab_free+0x210/0x3d0
[  126.841920]  ? __slab_alloc+0xb/0x10
[  126.841920]  ? 0xffffffffc01a8000
[  126.841920]  ? 0xffffffffc01a8000
[  126.841920]  ? lkm_example_init+0x5/0x1000 [mySlabRightOob]
[  126.841920]  lkm_example_init+0x5/0x1000 [mySlabRightOob]
[  126.841920]  do_one_initcall+0x47/0x1c0
[  126.841920]  ? __slab_alloc+0x9/0x10
[  126.841920]  ? kmem_cache_alloc_trace+0x177/0x1e0
[  126.841920]  do_init_module+0x56/0x1ff
[  126.841920]  load_module+0x25f4/0x2920
[  126.841920]  ? __do_sys_init_module+0x152/0x170
[  126.841920]  __do_sys_init_module+0x152/0x170
[  126.841920]  do_syscall_64+0x33/0x40
[  126.841920]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  126.841920] RIP: 0033:0x4aabf9
[  126.841920] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 6b 33 01 00 c3 66 2e 0f 1f 84 00 00 00 00
[  126.841920] RSP: 002b:00007ffc6da5d0d8 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
[  126.841920] RAX: ffffffffffffffda RBX: 00007ffc6da5d480 RCX: 00000000004aabf9
[  126.841920] RDX: 000000000063822b RSI: 0000000000001368 RDI: 0000000001147d20
[  126.841920] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000001368
[  126.841920] R10: 0000000001147cc0 R11: 0000000000000246 R12: 00007ffc6da5d469
[  126.841920] R13: 00007ffc6da5d488 R14: 000000000063822b R15: 0000000000000000
#问题点是如何被解决的，此处恢复2个字节为0xcc
[  126.841920] FIX kmalloc-32: Restoring 0x000000009363cedd-0x000000009363cedd=0xcc

    slub_debug实现原理

    ​ 参考：https://zhuanlan.zhihu.com/p/103721910

2 kmemleak

linux内核提供了一个方便的内核态内存泄露扫描工具：kmemleak，该工具通过启动一个内核线程对linux系统的内存进行扫描，然后打印它新发现未引用内存对象的数量和相关信息。

内核配置

CONFIG_HAVE_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE=16000
CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=n #打开该选项需要在内核命名行添加kmemleak=on启动参数

qemu启动内核

sudo qemu-system-x86_64 -kernel ./bzImage -initrd ./cgel-image-virt-generic-pc-x86-64.cpio 
						-net nic -net tap -m 1024M -smp 4 
						-append "root=/dev/ram rw console=ttyS0 kmemleak=on" -nographic  -cpu max

系统启动后扫描方式

1.mount -t debugfs debugfs /sys/kernel/debug/
2.执行内核测试程序触发内存泄露
3.echo scan > /sys/kernel/debug/kmemleak（手动触发扫描，需等待一段时间）
4.cat /sys/kernel/debug/kmemleak（查看泄露检测日志打印，并分析原因）

原理

kmemleak通过追踪kmalloc(), vmalloc(), kmem_cache_alloc()等函数，把分配内存的指针和大小、时间、stack trace等信息记录在一个rbtree中，等到调用free释放内存时就把相应的记录从rbtree中删除。也就是说rbtree中的记录就是已经分配出去但尚未释放的内存，其中有些内存尚未释放是因为还在被使用，这属于正常情况，而不正常的情况，即真正“泄漏”的内存都是不会再被使用的，那么如何找出泄漏的内存呢？kmemleak缺省每10分钟对内存做一次扫描，寻找内存中有没有rbtree中记录的地址，如果某个地址在内存中找不到，就认为这个地址是无人引用的，不会再被用到，是“泄漏”了，然后，把这些泄漏的内存地址以及rbtree中记录的相关信息通过 /sys/kernel/debug/kmemleak 这个接口展现给我们。

实例

1.模块c文件

//kmemleak.c
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/vmalloc.h>
#include<linux/delay.h>
MODULE_LICENSE("GPL");
MODULE_AUTHOR("JingTao");
MODULE_DESCRIPTION("A simple test program for kmemleak test");
MODULE_VERSION("0.01");

static char *buf;


void create_kmemleak(void)
{
  buf = kmalloc(120, GFP_KERNEL);
  buf = vmalloc(4096);
}

static int __init lkm_example_init(void) {
        create_kmemleak();
        return 0;
}
static void __exit lkm_example_exit(void) {
        printk(KERN_INFO "Goodbye, master!\n");
}
module_init(lkm_example_init);
module_exit(lkm_example_exit);

2.Makefile文件

obj-m := mykMemLeak.o

#和mo块c文件名一致
mykMemLeak-objs := kmemleak.o

#内核源码路径（源码已经make all）
KERNELDIR := /home/taojing/linux5.11.2/src

ARCH := x86

#工具链路径
CROSS_COMPILE := /home/taojing/toolchain/x86_64/x86_64_gcc6.2.0_glibc2.24.0/bin/x86_64-pc-linux-gnu-

#当前路径，编译结果存放地，一般和模块c文件在一个目录
CURENTDIR := $(shell pwd)

default:
        make -C $(KERNELDIR) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) M=$(CURENTDIR) modules

clean:
        @rm -rf $(CURENTDIR)/*.ko
        @rm -rf *.order
        @rm -rf Module.symvers
        @rm -rf *.o
        @rm -rf *.mod*

3.日志报告

在上述模块c文件和Makefile所在目录执行make,就可生成mykMemLeak.ko文件。然后将该模块文件插入qemu启动的内核中。测试程序执行完后，通过rmmod测试模块。手动触发kmemleak扫描，扫描结束后通过cat /sys/kernel/debug/kmemleak查看日志并分析。

#第一处可疑点，泄露128直接的内存
unreferenced object 0xff29455ffdc2e600 (size 128):
  #相关进程信息
  comm "insmod", pid 231, jiffies 4296287062 (age 195.881s)
  #二进制打印
  hex dump (first 32 bytes):
    6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
    6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
  #栈回溯
  backtrace:
    [<00000000f6e38ea2>] 0xffffffffc00ce016
    [<000000001aa41d05>] 0xffffffffc00d3005
    [<00000000be0b8009>]  do_one_initcall+0x47/0x1c0
    [<00000000448019b3>] do_init_module+0x56/0x1ff
    [<00000000ca42473a>] load_module+0x2484/0x29b0
    [<000000008b554566>] __do_sys_init_module+0x152/0x170
    [<000000005dc7a0d1>] do_syscall_64+0x33/0x40
    [<00000000e7ec7f2c>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
unreferenced object 0xff41a8e240045000 (size 4096):
  comm "insmod", pid 231, jiffies 4296287066 (age 195.877s)
  hex dump (first 32 bytes):
    85 00 00 00 01 00 00 00 02 00 00 00 00 00 00 00  ................
    50 f0 0c c0 ff ff ff ff 9a 01 00 00 00 00 00 00  P...............
  backtrace:
    [<00000000def4678d>] __vmalloc_node_range+0x1fe/0x250
    [<0000000051e15033>] __vmalloc_node+0x4b/0x60
    [<000000001aa41d05>] 0xffffffffc00d3005
    [<00000000be0b8009>] do_one_initcall+0x47/0x1c0
    [<00000000448019b3>] do_init_module+0x56/0x1ff
    [<00000000ca42473a>] load_module+0x2484/0x29b0
    [<000000008b554566>] __do_sys_init_module+0x152/0x170
    [<000000005dc7a0d1>] do_syscall_64+0x33/0x40
    [<00000000e7ec7f2c>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

3 KASAN内存检查工具

Kasan(Kernel Address Sanitizer)它是一个动态的内核内存错误检测工具，主要功能是检查内存的越界访问和使用已经释放的内存等问题。同SLUB_DEBUG工具比较,kasan具有下列优点：

  1. 可以检测全局变量、栈、堆分配的内存发生越界访问等问题。
  2. 支持内存问题的实时化检测（在程序运行时kasan能动态监测到内存错误访问并立即生成对应的日志报告）。

ps:kasan暂不支持32位ARM，支持ARM64和X86。

内核配置

CONFIG_SLUB_DEBUG=y
CONFIG_KASAN=y

实例

  1. 源文件：将下列程序编译从ko模块文件，插入配置了kasan工具的linux系统中。

    //kasan_stack_oob.c
#define pr_fmt(fmt) "kasan test: %s " fmt, __func__

#include <linux/kernel.h>
#include <linux/printk.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/module.h>
#include <linux/vmalloc.h>
static noinline void __init kasan_stack_oob(void)
{
	char stack_array[10];
	volatile int i = 0;
	char *p = &stack_array[ARRAY_SIZE(stack_array) + i];

	pr_info("out-of-bounds on stack\n");
	*(volatile char *)p;
}

static int __init kmalloc_tests_init(void)
{
	kasan_stack_oob();
	return -EAGAIN;
}

module_init(kmalloc_tests_init);
MODULE_LICENSE("GPL");

  2. ko模块插入后会在shell终端实时生成如下错误报告：

    [ 2123.786582] kasan test: kasan_stack_oob out-of-bounds on stack
[ 2123.789619] ==================================================================
#错误类型是stack-out-of-bounds，在kasan_stack_oob中产生。
[ 2123.790271] BUG: KASAN: stack-out-of-bounds in kasan_stack_oob+0x9b/0xb8 [testKasan] at addr ffff88003f517a42
[ 2123.790271] Read of size 1 by task insmod/1201
[ 2123.790271] page:ffffea0000fd45c0 count:0 mapcount:0 mapping:          (null) index:0x1
[ 2123.790271] flags: 0x100000000000000()
#非法访问（页）
[ 2123.790271] page dumped because: kasan: bad access detected
[ 2123.790271] CPU: 0 PID: 1201 Comm: insmod Tainted: G        W  O    4.4.157-rt174-CGELV6.03.50B5.20201124 #1
[ 2123.790271] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 2123.790271]  0000000000000000 ffff88003f517928 ffffffff81529f29 0000000000000001
[ 2123.790271]  ffffed0007ea2f48 ffff88003f5179a8 ffffffff812571fa ffffffff811db813
[ 2123.790271]  ffff880027802400 0000000000000246 ffffffffa003809b ffff88003f517988
#问题点的栈回溯
[ 2123.790271] Call Trace:
[ 2123.790271]  [<ffffffff81529f29>] dump_stack+0x59/0x80
[ 2123.790271]  [<ffffffff812571fa>] kasan_report.part.2+0x4ea/0x520
[ 2123.790271]  [<ffffffff811db813>] ? power_down+0xa4/0xa4
[ 2123.790271]  [<ffffffffa003809b>] ? kasan_stack_oob+0x9b/0xb8 [testKasan]
[ 2123.790271]  [<ffffffff8111d897>] ? __trace_hardirqs_off+0x27/0x30
[ 2123.790271]  [<ffffffffa00380b8>] ? kasan_stack_oob+0xb8/0xb8 [testKasan]
[ 2123.790271]  [<ffffffff81257490>] kasan_report+0x20/0x30
[ 2123.790271]  [<ffffffff812564a6>] __asan_load1+0x46/0x50
[ 2123.790271]  [<ffffffffa003809b>] kasan_stack_oob+0x9b/0xb8 [testKasan]
[ 2123.790271]  [<ffffffffa0038000>] ? 0xffffffffa0038000
[ 2123.790271]  [<ffffffff81542aa0>] ? kvasprintf_const+0xc0/0xc0
[ 2123.790271]  [<ffffffff8100040f>] ? do_one_initcall+0xdf/0x240
[ 2123.790271]  [<ffffffff8125370d>] ? kfree+0x15d/0x180
[ 2123.790271]  [<ffffffffa00380c1>] kmalloc_tests_init+0x9/0x10 [testKasan]
[ 2123.790271]  [<ffffffff81000421>] do_one_initcall+0xf1/0x240
[ 2123.790271]  [<ffffffff81000330>] ? try_to_run_init_process+0x40/0x40
[ 2123.790271]  [<ffffffff81256615>] ? kasan_unpoison_shadow+0x35/0x50
[ 2123.790271]  [<ffffffff81256615>] ? kasan_unpoison_shadow+0x35/0x50
[ 2123.790271]  [<ffffffff81256615>] ? kasan_unpoison_shadow+0x35/0x50
[ 2123.790271]  [<ffffffff8125671c>] ? __asan_register_globals+0x7c/0xa0
[ 2123.790271]  [<ffffffff811dbbd2>] do_init_module+0xf4/0x2c8
[ 2123.790271]  [<ffffffff8114e1a4>] load_module+0x3694/0x40a0
[ 2123.790271]  [<ffffffff811488f0>] ? __symbol_put+0xa0/0xa0
[ 2123.790271]  [<ffffffff8114ab10>] ? module_frob_arch_sections+0x20/0x20
[ 2123.790271]  [<ffffffff81e81fb1>] ? __schedule+0x411/0x8e0
[ 2123.790271]  [<ffffffff81e81fa5>] ? __schedule+0x405/0x8e0
[ 2123.790271]  [<ffffffff81e81fb1>] ? __schedule+0x411/0x8e0
[ 2123.790271]  [<ffffffff81e81fa5>] ? __schedule+0x405/0x8e0
[ 2123.790271]  [<ffffffff81e81fb1>] ? __schedule+0x411/0x8e0
[ 2123.790271]  [<ffffffff81e81fa5>] ? __schedule+0x405/0x8e0
[ 2123.790271]  [<ffffffff81e81fb1>] ? __schedule+0x411/0x8e0
[ 2123.790271]  [<ffffffff81e81fa5>] ? __schedule+0x405/0x8e0
[ 2123.790271]  [<ffffffff81e81fb1>] ? __schedule+0x411/0x8e0
[ 2123.790271]  [<ffffffff81e81fa5>] ? __schedule+0x405/0x8e0
[ 2123.790271]  [<ffffffff81e81fb1>] ? __schedule+0x411/0x8e0
[ 2123.790271]  [<ffffffff81e81fa5>] ? __schedule+0x405/0x8e0
[ 2123.790271]  [<ffffffff81e81fb1>] ? __schedule+0x411/0x8e0
[ 2123.790271]  [<ffffffff8114ed35>] SYSC_init_module+0x185/0x1a0
[ 2123.790271]  [<ffffffff8114ebb0>] ? load_module+0x40a0/0x40a0
[ 2123.790271]  [<ffffffff8100226c>] ? exit_to_usermode_loop+0x7c/0xd0
[ 2123.790271]  [<ffffffff8114ee69>] SyS_init_module+0x9/0x10
[ 2123.790271]  [<ffffffff81e8834a>] entry_SYSCALL_64_fastpath+0x1e/0x8e
[ 2123.790271] Memory state around the buggy address:#异常点附近的内存dump
[ 2123.790271]  ffff88003f517900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 2123.790271]  ffff88003f517980: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04
[ 2123.790271] >ffff88003f517a00: f4 f4 f4 f2 f2 f2 f2 00 02 f4 f4 f3 f3 f3 f3 00
[ 2123.790271]                                            ^
[ 2123.790271]  ffff88003f517a80: 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00
[ 2123.790271]  ffff88003f517b00: 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
[ 2123.790271] ==================================================================
[ 2123.790271] Disabling lock debugging due to kernel taint

kasan实现原理

后期分析，参考：http://www.wowotech.net/memory_management/424.html

早起的虫儿有鹰吃
关注
专栏目录
Linux内核态内存泄露检测工具——Kmemleak
Donge's Blog
06-22 1605
在Linux内核开发中，Kmemleak是一种用于检测内核中内存泄漏的工具。内存泄漏指的是程序中已经不再使用的内存没有被妥善地释放，导致内存的浪费。内核中的内存泄漏同样会导致系统性能下降、系统崩溃等问题。Kmemleak能够检测内核中的内存泄漏，通过检测内核中未被释放但又无法找到其使用位置的内存，进一步定位、修复内存泄漏的问题。在用户空间，我们常用Valgrind来检测；在内核空间，我们常用Kmemleak来检测。
Linux内核漏洞检测与防御2022看雪安全开发者峰会(公
11-19
Linux内核漏洞检测与防御2022看雪安全开发者峰会(公开)共56页.pdf.zip
深入了解Linux内存检测技术
m0_74282605的博客
03-16 601
----------------------------------虽然分配32字节，但是对应分配了64字节。在test_code/slub_debug目录下执行make.sh，将slub.ko/slub2.ko/slub3.ko放入data。重复释放可以被slub_debug识别。kasan可以检测到越界访问、访问已释放内存、重复释放等类型错误，其中重复释放借助于slub_debug。kasan是一个动态检查内存错误的工具，可以检查内存越界访问、使用已释放内存、重复释放以及栈溢出。
Linux内存管理 (22)内存检测技术(slub_debug/kmemleak/kasan)
铁匠的七寸宫
10-29 1768
Linux常见的内存访问错误有： 越界访问(out of bounds) 访问已经释放的内存(use after free) 重复释放 内存泄露(memory leak) 栈溢出(stack overflow) 不同的工具有不同的侧重点，本章主要从slub_debug、kmemleak、kasan三个工具介绍。 kmemleak侧重于内存泄露问题发现。 slub_debug和kasan有一定的重复，部分slub_debug问题需要借助slabinfo去发现；kasan更快，所有问题独立上
Linux kernel panic解决方法
JackieGemini
01-31 7816
kernel panic错误表现 kernel panic 主要有以下几个出错提示： Kernel panic-not syncing fatal exception in interrupt kernel panic - not syncing: Attempted to kill the idle task! kernel panic - not syncing: killing in
Linux 内存管理之 SLUB分配器（6）：slub debug 实例测试
And乔的博客
01-10 1844
Linux 内存管理之 SLUB分配器（6）：slub debug 实例测试 1. Object layout slub object layout 之前已经有专门的一小节进行介绍了，这里直接将其结果拿来： 2. 配置开关 默认情况下上述的layout中debug信息是没有打开的，毕竟会增加太多的内容，增加内存的压力，所以需要打开如下部分内容： Config： CONFIG_SLUB=y CONFIG_SLUB_DEBUG=y CONFIG_SLUB_DEBUG_ON=y CONFIG_SLUB_C
Linux内存管理 (22)内存检测技术(slub_debug/kmemleak/kasan)【转】
weixin_34245749的博客
03-21 472
转自：https://www.cnblogs.com/arnoldlu/p/8568090.html 专题：Linux内存管理专题 关键词：slub_debug、kmemleak、kasan、oob、Redzone、Padding。 Linux常见的内存访问错误有： 越界访问(out of bounds) 访问已经释放的内存(use after free) 重复释放 ...
linux 内核 内存泄露检测
09-11
linux 内核 内存泄露检测 linux 内核 内存泄露检测 linux 内核 内存泄露检测 linux 内核 内存泄露检测 linux 内核 内存泄露检测 linux 内核 内存泄露检测 linux 内核 内存泄露检测
Linux内核内存管理.zip
06-05
Linux内核内存管理是操作系统设计的关键部分，它负责有效地分配、使用和回收系统中的物理内存。在Linux系统中，内存管理机制确保了高效且可靠的内存使用，为各个进程提供了一个一致且安全的运行环境。本资料主要探讨...
linux内核内存检测方法实践手记
软工电子行
08-19 546
内存
Linux下内存检测利器Valgrind之Memcheck工具详解
热门推荐
dvlinker的技术专栏
10-16 2万+
Linux下内存检测利器Valgrind之Memcheck工具详解。
TIPS14_内核的一些小概念：idle()的三种实现，内存屏障，need_sched,thread_info,bug_on和warn_on。
芋圆＿钰源
09-20 1108
1.idle()函数的三种可能实现： 1.default_idle():执行hlt指令； 2.poll_idle():如果核心参数上定义了"idle = poll"，则pm_idle会指向poll_idle()，它将need_resched设置为-1，反复循环直到不为-1,比default_idle()效率高。 3.电源管理相关的idle过程：如APM和ACPI模块中定义的idle过程； 2.内存...
内核kernel panic错误定位
zailushangha的专栏
10-18 7331
本文是基于linux2.6.28.6版本内核，使用led驱动和内核定时器驱动模拟灯闪（并且在内核定时器驱动中断函数中使用空指针模拟kernel panic错误）。以报错信息为根据，通过对驱动程序进行反编译与获得的系统中函数对应地址进行对比。从而定位kernel panic是哪里引起的。 一、下面为报错的信息： /usr/local/nbpt/ltx # ./leds_test [ 4000.
Linux kernel slub debug
scutth的专栏
04-13 1271
在device driver开发的过程中，有时候会碰到memory相关的问题，比如memory leak，use after free，out of boundary，double free等等。因为device driver运行在kernel环境，kernel是一个global的runtime，driver分配或者释放的memory都是由kernel负责管理，而且所有的device driver...
SLUB DEBUG 检测slab 内存泄漏
最新发布
一叶知秋的博客
11-07 715
文章介绍如何定位linux 内核中slab 内存泄漏。
KE分析之slub_debug功能使用记录
And乔的博客
05-30 2368
1. 前记 前段时间遇到一个问题，具有一定的代表性，特此记录，后续遇到类似问题时，可以参考这个方向 2. 问题说明 此问题为低概率煲机测试类问题，概率较低，需要长时间的运行才可以触发到，排查起来比较困难； 2.1 测试方法 设置机器为自动化休眠唤醒测试，时间周期为1分钟； usb 口有连接u盘，唤醒后会自动播放u盘内歌曲； 无其他特别步骤 测试时通过串口打印debug信息，另外打开系统中集成的debug功能，即收集logcat + kernel log信息，在遇到anr\je\ne\ke\hwt时会将现场
Linux内核代码(slab.c)分析［转］
weixin_34161029的博客
08-25 171
slab.c来自linux内核2.4.22版，本文件按照GNU协议发布。一、准备知识： 1. slab的概念：* 提出的原因：由于操作系统在运行中会不断产生、使用、释放大量重复的对象， 所以对这样的重复对象的生成进行改进可以大大提高效率 *最早由sun的工程师提出(1994年)并首先在sunos5.4上应用。 2. slab算法的...
Linux内核中使用内存检测
09-20 2597
在内核中提供了内存检测的工具slub与kasan，在开发时可以将检测的功能打开。
内存检测技术(slub_debug/kmemleak/kasan)
biaotai的博客
08-29 1522
关键词：slub_debug、kmemleak、kasan、oob、Redzone、Padding。   Linux常见的内存访问错误有： 越界访问(out of bounds) 访问已经释放的内存(use after free) 重复释放 内存泄露(memory leak) 栈溢出(stack overflow) 不同的工具有不同的侧重点，本章主要从slub_debug、kmemleak、kasan三个工具介绍。 kmemleak侧重于内存泄露问题发现。 slub_debug和kasan有一
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值