CVE-2024-47728

bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error

published October 21, 2024

CVSS
—
EPSS
0%
Percentile
13.7
In the wild
Unconfirmed
What it is

In the Linux kernel, the following vulnerability has been resolved:

bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error

For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input

arguments, zero the value for the case of an error as otherwise it could leak

memory. For tracing, it is not needed given CAP_PERFMON can already read all

kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped

in here.

Also, the MTU helpers mtu_len pointer value is being written but also read.

Technically, the MEM_UNINIT should not be there in order to always force init.

Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now

implies two things actually: i) write into memory, ii) memory does not have

to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory,

ii) memory must be initialized. This means that for bpf_*_check_mtu() we're

readding the issue we're trying to fix, that is, it would then be able to

write back into things like .rodata BPF maps. Follow-up work will rework the

MEM_UNINIT semantics such that the intent can be better expressed. For now

just clear the *mtu_len on error path which can be lifted later again.

The record
Technical detail
CVSS
Not scored
CVSS v4.0
Not supplied
EPSS
0.00236 · 13.7th percentile
Published
2024-10-21T12:14Z
EPSS history
Timeline
  • 21 OCT 12:14Z
    bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error
    cvelistv5