LiveActive security incident?Get immediate response
CVE Record

CVE-2022-49985: bpf: Don't use tnum_range on array range checking for poke descriptors

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 bpf_int_jit_compile+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> dump_stack_lvl+0x9c/0xc9 print_address_description.constprop.0+0x1f/0x1f0 ? bpf_int_jit_compile+0x1257/0x13f0 kasan_report.cold+0xeb/0x197 ? kvmalloc_node+0x170/0x200 ? bpf_int_jit_compile+0x1257/0x13f0 bpf_int_jit_compile+0x1257/0x13f0 ? arch_prepare_bpf_dispatcher+0xd0/0xd0 ? rcu_read_lock_sched_held+0x43/0x70 bpf_prog_select_runtime+0x3e8/0x640 ? bpf_obj_name_cpy+0x149/0x1b0 bpf_prog_load+0x102f/0x2220 ? __bpf_prog_put.constprop.0+0x220/0x220 ? find_held_lock+0x2c/0x110 ? __might_fault+0xd6/0x180 ? lock_downgrade+0x6e0/0x6e0 ? lock_is_held_type+0xa6/0x120 ? __might_fault+0x147/0x180 __sys_bpf+0x137b/0x6070 ? bpf_perf_link_attach+0x530/0x530 ? new_sync_read+0x600/0x600 ? __fget_files+0x255/0x450 ? lock_downgrade+0x6e0/0x6e0 ? fput+0x30/0x1a0 ? ksys_write+0x1a8/0x260 __x64_sys_bpf+0x7a/0xc0 ? syscall_enter_from_user_mode+0x21/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f917c4e2c2d The problem here is that a range of tnum_range(0, map->max_entries - 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 tnum_in(range, reg->var_off) check may yield true when it shouldn't, for example tnum_range(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->var_off.value for the upper index check.

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysisunknown

Security readout for executives and security teams

Plain-English summary

This Linux kernel issue is a bounds-checking mistake in BPF JIT handling. A crafted BPF program can make the kernel read outside an expected array while compiling, shown by a KASAN crash report. The public data does not provide CVSS, CWE, confirmed exploitation, or impact beyond the out-of-bounds read/crash evidence.

Executive priority

Treat this as a kernel hygiene issue requiring normal vulnerability management attention, not emergency response, unless your environment exposes BPF loading to untrusted users. The absence of CVSS and exploitation evidence limits urgency certainty.

Technical view

The bug is in BPF poke descriptor array range checking. The kernel used tnum_range to represent an index range, but that representation can include values outside the intended concrete range. For known constant scalar registers, the fix uses reg->var_off.value for the upper index check instead of relying on tnum_in over an imprecise range.

Likely exposure

Exposure is most relevant to Linux systems running affected kernel version data listed in the CVE bundle and permitting BPF program loading. The source names Linux kernel branches/versions and stable fix commits, but distro-specific exposure requires vendor kernel mapping and backport verification.

Exploitation context

The source evidence is a customized syzkaller-based BPF runtime fuzzer triggering a KASAN slab out-of-bounds read. CISA KEV status is false in the bundle, and no cited source claims active exploitation or a public exploit.

Researcher notes

The key technical nuance is tnum imprecision: tnum_range(0, 2) can represent a superset including 3. That allowed an array range check to pass incorrectly for poke descriptors. Available evidence supports memory-safety failure during BPF JIT compilation, not broader impact claims.

Mitigation direction

  • Review vendor kernel advisories for CVE-2022-49985 and applicable backports.
  • Update Linux kernels to vendor releases containing the referenced stable fixes.
  • Where feasible, restrict BPF program loading to trusted administrative contexts.
  • Track distribution-specific kernel package status before declaring remediation complete.

Validation and detection

  • Inventory Linux kernel versions and distribution package releases across exposed systems.
  • Map installed kernels to vendor advisories or the referenced stable fix commits.
  • Check whether untrusted users can load BPF programs on each host class.
  • Confirm post-update kernels include the vendor fix or equivalent backport.
Prepared
Confidence
medium
Sources
6

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2022-49985 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
0ADP providers
5Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinuxd2e4c1e6c2947269346054ac8937ccfe9e0bcc6b, d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b, d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b, d2e4c1e6c2947269346054ac8937ccfe9e0bcc6bunaffected
LinuxLinux5.5, 0, 5.10.140, 5.15.64, 5.19.6, 6.0affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.