* [PATCH net] bpf: Fix memory leaks in __check_func_call
@ 2022-10-27 10:23 Wang Yufen
2022-10-27 20:34 ` Andrii Nakryiko
2022-10-28 12:17 ` Dan Carpenter
0 siblings, 2 replies; 4+ messages in thread
From: Wang Yufen @ 2022-10-27 10:23 UTC (permalink / raw)
To: bpf, netdev; +Cc: ast, daniel, john.fastabend, andrii, martin.lau, yhs, joe
kmemleak reports this issue:
unreferenced object 0xffff88817139d000 (size 2048):
comm "test_progs", pid 33246, jiffies 4307381979 (age 45851.820s)
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000045f075f0>] kmalloc_trace+0x27/0xa0
[<0000000098b7c90a>] __check_func_call+0x316/0x1230
[<00000000b4c3c403>] check_helper_call+0x172e/0x4700
[<00000000aa3875b7>] do_check+0x21d8/0x45e0
[<000000001147357b>] do_check_common+0x767/0xaf0
[<00000000b5a595b4>] bpf_check+0x43e3/0x5bc0
[<0000000011e391b1>] bpf_prog_load+0xf26/0x1940
[<0000000007f765c0>] __sys_bpf+0xd2c/0x3650
[<00000000839815d6>] __x64_sys_bpf+0x75/0xc0
[<00000000946ee250>] do_syscall_64+0x3b/0x90
[<0000000000506b7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
The root case here is: In function prepare_func_exit(), the callee is
not released in the abnormal scenario after "state->curframe--;".
In addition, function __check_func_call() has a similar problem. In
the abnormal scenario before "state->curframe++;", the callee is alse
not released.
Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper")
Fixes: fd978bf7fd31 ("bpf: Add reference tracking to verifier")
Signed-off-by: Wang Yufen <wangyufen@huawei.com>
---
kernel/bpf/verifier.c | 25 ++++++++++++++++---------
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 014ee09..bff8477 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -6736,11 +6736,11 @@ static int __check_func_call(struct bpf_verifier_env *env, struct bpf_insn *insn
/* Transfer references to the callee */
err = copy_reference_state(callee, caller);
if (err)
- return err;
+ goto err;
err = set_callee_state_cb(env, caller, callee, *insn_idx);
if (err)
- return err;
+ goto err;
clear_caller_saved_regs(env, caller->regs);
@@ -6757,6 +6757,10 @@ static int __check_func_call(struct bpf_verifier_env *env, struct bpf_insn *insn
print_verifier_state(env, callee, true);
}
return 0;
+
+err:
+ kfree(callee);
+ return err;
}
int map_set_for_each_callback_args(struct bpf_verifier_env *env,
@@ -6954,7 +6958,7 @@ static int prepare_func_exit(struct bpf_verifier_env *env, int *insn_idx)
struct bpf_verifier_state *state = env->cur_state;
struct bpf_func_state *caller, *callee;
struct bpf_reg_state *r0;
- int err;
+ int ret;
callee = state->frame[state->curframe];
r0 = &callee->regs[BPF_REG_0];
@@ -6977,11 +6981,13 @@ static int prepare_func_exit(struct bpf_verifier_env *env, int *insn_idx)
if (r0->type != SCALAR_VALUE) {
verbose(env, "R0 not a scalar value\n");
- return -EACCES;
+ ret = -EACCES;
+ goto out;
}
if (!tnum_in(range, r0->var_off)) {
verbose_invalid_scalar(env, r0, &range, "callback return", "R0");
- return -EINVAL;
+ ret = -EINVAL;
+ goto out;
}
} else {
/* return to the caller whatever r0 had in the callee */
@@ -6995,9 +7001,9 @@ static int prepare_func_exit(struct bpf_verifier_env *env, int *insn_idx)
*/
if (!callee->in_callback_fn) {
/* Transfer references to the caller */
- err = copy_reference_state(caller, callee);
- if (err)
- return err;
+ ret = copy_reference_state(caller, callee);
+ if (ret)
+ goto out;
}
*insn_idx = callee->callsite + 1;
@@ -7008,9 +7014,10 @@ static int prepare_func_exit(struct bpf_verifier_env *env, int *insn_idx)
print_verifier_state(env, caller, true);
}
/* clear everything in the callee */
+out:
free_func_state(callee);
state->frame[state->curframe + 1] = NULL;
- return 0;
+ return ret;
}
static void do_refine_retval_range(struct bpf_reg_state *regs, int ret_type,
--
1.8.3.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH net] bpf: Fix memory leaks in __check_func_call
2022-10-27 10:23 [PATCH net] bpf: Fix memory leaks in __check_func_call Wang Yufen
@ 2022-10-27 20:34 ` Andrii Nakryiko
2022-10-28 1:36 ` wangyufen
2022-10-28 12:17 ` Dan Carpenter
1 sibling, 1 reply; 4+ messages in thread
From: Andrii Nakryiko @ 2022-10-27 20:34 UTC (permalink / raw)
To: Wang Yufen
Cc: bpf, netdev, ast, daniel, john.fastabend, andrii, martin.lau, yhs, joe
On Thu, Oct 27, 2022 at 3:03 AM Wang Yufen <wangyufen@huawei.com> wrote:
>
> kmemleak reports this issue:
>
> unreferenced object 0xffff88817139d000 (size 2048):
> comm "test_progs", pid 33246, jiffies 4307381979 (age 45851.820s)
> hex dump (first 32 bytes):
> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<0000000045f075f0>] kmalloc_trace+0x27/0xa0
> [<0000000098b7c90a>] __check_func_call+0x316/0x1230
> [<00000000b4c3c403>] check_helper_call+0x172e/0x4700
> [<00000000aa3875b7>] do_check+0x21d8/0x45e0
> [<000000001147357b>] do_check_common+0x767/0xaf0
> [<00000000b5a595b4>] bpf_check+0x43e3/0x5bc0
> [<0000000011e391b1>] bpf_prog_load+0xf26/0x1940
> [<0000000007f765c0>] __sys_bpf+0xd2c/0x3650
> [<00000000839815d6>] __x64_sys_bpf+0x75/0xc0
> [<00000000946ee250>] do_syscall_64+0x3b/0x90
> [<0000000000506b7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
>
> The root case here is: In function prepare_func_exit(), the callee is
> not released in the abnormal scenario after "state->curframe--;".
>
> In addition, function __check_func_call() has a similar problem. In
> the abnormal scenario before "state->curframe++;", the callee is alse
> not released.
For prepare_func_exit, wouldn't it be correct and cleaner to just move
state->curframe--; to the very bottom of the function, right when we
free callee and reset frame[] pointer to NULL?
For __check_func_call, please use err_out label name to disambiguate
it from the "err" variable.
>
> Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper")
> Fixes: fd978bf7fd31 ("bpf: Add reference tracking to verifier")
> Signed-off-by: Wang Yufen <wangyufen@huawei.com>
> ---
> kernel/bpf/verifier.c | 25 ++++++++++++++++---------
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
[...]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH net] bpf: Fix memory leaks in __check_func_call
2022-10-27 20:34 ` Andrii Nakryiko
@ 2022-10-28 1:36 ` wangyufen
0 siblings, 0 replies; 4+ messages in thread
From: wangyufen @ 2022-10-28 1:36 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: bpf, netdev, ast, daniel, john.fastabend, andrii, martin.lau, yhs, joe
在 2022/10/28 4:34, Andrii Nakryiko 写道:
> On Thu, Oct 27, 2022 at 3:03 AM Wang Yufen <wangyufen@huawei.com> wrote:
>> kmemleak reports this issue:
>>
>> unreferenced object 0xffff88817139d000 (size 2048):
>> comm "test_progs", pid 33246, jiffies 4307381979 (age 45851.820s)
>> hex dump (first 32 bytes):
>> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> backtrace:
>> [<0000000045f075f0>] kmalloc_trace+0x27/0xa0
>> [<0000000098b7c90a>] __check_func_call+0x316/0x1230
>> [<00000000b4c3c403>] check_helper_call+0x172e/0x4700
>> [<00000000aa3875b7>] do_check+0x21d8/0x45e0
>> [<000000001147357b>] do_check_common+0x767/0xaf0
>> [<00000000b5a595b4>] bpf_check+0x43e3/0x5bc0
>> [<0000000011e391b1>] bpf_prog_load+0xf26/0x1940
>> [<0000000007f765c0>] __sys_bpf+0xd2c/0x3650
>> [<00000000839815d6>] __x64_sys_bpf+0x75/0xc0
>> [<00000000946ee250>] do_syscall_64+0x3b/0x90
>> [<0000000000506b7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
>>
>> The root case here is: In function prepare_func_exit(), the callee is
>> not released in the abnormal scenario after "state->curframe--;".
>>
>> In addition, function __check_func_call() has a similar problem. In
>> the abnormal scenario before "state->curframe++;", the callee is alse
>> not released.
> For prepare_func_exit, wouldn't it be correct and cleaner to just move
> state->curframe--; to the very bottom of the function, right when we
> free callee and reset frame[] pointer to NULL?
Yes, that't better. will change and test in v2.
> For __check_func_call, please use err_out label name to disambiguate
> it from the "err" variable.
I got it. will change in v2.
>
>> Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper")
>> Fixes: fd978bf7fd31 ("bpf: Add reference tracking to verifier")
>> Signed-off-by: Wang Yufen <wangyufen@huawei.com>
>> ---
>> kernel/bpf/verifier.c | 25 ++++++++++++++++---------
>> 1 file changed, 16 insertions(+), 9 deletions(-)
>>
> [...]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH net] bpf: Fix memory leaks in __check_func_call
2022-10-27 10:23 [PATCH net] bpf: Fix memory leaks in __check_func_call Wang Yufen
2022-10-27 20:34 ` Andrii Nakryiko
@ 2022-10-28 12:17 ` Dan Carpenter
1 sibling, 0 replies; 4+ messages in thread
From: Dan Carpenter @ 2022-10-28 12:17 UTC (permalink / raw)
To: oe-kbuild, Wang Yufen, bpf, netdev
Cc: lkp, oe-kbuild-all, ast, daniel, john.fastabend, andrii,
martin.lau, yhs, joe
Hi Wang,
url: https://github.com/intel-lab-lkp/linux/commits/Wang-Yufen/bpf-Fix-memory-leaks-in-__check_func_call/20221027-180438
patch link: https://lore.kernel.org/r/1666866213-4394-1-git-send-email-wangyufen%40huawei.com
patch subject: [PATCH net] bpf: Fix memory leaks in __check_func_call
config: openrisc-randconfig-m031-20221026
compiler: or1k-linux-gcc (GCC) 12.1.0
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
smatch warnings:
kernel/bpf/verifier.c:7021 prepare_func_exit() error: uninitialized symbol 'ret'.
vim +/ret +7021 kernel/bpf/verifier.c
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6957 static int prepare_func_exit(struct bpf_verifier_env *env, int *insn_idx)
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6958 {
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6959 struct bpf_verifier_state *state = env->cur_state;
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6960 struct bpf_func_state *caller, *callee;
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6961 struct bpf_reg_state *r0;
7e03dd8c129a0d Wang Yufen 2022-10-27 6962 int ret;
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6963
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6964 callee = state->frame[state->curframe];
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6965 r0 = &callee->regs[BPF_REG_0];
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6966 if (r0->type == PTR_TO_STACK) {
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6967 /* technically it's ok to return caller's stack pointer
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6968 * (or caller's caller's pointer) back to the caller,
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6969 * since these pointers are valid. Only current stack
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6970 * pointer will be invalid as soon as function exits,
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6971 * but let's be conservative
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6972 */
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6973 verbose(env, "cannot return stack pointer to the caller\n");
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6974 return -EINVAL;
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6975 }
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6976
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6977 state->curframe--;
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6978 caller = state->frame[state->curframe];
69c087ba6225b5 Yonghong Song 2021-02-26 6979 if (callee->in_callback_fn) {
69c087ba6225b5 Yonghong Song 2021-02-26 6980 /* enforce R0 return value range [0, 1]. */
1bfe26fb082724 Dave Marchevsky 2022-09-08 6981 struct tnum range = callee->callback_ret_range;
69c087ba6225b5 Yonghong Song 2021-02-26 6982
69c087ba6225b5 Yonghong Song 2021-02-26 6983 if (r0->type != SCALAR_VALUE) {
69c087ba6225b5 Yonghong Song 2021-02-26 6984 verbose(env, "R0 not a scalar value\n");
7e03dd8c129a0d Wang Yufen 2022-10-27 6985 ret = -EACCES;
7e03dd8c129a0d Wang Yufen 2022-10-27 6986 goto out;
69c087ba6225b5 Yonghong Song 2021-02-26 6987 }
69c087ba6225b5 Yonghong Song 2021-02-26 6988 if (!tnum_in(range, r0->var_off)) {
69c087ba6225b5 Yonghong Song 2021-02-26 6989 verbose_invalid_scalar(env, r0, &range, "callback return", "R0");
7e03dd8c129a0d Wang Yufen 2022-10-27 6990 ret = -EINVAL;
7e03dd8c129a0d Wang Yufen 2022-10-27 6991 goto out;
69c087ba6225b5 Yonghong Song 2021-02-26 6992 }
69c087ba6225b5 Yonghong Song 2021-02-26 6993 } else {
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6994 /* return to the caller whatever r0 had in the callee */
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6995 caller->regs[BPF_REG_0] = *r0;
69c087ba6225b5 Yonghong Song 2021-02-26 6996 }
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 6997
9d9d00ac29d0ef Kumar Kartikeya Dwivedi 2022-08-23 6998 /* callback_fn frame should have released its own additions to parent's
9d9d00ac29d0ef Kumar Kartikeya Dwivedi 2022-08-23 6999 * reference state at this point, or check_reference_leak would
9d9d00ac29d0ef Kumar Kartikeya Dwivedi 2022-08-23 7000 * complain, hence it must be the same as the caller. There is no need
9d9d00ac29d0ef Kumar Kartikeya Dwivedi 2022-08-23 7001 * to copy it back.
9d9d00ac29d0ef Kumar Kartikeya Dwivedi 2022-08-23 7002 */
9d9d00ac29d0ef Kumar Kartikeya Dwivedi 2022-08-23 7003 if (!callee->in_callback_fn) {
fd978bf7fd3125 Joe Stringer 2018-10-02 7004 /* Transfer references to the caller */
7e03dd8c129a0d Wang Yufen 2022-10-27 7005 ret = copy_reference_state(caller, callee);
7e03dd8c129a0d Wang Yufen 2022-10-27 7006 if (ret)
7e03dd8c129a0d Wang Yufen 2022-10-27 7007 goto out;
9d9d00ac29d0ef Kumar Kartikeya Dwivedi 2022-08-23 7008 }
Not initialized on else path.
fd978bf7fd3125 Joe Stringer 2018-10-02 7009
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 7010 *insn_idx = callee->callsite + 1;
06ee7115b0d174 Alexei Starovoitov 2019-04-01 7011 if (env->log.level & BPF_LOG_LEVEL) {
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 7012 verbose(env, "returning from callee:\n");
0f55f9ed21f966 Christy Lee 2021-12-16 7013 print_verifier_state(env, callee, true);
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 7014 verbose(env, "to caller at %d:\n", *insn_idx);
0f55f9ed21f966 Christy Lee 2021-12-16 7015 print_verifier_state(env, caller, true);
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 7016 }
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 7017 /* clear everything in the callee */
7e03dd8c129a0d Wang Yufen 2022-10-27 7018 out:
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 7019 free_func_state(callee);
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 7020 state->frame[state->curframe + 1] = NULL;
7e03dd8c129a0d Wang Yufen 2022-10-27 @7021 return ret;
f4d7e40a5b7157 Alexei Starovoitov 2017-12-14 7022 }
--
0-DAY CI Kernel Test Service
https://01.org/lkp
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-10-28 12:20 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-27 10:23 [PATCH net] bpf: Fix memory leaks in __check_func_call Wang Yufen
2022-10-27 20:34 ` Andrii Nakryiko
2022-10-28 1:36 ` wangyufen
2022-10-28 12:17 ` Dan Carpenter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).