In the Linux kernel, the following vulnerability has been resolved:
bpf: Don't use tnum_range on array range checking for poke descriptors
Hsin-Wei reported a KASAN splat triggered by their BPF runtime fuzzer which is based on a customized syzkaller:
BUG: KASAN: slab-out-of-bounds in bpfintjitcompile+0x1257/0x13f0 Read of size 8 at addr ffff888004e90b58 by task syz-executor.0/1489 CPU: 1 PID: 1489 Comm: syz-executor.0 Not tainted 5.19.0 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x9c/0xc9 printaddressdescription.constprop.0+0x1f/0x1f0 ? bpfintjitcompile+0x1257/0x13f0 kasanreport.cold+0xeb/0x197 ? kvmallocnode+0x170/0x200 ? bpfintjitcompile+0x1257/0x13f0 bpfintjitcompile+0x1257/0x13f0 ? archpreparebpfdispatcher+0xd0/0xd0 ? rcureadlockschedheld+0x43/0x70 bpfprogselectruntime+0x3e8/0x640 ? bpfobjnamecpy+0x149/0x1b0 bpfprogload+0x102f/0x2220 ? _bpfprogput.constprop.0+0x220/0x220 ? findheldlock+0x2c/0x110 ? _mightfault+0xd6/0x180 ? lockdowngrade+0x6e0/0x6e0 ? lockisheldtype+0xa6/0x120 ? _mightfault+0x147/0x180 _sysbpf+0x137b/0x6070 ? bpfperflinkattach+0x530/0x530 ? newsyncread+0x600/0x600 ? _fgetfiles+0x255/0x450 ? lockdowngrade+0x6e0/0x6e0 ? fput+0x30/0x1a0 ? ksyswrite+0x1a8/0x260 _x64sysbpf+0x7a/0xc0 ? syscallenterfromusermode+0x21/0x70 dosyscall64+0x3b/0x90 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x7f917c4e2c2d
The problem here is that a range of tnumrange(0, map->maxentries - 1) has limited ability to represent the concrete tight range with the tnum as the set of resulting states from value + mask can result in a superset of the actual intended range, and as such a tnumin(range, reg->varoff) check may yield true when it shouldn't, for example tnumrange(0, 2) would result in 00XX -> v = 0000, m = 0011 such that the intended set of {0, 1, 2} is here represented by a less precise superset of {0, 1, 2, 3}. As the register is known const scalar, really just use the concrete reg->varoff.value for the upper index check.