Commit e3857414 authored by Zheng Yejian's avatar Zheng Yejian Committed by Zheng Zengkai
Browse files

livepatch: Fix issues in klp_mem_{prepare,recycle}

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4UAQ1



--------------------------------

There are several issues in klp_mem_{prepare,recycle}:
  1. Memory leak when save old codes fail:
    __klp_enable_patch
        klp_mem_prepare
            klp_for_each_func(patch)
                func->func_node = kzalloc(...)    <-- 1. Alloc memory
        stop_machine(klp_try_enable_patch, ...)
            enable_patch
                arch_klp_patch_func
                    INIT_LIST_HEAD(&func_node->func_stack); <-- 2. func_stack list inited as empty
                    copy_from_kernel_nofault    <-- 3. When save codes fail
        klp_mem_recycle
            klp_for_each_func(patch)
                <-- 4. Here func_stack list is empty but not singular, 'func_node' not be freed!!!
                if (func_node && list_is_singular(&func_node->func_stack))
                    kfree(func_node);

  2. Memory leak in following scene:
     Suppose P1/P2 want to patch same old func, then enable P1 --> enable P2 --> disable P2 --> disable P1
  3. UAF(use-after-free) happened in following scene:
     Suppose P1/P2 want to patch same old func, then enable P1 --> enable P2 --> disable P1 --> disable P2

Above problems are introduced in commit ec7ce700674f ("[Huawei] livepatch:
put memory alloc and free out stop machine"):
  before it: 'func_node' is only keep in 'klp_func_list';
  after it: 'func_node' is keep both in 'klp_func_list' and 'struct klp_func', and
            conditions to free memory of 'func_node' somewhat wrong.

To resolve it, we add check and do func_node init when klp_mem_prepare.

Fixes: ("000c0197 livepatch: put memory alloc and free out stop machine")
Signed-off-by: default avatarZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: default avatarKuohai Xu <xukuohai@huawei.com>
Signed-off-by: default avatarZheng Zengkai <zhengzengkai@huawei.com>
parent 8bedd284
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment