Patch "bpf: fix kfunc btf caching for modules" has been added to the 6.6-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    bpf: fix kfunc btf caching for modules

to the 6.6-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     bpf-fix-kfunc-btf-caching-for-modules.patch
and it can be found in the queue-6.6 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 95792cd4e5b7702acba24370c124fe9dd8218e33
Author: Toke Høiland-Jørgensen <toke@xxxxxxxxxx>
Date:   Thu Oct 10 15:27:07 2024 +0200

    bpf: fix kfunc btf caching for modules
    
    [ Upstream commit 6cb86a0fdece87e126323ec1bb19deb16a52aedf ]
    
    The verifier contains a cache for looking up module BTF objects when
    calling kfuncs defined in modules. This cache uses a 'struct
    bpf_kfunc_btf_tab', which contains a sorted list of BTF objects that
    were already seen in the current verifier run, and the BTF objects are
    looked up by the offset stored in the relocated call instruction using
    bsearch().
    
    The first time a given offset is seen, the module BTF is loaded from the
    file descriptor passed in by libbpf, and stored into the cache. However,
    there's a bug in the code storing the new entry: it stores a pointer to
    the new cache entry, then calls sort() to keep the cache sorted for the
    next lookup using bsearch(), and then returns the entry that was just
    stored through the stored pointer. However, because sort() modifies the
    list of entries in place *by value*, the stored pointer may no longer
    point to the right entry, in which case the wrong BTF object will be
    returned.
    
    The end result of this is an intermittent bug where, if a BPF program
    calls two functions with the same signature in two different modules,
    the function from the wrong module may sometimes end up being called.
    Whether this happens depends on the order of the calls in the BPF
    program (as that affects whether sort() reorders the array of BTF
    objects), making it especially hard to track down. Simon, credited as
    reporter below, spent significant effort analysing and creating a
    reproducer for this issue. The reproducer is added as a selftest in a
    subsequent patch.
    
    The fix is straight forward: simply don't use the stored pointer after
    calling sort(). Since we already have an on-stack pointer to the BTF
    object itself at the point where the function return, just use that, and
    populate it from the cache entry in the branch where the lookup
    succeeds.
    
    Fixes: 2357672c54c3 ("bpf: Introduce BPF support for kernel module function calls")
    Reported-by: Simon Sundberg <simon.sundberg@xxxxxx>
    Acked-by: Jiri Olsa <jolsa@xxxxxxxxxx>
    Acked-by: Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx>
    Signed-off-by: Toke Høiland-Jørgensen <toke@xxxxxxxxxx>
    Link: https://lore.kernel.org/r/20241010-fix-kfunc-btf-caching-for-modules-v2-1-745af6c1af98@xxxxxxxxxx
    Signed-off-by: Alexei Starovoitov <ast@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 3032a464d31bb..d1050479cbb33 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2799,10 +2799,16 @@ static struct btf *__find_kfunc_desc_btf(struct bpf_verifier_env *env,
 		b->module = mod;
 		b->offset = offset;
 
+		/* sort() reorders entries by value, so b may no longer point
+		 * to the right entry after this
+		 */
 		sort(tab->descs, tab->nr_descs, sizeof(tab->descs[0]),
 		     kfunc_btf_cmp_by_off, NULL);
+	} else {
+		btf = b->btf;
 	}
-	return b->btf;
+
+	return btf;
 }
 
 void bpf_free_kfunc_btf_tab(struct bpf_kfunc_btf_tab *tab)




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux