CVE-2024-56702: bpf: Mark raw_tp arguments with PTR_MAYBE_NULL

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

bpf: Mark rawtp arguments with PTRMAYBENULL

Arguments to a raw tracepoint are tagged as trusted, which carries the semantics that the pointer will be non-NULL. However, in certain cases, a raw tracepoint argument may end up being NULL. More context about this issue is available in [0].

Thus, there is a discrepancy between the reality, that rawtp arguments can actually be NULL, and the verifier's knowledge, that they are never NULL, causing explicit NULL checks to be deleted, and accesses to such pointers potentially crashing the kernel.

To fix this, mark rawtp arguments as PTRMAYBENULL, and then special case the dereference and pointer arithmetic to permit it, and allow passing them into helpers/kfuncs; these exceptions are made for rawtp programs only. Ensure that we don't do this when refobjid > 0, as in that case this is an acquired object and doesn't need such adjustment.

The reason we do maskrawtptrustedreg logic is because other will recheck in places whether the register is a trustedreg, and then consider our register as untrusted when detecting the presence of the PTRMAYBENULL flag.

To allow safe dereference, we enable PROBEMEM marking when we see loads into trusted pointers with PTRMAYBENULL.

While trusted rawtp arguments can also be passed into helpers or kfuncs where such broken assumption may cause issues, a future patch set will tackle their case separately, as PTRTOBTFID (without PTRTRUSTED) can already be passed into helpers and causes similar problems. Thus, they are left alone for now.

It is possible that these checks also permit passing non-rawtp args that are trusted PTRTOBTFID with null marking. In such a case, allowing dereference when pointer is NULL expands allowed behavior, so won't regress existing programs, and the case of passing these into helpers is the same as above and will be dealt with later.

Also update the failure case in tpbtfnullable selftest to capture the new behavior, as the verifier will no longer cause an error when directly dereference a raw tracepoint argument marked as nullable.

[0]: https://lore.kernel.org/bpf/ZrCZS6nisraEqehw@jlelli-thinkpadt14gen4.remote.csb