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

OESA-2026-2415 (CVE-2026-31527)

Vulnerability from osv_openeuler – Published: 2026-05-22 11:11 – Updated: 2026-08-06 11:11 – Source website
VLAI
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

driver core: platform: use generic driver_override infrastructure

When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.

Note that calling match() from __driver_attach() without the device lock held is intentional. 1

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

crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failed

When retrieving the PDH cert, don't attempt to copy the blobs to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes firmware requires will overflow the kernel-allocated buffer and leak data to userspace.

BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033

CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025 Call Trace: <TASK> dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK>

WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.(CVE-2026-31698)

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

crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failed

When retrieving the PEK CSR, don't attempt to copy the blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes firmware requires will overflow the kernel-allocated buffer and leak data to userspace.

BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405

CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: <TASK> dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK>

WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.(CVE-2026-31699)

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

HID: multitouch: Check to ensure report responses match the request

It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes.

Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early.(CVE-2026-43047)

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

HID: core: Mitigate potential OOB by removing bogus memset()

The memset() in hid_report_raw_event() has the good intention of clearing out bogus data by zeroing the area from the end of the incoming data string to the assumed end of the buffer. However, as we have previously seen, doing so can easily result in OOB reads and writes in the subsequent thread of execution.

The current suggestion from one of the HID maintainers is to remove the memset() and simply return if the incoming event buffer size is not large enough to fill the associated report.

Suggested-by Benjamin Tissoires <(CVE-2026-43048)

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

ptrace: slightly saner 'get_dumpable()' logic

The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm.

And almost all users do in fact use it only for the case where the task has a mm pointer.

But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads).

It's not what this flag was designed for, but it is what it is.

The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional "drop capabilities" model doesn't make any difference for this all.

Make it all make a bit more sense by saying that if you don't have a MM pointer, we'll use a cached "last dumpability" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.(CVE-2026-46333)

