CVE-2024-47728: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error

Severity: medium (CVSS 5.5 v3.1)
Exploited in the wild: not listed in CISA KEV
EPSS: 0.2% probability of exploitation in the next 30 days
Public exploit or detection template: none known
Published: 2024-10-21 · updated 2026-06-17
Weakness: CWE-459

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.

Affected products

Linux kernel: from 5.2 before 6.1.113; from 6.2 before 6.6.54; from 6.7 before 6.10.13; from 6.11 before 6.11.2 — fixed in 6.1.113, 6.10.13, 6.11.2, 6.6.54

How to fix

Upgrade to a fixed version: Linux kernel 6.1.113, 6.10.13, 6.11.2, 6.6.54. Check the vendor advisory for mitigations.

References

Get alerted when CVE-2024-47728 or the next vulnerability affects your stack