regtest for ebpf input validation CVE-2022-23222

[msmeissn]

via oss-sec

The exploit code can be found at https://github.com/tr3ee/CVE-2022-23222

[richiejp]

AFAICT there is no fix for this or #944. We are just relying on /proc/sys/kernel/unprivileged_bpf_disabled > 0?

I'm tempted to say that it's not worth implementing a test that we know will fail unless some setting is applied. OTOH it appears very simple to do the OOB write and corrupt memory. So it can be used to assert /proc/sys/kernel/unprivileged_bpf_disabled should be > 0.

@metan-ucw

[richiejp]

Actually IIRC unprivileged bpf doesn't allow pointer arithmetic after a certain version. So we are not just relying on unprivileged_bpf_disabled

[metan-ucw]

I guess that it makes sense to write the test in a case that the support for userspace eBPF will be enabled back again one day, which may happen one day due to containers.

[richiejp]

Well I reproduced #944 easily. However this one is slightly more complicated and the PoC doesn't quite match the description.

" First, we pass 0xffff........ffff to BPF_FUNC_ringbuf_reserve to get a NULL pointer r0"

However they appear to pass PAGE_SIZE in the PoC. I guess I'm missing something or else this can just be substituted with the correct value. So it shouldn't be too hard either.

Also it turns out I am wrong about ptr arithmetic. It's being expanded and contracted as more code is allowed then denied again when vulnerabilities are found. There are specific fixes for these issues as well.

[richiejp]

Turns out that PAGE_SIZE is too much so it does return 0. Anyway I submitted tests based on both reproducers. Possibly they are just different ways of triggering the same issue.