Skip to main content
← All vulnerabilities
CVE-2024-58098

bpf: track changes_pkt_data property for global functions

Published
Last modified
published
Not listed in CISA KEV
Fix
Fixed in 6.6.90, 6.12.25
None on Exploit-DB, Metasploit or GitHub
  • Exploitation: none
  • Automatable: no
  • Technical impact: total

Summary

In the Linux kernel, the following vulnerability has been resolved: bpf: track changes_pkt_data property for global functions When processing calls to certain helpers, verifier invalidates all packet pointers in a current state. For example, consider the following program: attribute((noinline)) long skb_pull_data(struct __sk_buff *sk, __u32 len) { return bpf_skb_pull_data(sk, len); } SEC("tc") int test_invalidate_checks(struct __sk_buff *sk) { int p = (void )(long)sk->data; if ((void )(p + 1) > (void )(long)sk->data_end) return TCX_DROP; skb_pull_data(sk, 0); *p = 42; return TCX_PASS; } After a call to bpf_skb_pull_data() the pointer 'p' can't be used safely. See function filter.c:bpf_helper_changes_pkt_data() for a list of such helpers. At the moment verifier invalidates packet pointers when processing helper function calls, and does not traverse global sub-programs when processing calls to global sub-programs. This means that calls to helpers done from global sub-programs do not invalidate pointers in the caller state. E.g. the program above is unsafe, but is not rejected by verifier. This commit fixes the omission by computing field bpf_subprog_info->changes_pkt_data for each sub-program before main verification pass. changes_pkt_data should be set if: • subprogram calls helper for which bpf_helper_changes_pkt_data returns true; • subprogram calls a global function, for which bpf_subprog_info->changes_pkt_data should be set. The verifier.c:check_cfg() pass is modified to compute this information. The commit relies on depth first instruction traversal done by check_cfg() and absence of recursive function calls: • check_cfg() would eventually visit every call to subprogram S in a state when S is fully explored; • when S is fully explored: • every direct helper call within S is explored (and thus changes_pkt_data is set if needed); • every call to subprogram S1 called by S was visited with S1 fully explored (and thus S inherits changes_pkt_data from S1). The downside of such approach is that dead code elimination is not taken into account: if a helper call inside global function is dead because of current configuration, verifier would conservatively assume that the call occurs for the purpose of the changes_pkt_data computation.

Timeline

  1. CVE published
  2. CISA SSVC assessment

    Exploitation: none · Automatable: no · Technical impact: total

  3. Record last updated

Affected versions

  • Linux Linux

    From 51c39bb1d5d105a02e29aa7960f0a395086e6342 · fixed in 79751e9227a5910c0e5a2c7186877d91821d957d; From 51c39bb1d5d105a02e29aa7960f0a395086e6342 · fixed in 1d572c60488b52882b719ed273767ee3b280413d; From 51c39bb1d5d105a02e29aa7960f0a395086e6342 · fixed in 51081a3f25c742da5a659d7fc6fd77ebfdd555be

  • Linux Linux

    5.6

  • KernelLinux

    From 5.6.0 · fixed in 6.6.90; From 6.7.0 · fixed in 6.12.25

References 3

git.kernel.org