CVE-2022-49985

Source
https://cve.org/CVERecord?id=CVE-2022-49985
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2022-49985.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2022-49985
Downstream
Related
Published
2025-06-18T11:00:47.251Z
Modified
2026-04-11T12:44:45.577889Z
Summary
bpf: Don't use tnum_range on array range checking for poke descriptors
Details

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 bpfprog_load+0x102f/0x2220 ? __bpfprogput.constprop.0+0x220/0x220 ? findheldlock+0x2c/0x110 ? __mightfault+0xd6/0x180 ? lockdowngrade+0x6e0/0x6e0 ? lock_isheldtype+0xa6/0x120 ? __might_fault+0x147/0x180 __sysbpf+0x137b/0x6070 ? bpfperflinkattach+0x530/0x530 ? newsyncread+0x600/0x600 ? __fgetfiles+0x255/0x450 ? lockdowngrade+0x6e0/0x6e0 ? fput+0x30/0x1a0 ? ksys_write+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.

Database specific
{
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/49xxx/CVE-2022-49985.json",
    "cna_assigner": "Linux"
}
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b
Fixed
e8979807178434db8ceaa84dfcd44363e71e50bb
Fixed
4f672112f8665102a5842c170be1713f8ff95919
Fixed
a36df92c7ff7ecde2fb362241d0ab024dddd0597
Fixed
a657182a5c5150cdfacb6640aad1d2712571a409

Database specific

source
"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2022-49985.json"

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
5.5.0
Fixed
5.10.140
Type
ECOSYSTEM
Events
Introduced
5.11.0
Fixed
5.15.64
Type
ECOSYSTEM
Events
Introduced
5.16.0
Fixed
5.19.6

Database specific

source
"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2022-49985.json"