GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

CVE-2022-49985 (GCVE-0-2022-49985)

Vulnerability from cvelistv5 – Published: 2025-06-18 11:00 – Updated: 2026-08-05 08:57
VLAI
Title
bpf: Don't use tnum_range on array range checking for poke descriptors
Summary
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.
Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Assigner
References
Impacted products
Vendor Product Version CPE status
Linux Linux Affected: d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b , < e8979807178434db8ceaa84dfcd44363e71e50bb (git)
Affected: d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b , < 4f672112f8665102a5842c170be1713f8ff95919 (git)
Affected: d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b , < a36df92c7ff7ecde2fb362241d0ab024dddd0597 (git)
Affected: d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b , < a657182a5c5150cdfacb6640aad1d2712571a409 (git)
guessed Create a notification for this product.
Linux Linux Affected: 5.5
Unaffected: 0 , < 5.5 (semver)
Unaffected: 5.10.140 , ≤ 5.10.* (semver)
Unaffected: 5.15.64 , ≤ 5.15.* (semver)
Unaffected: 5.19.6 , ≤ 5.19.* (semver)
Unaffected: 6.0 , ≤ * (original_commit_for_fix)
guessed Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "kernel/bpf/verifier.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "e8979807178434db8ceaa84dfcd44363e71e50bb",
              "status": "affected",
              "version": "d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b",
              "versionType": "git"
            },
            {
              "lessThan": "4f672112f8665102a5842c170be1713f8ff95919",
              "status": "affected",
              "version": "d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b",
              "versionType": "git"
            },
            {
              "lessThan": "a36df92c7ff7ecde2fb362241d0ab024dddd0597",
              "status": "affected",
              "version": "d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b",
              "versionType": "git"
            },
            {
              "lessThan": "a657182a5c5150cdfacb6640aad1d2712571a409",
              "status": "affected",
              "version": "d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "kernel/bpf/verifier.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.5"
            },
            {
              "lessThan": "5.5",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.140",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.64",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.19.*",
              "status": "unaffected",
              "version": "5.19.6",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.0",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.140",
                  "versionStartIncluding": "5.5",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.64",
                  "versionStartIncluding": "5.5",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.19.6",
                  "versionStartIncluding": "5.5",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.0",
                  "versionStartIncluding": "5.5",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Don\u0027t use tnum_range on array range checking for poke descriptors\n\nHsin-Wei reported a KASAN splat triggered by their BPF runtime fuzzer which\nis based on a customized syzkaller:\n\n  BUG: KASAN: slab-out-of-bounds in bpf_int_jit_compile+0x1257/0x13f0\n  Read of size 8 at addr ffff888004e90b58 by task syz-executor.0/1489\n  CPU: 1 PID: 1489 Comm: syz-executor.0 Not tainted 5.19.0 #1\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n  1.13.0-1ubuntu1.1 04/01/2014\n  Call Trace:\n   \u003cTASK\u003e\n   dump_stack_lvl+0x9c/0xc9\n   print_address_description.constprop.0+0x1f/0x1f0\n   ? bpf_int_jit_compile+0x1257/0x13f0\n   kasan_report.cold+0xeb/0x197\n   ? kvmalloc_node+0x170/0x200\n   ? bpf_int_jit_compile+0x1257/0x13f0\n   bpf_int_jit_compile+0x1257/0x13f0\n   ? arch_prepare_bpf_dispatcher+0xd0/0xd0\n   ? rcu_read_lock_sched_held+0x43/0x70\n   bpf_prog_select_runtime+0x3e8/0x640\n   ? bpf_obj_name_cpy+0x149/0x1b0\n   bpf_prog_load+0x102f/0x2220\n   ? __bpf_prog_put.constprop.0+0x220/0x220\n   ? find_held_lock+0x2c/0x110\n   ? __might_fault+0xd6/0x180\n   ? lock_downgrade+0x6e0/0x6e0\n   ? lock_is_held_type+0xa6/0x120\n   ? __might_fault+0x147/0x180\n   __sys_bpf+0x137b/0x6070\n   ? bpf_perf_link_attach+0x530/0x530\n   ? new_sync_read+0x600/0x600\n   ? __fget_files+0x255/0x450\n   ? lock_downgrade+0x6e0/0x6e0\n   ? fput+0x30/0x1a0\n   ? ksys_write+0x1a8/0x260\n   __x64_sys_bpf+0x7a/0xc0\n   ? syscall_enter_from_user_mode+0x21/0x70\n   do_syscall_64+0x3b/0x90\n   entry_SYSCALL_64_after_hwframe+0x63/0xcd\n  RIP: 0033:0x7f917c4e2c2d\n\nThe problem here is that a range of tnum_range(0, map-\u003emax_entries - 1) has\nlimited ability to represent the concrete tight range with the tnum as the\nset of resulting states from value + mask can result in a superset of the\nactual intended range, and as such a tnum_in(range, reg-\u003evar_off) check may\nyield true when it shouldn\u0027t, for example tnum_range(0, 2) would result in\n00XX -\u003e v = 0000, m = 0011 such that the intended set of {0, 1, 2} is here\nrepresented by a less precise superset of {0, 1, 2, 3}. As the register is\nknown const scalar, really just use the concrete reg-\u003evar_off.value for the\nupper index check."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The vulnerability is triggered by loading a crafted eBPF program via the bpf() syscall (BPF_PROG_LOAD \u2192 verifier \u2192 JIT), which is a local attack vector.\nAC:L - The attacker fully controls PROG_ARRAY max_entries and the constant tail-call index, and a public PoC reliably triggers the slab OOB during JIT with no conditions outside attacker control.\nPR:L - Exploitation requires loading BPF programs and creating a PROG_ARRAY (CAP_BPF, or unprivileged BPF where enabled); this is basic/low privilege relative to full root, consistent with other BPF verifier OOB scorings.\nUI:N - No victim action is required; the attacker triggers the bug solely by loading their own crafted BPF program.\nS:U - Impact stays within the kernel\u0027s authority (local memory corruption / potential privilege escalation); it does not cross a VM, IOMMU, or other security boundary.\nC:H - The bug is a slab out-of-bounds read of pointer-sized values from adjacent memory, and with attacker-chosen map sizes the OOB can span kilobytes, enabling high-impact disclosure primitives.\nI:H - The OOB-read pointer is passed to bpf_tail_call_direct_fixup / __bpf_arch_text_poke, which patches JIT code with a jump derived from that value, yielding a controllable integrity / control-flow corruption primitive.\nA:H - The OOB access was confirmed via KASAN as a slab-out-of-bounds read in bpf_int_jit_compile, and dereferencing a garbage target pointer can cause a kernel oops/panic."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T08:57:01.160Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/e8979807178434db8ceaa84dfcd44363e71e50bb"
        },
        {
          "url": "https://git.kernel.org/stable/c/4f672112f8665102a5842c170be1713f8ff95919"
        },
        {
          "url": "https://git.kernel.org/stable/c/a36df92c7ff7ecde2fb362241d0ab024dddd0597"
        },
        {
          "url": "https://git.kernel.org/stable/c/a657182a5c5150cdfacb6640aad1d2712571a409"
        }
      ],
      "title": "bpf: Don\u0027t use tnum_range on array range checking for poke descriptors",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2022-49985",
    "datePublished": "2025-06-18T11:00:47.251Z",
    "dateReserved": "2025-06-18T10:57:27.386Z",
    "dateUpdated": "2026-08-05T08:57:01.160Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2022-49985",
      "date": "2026-09-16",
      "epss": "0.00242",
      "percentile": "0.15504"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2022-49985\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-06-18T11:15:26.067\",\"lastModified\":\"2026-08-04T10:18:01.983\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbpf: Don\u0027t use tnum_range on array range checking for poke descriptors\\n\\nHsin-Wei reported a KASAN splat triggered by their BPF runtime fuzzer which\\nis based on a customized syzkaller:\\n\\n  BUG: KASAN: slab-out-of-bounds in bpf_int_jit_compile+0x1257/0x13f0\\n  Read of size 8 at addr ffff888004e90b58 by task syz-executor.0/1489\\n  CPU: 1 PID: 1489 Comm: syz-executor.0 Not tainted 5.19.0 #1\\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\\n  1.13.0-1ubuntu1.1 04/01/2014\\n  Call Trace:\\n   \u003cTASK\u003e\\n   dump_stack_lvl+0x9c/0xc9\\n   print_address_description.constprop.0+0x1f/0x1f0\\n   ? bpf_int_jit_compile+0x1257/0x13f0\\n   kasan_report.cold+0xeb/0x197\\n   ? kvmalloc_node+0x170/0x200\\n   ? bpf_int_jit_compile+0x1257/0x13f0\\n   bpf_int_jit_compile+0x1257/0x13f0\\n   ? arch_prepare_bpf_dispatcher+0xd0/0xd0\\n   ? rcu_read_lock_sched_held+0x43/0x70\\n   bpf_prog_select_runtime+0x3e8/0x640\\n   ? bpf_obj_name_cpy+0x149/0x1b0\\n   bpf_prog_load+0x102f/0x2220\\n   ? __bpf_prog_put.constprop.0+0x220/0x220\\n   ? find_held_lock+0x2c/0x110\\n   ? __might_fault+0xd6/0x180\\n   ? lock_downgrade+0x6e0/0x6e0\\n   ? lock_is_held_type+0xa6/0x120\\n   ? __might_fault+0x147/0x180\\n   __sys_bpf+0x137b/0x6070\\n   ? bpf_perf_link_attach+0x530/0x530\\n   ? new_sync_read+0x600/0x600\\n   ? __fget_files+0x255/0x450\\n   ? lock_downgrade+0x6e0/0x6e0\\n   ? fput+0x30/0x1a0\\n   ? ksys_write+0x1a8/0x260\\n   __x64_sys_bpf+0x7a/0xc0\\n   ? syscall_enter_from_user_mode+0x21/0x70\\n   do_syscall_64+0x3b/0x90\\n   entry_SYSCALL_64_after_hwframe+0x63/0xcd\\n  RIP: 0033:0x7f917c4e2c2d\\n\\nThe problem here is that a range of tnum_range(0, map-\u003emax_entries - 1) has\\nlimited ability to represent the concrete tight range with the tnum as the\\nset of resulting states from value + mask can result in a superset of the\\nactual intended range, and as such a tnum_in(range, reg-\u003evar_off) check may\\nyield true when it shouldn\u0027t, for example tnum_range(0, 2) would result in\\n00XX -\u003e v = 0000, m = 0011 such that the intended set of {0, 1, 2} is here\\nrepresented by a less precise superset of {0, 1, 2, 3}. As the register is\\nknown const scalar, really just use the concrete reg-\u003evar_off.value for the\\nupper index check.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: No use tnum_range en la comprobaci\u00f3n del rango de matriz para los descriptores de poke Hsin-Wei inform\u00f3 un splat de KASAN activado por su fuzzer de tiempo de ejecuci\u00f3n BPF que se basa en un syzkaller personalizado: ERROR: KASAN: slab-out-of-bounds en bpf_int_jit_compile+0x1257/0x13f0 Lectura de tama\u00f1o 8 en la direcci\u00f3n ffff888004e90b58 por la tarea syz-executor.0/1489 CPU: 1 PID: 1489 Comm: syz-executor.0 No contaminado 5.19.0 #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Rastreo de llamadas:  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 El problema aqu\u00ed es que un rango de tnum_range(0, map-\u0026gt;max_entries - 1) tiene una capacidad limitada para representar el rango estrecho concreto con el tnum como el conjunto de estados resultantes de value + mask puede resultar en un superconjunto del rango real deseado, y como tal una comprobaci\u00f3n tnum_in(range, reg-\u0026gt;var_off) puede dar como resultado verdadero cuando no deber\u00eda, por ejemplo tnum_range(0, 2) dar\u00eda como resultado 00XX -\u0026gt; v = 0000, m = 0011 de modo que el conjunto deseado de {0, 1, 2} est\u00e1 representado aqu\u00ed por un superconjunto menos preciso de {0, 1, 2, 3}. Como el registro es un escalar constante, simplemente use el valor concreto reg-\u0026gt;var_off.value para la verificaci\u00f3n del \u00edndice superior.\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"kernel/bpf/verifier.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b\",\"lessThan\":\"e8979807178434db8ceaa84dfcd44363e71e50bb\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b\",\"lessThan\":\"4f672112f8665102a5842c170be1713f8ff95919\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b\",\"lessThan\":\"a36df92c7ff7ecde2fb362241d0ab024dddd0597\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b\",\"lessThan\":\"a657182a5c5150cdfacb6640aad1d2712571a409\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"kernel/bpf/verifier.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"5.5\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"5.5\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.10.140\",\"lessThanOrEqual\":\"5.10.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.15.64\",\"lessThanOrEqual\":\"5.15.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.19.6\",\"lessThanOrEqual\":\"5.19.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.0\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\",\"baseScore\":7.8,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":5.9},{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H\",\"baseScore\":7.1,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":5.2}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-125\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.5\",\"versionEndExcluding\":\"5.10.140\",\"matchCriteriaId\":\"A26216A8-920B-4892-A1EB-143451AFFC31\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.11\",\"versionEndExcluding\":\"5.15.64\",\"matchCriteriaId\":\"292F3687-ADC2-4F3D-9710-3BCAD11A52BE\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.16\",\"versionEndExcluding\":\"5.19.6\",\"matchCriteriaId\":\"89E99903-E16D-475D-954B-2BAC46C98262\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.0:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"E8BD11A3-8643-49B6-BADE-5029A0117325\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.0:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"5F0AD220-F6A9-4012-8636-155F1B841FAD\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.0:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"A46498B3-78E1-4623-AAE1-94D29A42BE4E\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/4f672112f8665102a5842c170be1713f8ff95919\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/a36df92c7ff7ecde2fb362241d0ab024dddd0597\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/a657182a5c5150cdfacb6640aad1d2712571a409\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/e8979807178434db8ceaa84dfcd44363e71e50bb\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-08-04T19:41:41+00:00",
      "cve": "CVE-2022-49985",
      "id": "CVE-2022-49985",
      "initial_release_date": "2022-01-01T00:00:00+00:00",
      "product_status:fixed": "783",
      "product_status:known_affected": "22",
      "product_status:known_not_affected": "118",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: bpf: Don\u0027t use tnum_range on array range checking for poke descriptors",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2022/cve-2022-49985.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-08-29T02:24:13Z",
      "cve": "CVE-2022-49985",
      "id": "CVE-2022-49985",
      "initial_release_date": "2025-06-19T03:44:47Z",
      "product_status:known_not_affected": "384",
      "product_status:recommended": "282",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2022-49985",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2022-49985.json",
      "version": "39"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.