Severity
8.8 (High)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
References
To clipboard 

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2605.4.0.0373.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2605.4.0.0373.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: platform: use generic driver_override infrastructure\n\nWhen a driver is probed through __driver_attach(), the bus\u0026apos; match()\ncallback is called without the device lock held, thus accessing the\ndriver_override field without a lock, which can cause a UAF.\n\nFix this by using the driver-core driver_override infrastructure taking\ncare of proper locking internally.\n\nNote that calling match() from __driver_attach() without the device lock\nheld is intentional. [1](CVE-2026-31527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp: Don\u0026apos;t attempt to copy PDH cert to userspace if PSP command failed\n\nWhen retrieving the PDH cert, don\u0026apos;t attempt to copy the blobs to userspace\nif the firmware command failed.  If the failure was due to an invalid\nlength, i.e. the userspace buffer+length was too small, copying the number\nof bytes _firmware_ requires will overflow the kernel-allocated buffer and\nleak data to userspace.\n\n  BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n  BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n  BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n  Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033\n\n  CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G     U     O        7.0.0-smp-DEV #28 PREEMPTLAZY\n  Tainted: [U]=USER, [O]=OOT_MODULE\n  Hardware name: Google, Inc.                                                       Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120\n   print_address_description ../mm/kasan/report.c:378 [inline]\n   print_report+0xbc/0x260 ../mm/kasan/report.c:482\n   kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595\n   check_region_inline ../mm/kasan/generic.c:-1 [inline]\n   kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200\n   instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n   _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n   _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n   copy_to_user ../include/linux/uaccess.h:236 [inline]\n   sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347\n   sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568\n   vfs_ioctl ../fs/ioctl.c:51 [inline]\n   __do_sys_ioctl ../fs/ioctl.c:597 [inline]\n   __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583\n   do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]\n   do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n   \u0026lt;/TASK\u0026gt;\n\nWARN if the driver says the command succeeded, but the firmware error code\nsays otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any\nfirwmware error.(CVE-2026-31698)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp: Don\u0026apos;t attempt to copy CSR to userspace if PSP command failed\n\nWhen retrieving the PEK CSR, don\u0026apos;t attempt to copy the blob to userspace\nif the firmware command failed.  If the failure was due to an invalid\nlength, i.e. the userspace buffer+length was too small, copying the number\nof bytes _firmware_ requires will overflow the kernel-allocated buffer and\nleak data to userspace.\n\n  BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n  BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n  BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n  Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405\n\n  CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G     U     O        7.0.0-smp-DEV #28 PREEMPTLAZY\n  Tainted: [U]=USER, [O]=OOT_MODULE\n  Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120\n   print_address_description ../mm/kasan/report.c:378 [inline]\n   print_report+0xbc/0x260 ../mm/kasan/report.c:482\n   kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595\n   check_region_inline ../mm/kasan/generic.c:-1 [inline]\n   kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200\n   instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n   _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n   _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n   copy_to_user ../include/linux/uaccess.h:236 [inline]\n   sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872\n   sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562\n   vfs_ioctl ../fs/ioctl.c:51 [inline]\n   __do_sys_ioctl ../fs/ioctl.c:597 [inline]\n   __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583\n   do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]\n   do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n   \u0026lt;/TASK\u0026gt;\n\nWARN if the driver says the command succeeded, but the firmware error code\nsays otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any\nfirwmware error.(CVE-2026-31699)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: Check to ensure report responses match the request\n\nIt is possible for a malicious (or clumsy) device to respond to a\nspecific report\u0026apos;s feature request using a completely different report\nID.  This can cause confusion in the HID core resulting in nasty\nside-effects such as OOB writes.\n\nAdd a check to ensure that the report ID in the response, matches the\none that was requested.  If it doesn\u0026apos;t, omit reporting the raw event and\nreturn early.(CVE-2026-43047)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Mitigate potential OOB by removing bogus memset()\n\nThe memset() in hid_report_raw_event() has the good intention of\nclearing out bogus data by zeroing the area from the end of the incoming\ndata string to the assumed end of the buffer.  However, as we have\npreviously seen, doing so can easily result in OOB reads and writes in\nthe subsequent thread of execution.\n\nThe current suggestion from one of the HID maintainers is to remove the\nmemset() and simply return if the incoming event buffer size is not\nlarge enough to fill the associated report.\n\nSuggested-by Benjamin Tissoires \u0026lt;(CVE-2026-43048)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nptrace: slightly saner \u0026apos;get_dumpable()\u0026apos; logic\n\nThe \u0026apos;dumpability\u0026apos; of a task is fundamentally about the memory image of\nthe task - the concept comes from whether it can core dump or not - and\nmakes no sense when you don\u0026apos;t have an associated mm.\n\nAnd almost all users do in fact use it only for the case where the task\nhas a mm pointer.\n\nBut we have one odd special case: ptrace_may_access() uses \u0026apos;dumpable\u0026apos; to\ncheck various other things entirely independently of the MM (typically\nexplicitly using flags like PTRACE_MODE_READ_FSCREDS).  Including for\nthreads that no longer have a VM (and maybe never did, like most kernel\nthreads).\n\nIt\u0026apos;s not what this flag was designed for, but it is what it is.\n\nThe ptrace code does check that the uid/gid matches, so you do have to\nbe uid-0 to see kernel thread details, but this means that the\ntraditional \u0026quot;drop capabilities\u0026quot; model doesn\u0026apos;t make any difference for\nthis all.\n\nMake it all make a *bit* more sense by saying that if you don\u0026apos;t have a\nMM pointer, we\u0026apos;ll use a cached \u0026quot;last dumpability\u0026quot; flag if the thread\never had a MM (it will be zero for kernel threads since it is never\nset), and require a proper CAP_SYS_PTRACE capability to override.(CVE-2026-46333)",
  "id": "OESA-2026-2415",
  "modified": "2026-08-06T11:11:22Z",
  "published": "2026-05-22T11:11:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2415"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31527"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31698"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31699"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43047"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43048"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46333"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2026-31527",
    "CVE-2026-31698",
    "CVE-2026-31699",
    "CVE-2026-43047",
    "CVE-2026-43048",
    "CVE-2026-46333"
  ]
}



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.