Message ID | 20210212005926.2875002-1-yhs@fb.com (mailing list archive) |
---|---|
State | Accepted |
Delegated to: | BPF |
Headers | show |
Series | [bpf] bpf: fix an unitialized value in bpf_iter | expand |
Context | Check | Description |
---|---|---|
netdev/cover_letter | success | Link |
netdev/fixes_present | success | Link |
netdev/patch_count | success | Link |
netdev/tree_selection | success | Clearly marked for bpf |
netdev/subject_prefix | success | Link |
netdev/cc_maintainers | warning | 6 maintainers not CCed: kafai@fb.com netdev@vger.kernel.org songliubraving@fb.com kpsingh@kernel.org john.fastabend@gmail.com andrii@kernel.org |
netdev/source_inline | success | Was 0 now: 0 |
netdev/verify_signedoff | success | Link |
netdev/module_param | success | Was 0 now: 0 |
netdev/build_32bit | success | Errors and warnings before: 1 this patch: 1 |
netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
netdev/verify_fixes | success | Link |
netdev/checkpatch | warning | WARNING: 'unitialized' may be misspelled - perhaps 'uninitialized'? |
netdev/build_allmodconfig_warn | success | Errors and warnings before: 1 this patch: 1 |
netdev/header_inline | success | Link |
netdev/stable | success | Stable not CCed |
On Thu, Feb 11, 2021 at 4:59 PM Yonghong Song <yhs@fb.com> wrote: > > Commit 15d83c4d7cef ("bpf: Allow loading of a bpf_iter program") > cached btf_id in struct bpf_iter_target_info so later on > if it can be checked cheaply compared to checking registered names. > > syzbot found a bug that uninitialized value may occur to > bpf_iter_target_info->btf_id. This is because we allocated > bpf_iter_target_info structure with kmalloc and never initialized > field btf_id afterwards. This uninitialized btf_id is typically > compared to a u32 bpf program func proto btf_id, and the chance > of being equal is extremely slim. > > This patch fixed the issue by using kzalloc which will also > prevent future likely instances due to adding new fields. > > Reported-by: syzbot+580f4f2a272e452d55cb@syzkaller.appspotmail.com > Fixes: 15d83c4d7cef ("bpf: Allow loading of a bpf_iter program") > Signed-off-by: Yonghong Song <yhs@fb.com> Though it's a fix it's too late in the cycle. I've applied to bpf-next.
diff --git a/kernel/bpf/bpf_iter.c b/kernel/bpf/bpf_iter.c index 5454161407f1..a0d9eade9c80 100644 --- a/kernel/bpf/bpf_iter.c +++ b/kernel/bpf/bpf_iter.c @@ -287,7 +287,7 @@ int bpf_iter_reg_target(const struct bpf_iter_reg *reg_info) { struct bpf_iter_target_info *tinfo; - tinfo = kmalloc(sizeof(*tinfo), GFP_KERNEL); + tinfo = kzalloc(sizeof(*tinfo), GFP_KERNEL); if (!tinfo) return -ENOMEM;
Commit 15d83c4d7cef ("bpf: Allow loading of a bpf_iter program") cached btf_id in struct bpf_iter_target_info so later on if it can be checked cheaply compared to checking registered names. syzbot found a bug that uninitialized value may occur to bpf_iter_target_info->btf_id. This is because we allocated bpf_iter_target_info structure with kmalloc and never initialized field btf_id afterwards. This uninitialized btf_id is typically compared to a u32 bpf program func proto btf_id, and the chance of being equal is extremely slim. This patch fixed the issue by using kzalloc which will also prevent future likely instances due to adding new fields. Reported-by: syzbot+580f4f2a272e452d55cb@syzkaller.appspotmail.com Fixes: 15d83c4d7cef ("bpf: Allow loading of a bpf_iter program") Signed-off-by: Yonghong Song <yhs@fb.com> --- kernel/bpf/bpf_iter.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)