CVE-2021-47303

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

bpf: Track subprog poke descriptors correctly and fix use-after-free

Subprograms are calling mappoketrack(), but on program release there is no hook to call mappokeuntrack(). However, on program release, the aux memory (and poke descriptor table) is freed even though we still have a reference to it in the element list of the map aux data. When we run mappokerun(), we then end up accessing free'd memory, triggering KASAN in progarraymappokerun():

[...] [ 402.824689] BUG: KASAN: use-after-free in progarraymappokerun+0xc2/0x34e [ 402.824698] Read of size 4 at addr ffff8881905a7940 by task hubble-fgs/4337 [ 402.824705] CPU: 1 PID: 4337 Comm: hubble-fgs Tainted: G I 5.12.0+ #399 [ 402.824715] Call Trace: [ 402.824719] dumpstack+0x93/0xc2 [ 402.824727] printaddressdescription.constprop.0+0x1a/0x140 [ 402.824736] ? progarraymappokerun+0xc2/0x34e [ 402.824740] ? progarraymappokerun+0xc2/0x34e [ 402.824744] kasanreport.cold+0x7c/0xd8 [ 402.824752] ? progarraymappokerun+0xc2/0x34e [ 402.824757] progarraymappokerun+0xc2/0x34e [ 402.824765] bpffdarraymapupdate_elem+0x124/0x1a0 [...]

The elements concerned are walked as follows:

for (i = 0; i < elem->aux->size_poke_tab; i++) {
       poke = &elem->aux->poke_tab[i];
[...]

The access to sizepoketab is a 4 byte read, verified by checking offsets in the KASAN dump:

[ 402.825004] The buggy address belongs to the object at ffff8881905a7800 which belongs to the cache kmalloc-1k of size 1024 [ 402.825008] The buggy address is located 320 bytes inside of 1024-byte region [ffff8881905a7800, ffff8881905a7c00)

The pahole output of bpfprogaux:

struct bpfprogaux { [...] /* --- cacheline 5 boundary (320 bytes) --- / u32 size_poke_tab; / 320 4 */ [...]

In general, subprograms do not necessarily manage their own data structures. For example, BTF funcinfo and linfo are just pointers to the main program structure. This allows reference counting and cleanup to be done on the latter which simplifies their management a bit. The aux->poketab struct, however, did not follow this logic. The initial proposed fix for this use-after-free bug further embedded poke data tracking into the subprogram with proper reference counting. However, Daniel and Alexei questioned why we were treating these objects special; I agree, its unnecessary. The fix here removes the per subprogram poke table allocation and map tracking and instead simply points the aux->poke_tab pointer at the main programs poke table. This way, map tracking is simplified to the main program and we do not need to manage them per subprogram.

This also means, bpfprogfreedeferred(), which unwinds the program reference counting and kfrees objects, needs to ensure that we don't try to double free the poketab when free'ing the subprog structures. This is easily solved by NULL'ing the poketab pointer. The second detail is to ensure that per subprogram JIT logic only does fixups on poketab[] entries it owns. To do this, we add a pointer in the poke structure to point at the subprogram value so JITs can easily check while walking the poketab structure if the current entry belongs to the current program. The aux pointer is stable and therefore suitable for such comparison. On the jitsubprogs() error path, we omit cleaning up the poke->aux field because these are only ever referenced from the JIT side, but on error we will never make it to the JIT, so its fine to leave them dangling. Removing these pointers would complicate the error path for no reason. However, we do need to untrack all poke descriptors from the main program as otherwise they could race with the freeing of JIT memory from the subprograms. Lastly, a748c6975dea3 ("bpf: propagate poke des ---truncated---