CVE-2024-47728

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() were readding the issue were 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.

Weakness

The product does not properly “clean up” and remove temporary or supporting resources after they have been used.

Affected Software

Potential Mitigations

References

• https://git.kernel.org/stable/c/4b3786a6c5397dc220b1483d8e2f4867743e966f
• https://git.kernel.org/stable/c/594a9f5a8d2de2573a856e506f77ba7dd2cefc6a
• https://git.kernel.org/stable/c/599d15b6d03356a97bff7a76155c5604c42a2962
• https://git.kernel.org/stable/c/8397bf78988f3ae9dbebb0200189a62a57264980
• https://git.kernel.org/stable/c/a634fa8e480ac2423f86311a602f6295df2c8ed0