summaryrefslogtreecommitdiff
path: root/Documentation/bpf/index.rst
diff options
context:
space:
mode:
authorYonghong Song <yhs@fb.com>2022-12-03 12:49:54 -0800
committerAlexei Starovoitov <ast@kernel.org>2022-12-04 12:59:58 -0800
commitc0c852dd1876dc1db4600ce951a92aadd3073b1c (patch)
tree3125aa4faf137b73126d0ee881bad47a54a46f13 /Documentation/bpf/index.rst
parent1910676cc1ec29fad850448ead0fffdb93fb74b5 (diff)
bpf: Do not mark certain LSM hook arguments as trusted
Martin mentioned that the verifier cannot assume arguments from LSM hook sk_alloc_security being trusted since after the hook is called, the sk ref_count is set to 1. This will overwrite the ref_count changed by the bpf program and may cause ref_count underflow later on. I then further checked some other hooks. For example, for bpf_lsm_file_alloc() hook in fs/file_table.c, f->f_cred = get_cred(cred); error = security_file_alloc(f); if (unlikely(error)) { file_free_rcu(&f->f_rcuhead); return ERR_PTR(error); } atomic_long_set(&f->f_count, 1); The input parameter 'f' to security_file_alloc() cannot be trusted as well. Specifically, I investiaged bpf_map/bpf_prog/file/sk/task alloc/free lsm hooks. Except bpf_map_alloc and task_alloc, arguments for all other hooks should not be considered as trusted. This may not be a complete list, but it covers common usage for sk and task. Fixes: 3f00c5239344 ("bpf: Allow trusted pointers to be passed to KF_TRUSTED_ARGS kfuncs") Signed-off-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/r/20221203204954.2043348-1-yhs@fb.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Diffstat (limited to 'Documentation/bpf/index.rst')
0 files changed, 0 insertions, 0 deletions