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.
Metrics
Affected Vendors & Products
References
History
Wed, 18 Dec 2024 02:15:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Metrics |
threat_severity
|
threat_severity
|
Wed, 23 Oct 2024 21:00:00 +0000
Type | Values Removed | Values Added |
---|---|---|
First Time appeared |
Linux
Linux linux Kernel |
|
Weaknesses | CWE-459 | |
CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
Vendors & Products |
Linux
Linux linux Kernel |
Tue, 22 Oct 2024 01:30:00 +0000
Type | Values Removed | Values Added |
---|---|---|
References |
| |
Metrics |
threat_severity
|
cvssV3_1
|
Mon, 21 Oct 2024 13:15:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Metrics |
ssvc
|
Mon, 21 Oct 2024 12:30:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Description | 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. | |
Title | bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error | |
References |
|
|
MITRE
Status: PUBLISHED
Assigner: Linux
Published: 2024-10-21T12:14:01.012Z
Updated: 2024-12-19T09:26:54.254Z
Reserved: 2024-09-30T16:00:12.957Z
Link: CVE-2024-47728
Vulnrichment
Updated: 2024-10-21T13:00:57.615Z
NVD
Status : Analyzed
Published: 2024-10-21T13:15:02.980
Modified: 2024-10-23T20:36:52.367
Link: CVE-2024-47728
Redhat