Vulnerability-Lookup

GHSA-J844-9PMV-WMHV

Vulnerability from github – Published: 2025-12-24 15:30 – Updated: 2025-12-24 15:30

Details

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

igb: clean up in all error paths when enabling SR-IOV

After commit 50f303496d92 ("igb: Enable SR-IOV after reinit"), removing the igb module could hang or crash (depending on the machine) when the module has been loaded with the max_vfs parameter set to some value != 0.

In case of one test machine with a dual port 82580, this hang occurred:

[ 232.480687] igb 0000:41:00.1: removed PHC on enp65s0f1 [ 233.093257] igb 0000:41:00.1: IOV Disabled [ 233.329969] pcieport 0000:40:01.0: AER: Multiple Uncorrected (Non-Fatal) err0 [ 233.340302] igb 0000:41:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fata) [ 233.352248] igb 0000:41:00.0: device [8086:1516] error status/mask=00100000 [ 233.361088] igb 0000:41:00.0: [20] UnsupReq (First) [ 233.368183] igb 0000:41:00.0: AER: TLP Header: 40000001 0000040f cdbfc00c c [ 233.376846] igb 0000:41:00.1: PCIe Bus Error: severity=Uncorrected (Non-Fata) [ 233.388779] igb 0000:41:00.1: device [8086:1516] error status/mask=00100000 [ 233.397629] igb 0000:41:00.1: [20] UnsupReq (First) [ 233.404736] igb 0000:41:00.1: AER: TLP Header: 40000001 0000040f cdbfc00c c [ 233.538214] pci 0000:41:00.1: AER: can't recover (no error_detected callback) [ 233.538401] igb 0000:41:00.0: removed PHC on enp65s0f0 [ 233.546197] pcieport 0000:40:01.0: AER: device recovery failed [ 234.157244] igb 0000:41:00.0: IOV Disabled [ 371.619705] INFO: task irq/35-aerdrv:257 blocked for more than 122 seconds. [ 371.627489] Not tainted 6.4.0-dirty #2 [ 371.632257] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this. [ 371.641000] task:irq/35-aerdrv state:D stack:0 pid:257 ppid:2 f0 [ 371.650330] Call Trace: [ 371.653061] [ 371.655407] __schedule+0x20e/0x660 [ 371.659313] schedule+0x5a/0xd0 [ 371.662824] schedule_preempt_disabled+0x11/0x20 [ 371.667983] __mutex_lock.constprop.0+0x372/0x6c0 [ 371.673237] ? __pfx_aer_root_reset+0x10/0x10 [ 371.678105] report_error_detected+0x25/0x1c0 [ 371.682974] ? __pfx_report_normal_detected+0x10/0x10 [ 371.688618] pci_walk_bus+0x72/0x90 [ 371.692519] pcie_do_recovery+0xb2/0x330 [ 371.696899] aer_process_err_devices+0x117/0x170 [ 371.702055] aer_isr+0x1c0/0x1e0 [ 371.705661] ? __set_cpus_allowed_ptr+0x54/0xa0 [ 371.710723] ? __pfx_irq_thread_fn+0x10/0x10 [ 371.715496] irq_thread_fn+0x20/0x60 [ 371.719491] irq_thread+0xe6/0x1b0 [ 371.723291] ? __pfx_irq_thread_dtor+0x10/0x10 [ 371.728255] ? __pfx_irq_thread+0x10/0x10 [ 371.732731] kthread+0xe2/0x110 [ 371.736243] ? __pfx_kthread+0x10/0x10 [ 371.740430] ret_from_fork+0x2c/0x50 [ 371.744428]

The reproducer was a simple script:

#!/bin/sh for i in seq 1 5; do modprobe -rv igb modprobe -v igb max_vfs=1 sleep 1 modprobe -rv igb done

It turned out that this could only be reproduce on 82580 (quad and dual-port), but not on 82576, i350 and i210. Further debugging showed that igb_enable_sriov()'s call to pci_enable_sriov() is failing, because dev->is_physfn is 0 on 82580.

Prior to commit 50f303496d92 ("igb: Enable SR-IOV after reinit"), igb_enable_sriov() jumped into the "err_out" cleanup branch. After this commit it only returned the error code.

So the cleanup didn't take place, and the incorrect VF setup in the igb_adapter structure fooled the igb driver into assuming that VFs have been set up where no VF actually existed.

Fix this problem by cleaning up again if pci_enable_sriov() fails.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-54070"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-24T13:16:08Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nigb: clean up in all error paths when enabling SR-IOV\n\nAfter commit 50f303496d92 (\"igb: Enable SR-IOV after reinit\"), removing\nthe igb module could hang or crash (depending on the machine) when the\nmodule has been loaded with the max_vfs parameter set to some value != 0.\n\nIn case of one test machine with a dual port 82580, this hang occurred:\n\n[  232.480687] igb 0000:41:00.1: removed PHC on enp65s0f1\n[  233.093257] igb 0000:41:00.1: IOV Disabled\n[  233.329969] pcieport 0000:40:01.0: AER: Multiple Uncorrected (Non-Fatal) err0\n[  233.340302] igb 0000:41:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fata)\n[  233.352248] igb 0000:41:00.0:   device [8086:1516] error status/mask=00100000\n[  233.361088] igb 0000:41:00.0:    [20] UnsupReq               (First)\n[  233.368183] igb 0000:41:00.0: AER:   TLP Header: 40000001 0000040f cdbfc00c c\n[  233.376846] igb 0000:41:00.1: PCIe Bus Error: severity=Uncorrected (Non-Fata)\n[  233.388779] igb 0000:41:00.1:   device [8086:1516] error status/mask=00100000\n[  233.397629] igb 0000:41:00.1:    [20] UnsupReq               (First)\n[  233.404736] igb 0000:41:00.1: AER:   TLP Header: 40000001 0000040f cdbfc00c c\n[  233.538214] pci 0000:41:00.1: AER: can\u0027t recover (no error_detected callback)\n[  233.538401] igb 0000:41:00.0: removed PHC on enp65s0f0\n[  233.546197] pcieport 0000:40:01.0: AER: device recovery failed\n[  234.157244] igb 0000:41:00.0: IOV Disabled\n[  371.619705] INFO: task irq/35-aerdrv:257 blocked for more than 122 seconds.\n[  371.627489]       Not tainted 6.4.0-dirty #2\n[  371.632257] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this.\n[  371.641000] task:irq/35-aerdrv   state:D stack:0     pid:257   ppid:2      f0\n[  371.650330] Call Trace:\n[  371.653061]  \u003cTASK\u003e\n[  371.655407]  __schedule+0x20e/0x660\n[  371.659313]  schedule+0x5a/0xd0\n[  371.662824]  schedule_preempt_disabled+0x11/0x20\n[  371.667983]  __mutex_lock.constprop.0+0x372/0x6c0\n[  371.673237]  ? __pfx_aer_root_reset+0x10/0x10\n[  371.678105]  report_error_detected+0x25/0x1c0\n[  371.682974]  ? __pfx_report_normal_detected+0x10/0x10\n[  371.688618]  pci_walk_bus+0x72/0x90\n[  371.692519]  pcie_do_recovery+0xb2/0x330\n[  371.696899]  aer_process_err_devices+0x117/0x170\n[  371.702055]  aer_isr+0x1c0/0x1e0\n[  371.705661]  ? __set_cpus_allowed_ptr+0x54/0xa0\n[  371.710723]  ? __pfx_irq_thread_fn+0x10/0x10\n[  371.715496]  irq_thread_fn+0x20/0x60\n[  371.719491]  irq_thread+0xe6/0x1b0\n[  371.723291]  ? __pfx_irq_thread_dtor+0x10/0x10\n[  371.728255]  ? __pfx_irq_thread+0x10/0x10\n[  371.732731]  kthread+0xe2/0x110\n[  371.736243]  ? __pfx_kthread+0x10/0x10\n[  371.740430]  ret_from_fork+0x2c/0x50\n[  371.744428]  \u003c/TASK\u003e\n\nThe reproducer was a simple script:\n\n  #!/bin/sh\n  for i in `seq 1 5`; do\n    modprobe -rv igb\n    modprobe -v igb max_vfs=1\n    sleep 1\n    modprobe -rv igb\n  done\n\nIt turned out that this could only be reproduce on 82580 (quad and\ndual-port), but not on 82576, i350 and i210.  Further debugging showed\nthat igb_enable_sriov()\u0027s call to pci_enable_sriov() is failing, because\ndev-\u003eis_physfn is 0 on 82580.\n\nPrior to commit 50f303496d92 (\"igb: Enable SR-IOV after reinit\"),\nigb_enable_sriov() jumped into the \"err_out\" cleanup branch.  After this\ncommit it only returned the error code.\n\nSo the cleanup didn\u0027t take place, and the incorrect VF setup in the\nigb_adapter structure fooled the igb driver into assuming that VFs have\nbeen set up where no VF actually existed.\n\nFix this problem by cleaning up again if pci_enable_sriov() fails.",
  "id": "GHSA-j844-9pmv-wmhv",
  "modified": "2025-12-24T15:30:36Z",
  "published": "2025-12-24T15:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54070"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0e3ea7e82a06014b9baf1b84ba579c38cbff3558"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bc6ed2fa24b14e40e1005488bbe11268ce7108fa"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

CVE-2023-54070 (GCVE-0-2023-54070)

Vulnerability from cvelistv5 – Published: 2025-12-24 12:23 – Updated: 2026-05-11 19:54

Title

igb: clean up in all error paths when enabling SR-IOV

Summary

In the Linux kernel, the following vulnerability has been resolved: igb: clean up in all error paths when enabling SR-IOV After commit 50f303496d92 ("igb: Enable SR-IOV after reinit"), removing the igb module could hang or crash (depending on the machine) when the module has been loaded with the max_vfs parameter set to some value != 0. In case of one test machine with a dual port 82580, this hang occurred: [ 232.480687] igb 0000:41:00.1: removed PHC on enp65s0f1 [ 233.093257] igb 0000:41:00.1: IOV Disabled [ 233.329969] pcieport 0000:40:01.0: AER: Multiple Uncorrected (Non-Fatal) err0 [ 233.340302] igb 0000:41:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fata) [ 233.352248] igb 0000:41:00.0: device [8086:1516] error status/mask=00100000 [ 233.361088] igb 0000:41:00.0: [20] UnsupReq (First) [ 233.368183] igb 0000:41:00.0: AER: TLP Header: 40000001 0000040f cdbfc00c c [ 233.376846] igb 0000:41:00.1: PCIe Bus Error: severity=Uncorrected (Non-Fata) [ 233.388779] igb 0000:41:00.1: device [8086:1516] error status/mask=00100000 [ 233.397629] igb 0000:41:00.1: [20] UnsupReq (First) [ 233.404736] igb 0000:41:00.1: AER: TLP Header: 40000001 0000040f cdbfc00c c [ 233.538214] pci 0000:41:00.1: AER: can't recover (no error_detected callback) [ 233.538401] igb 0000:41:00.0: removed PHC on enp65s0f0 [ 233.546197] pcieport 0000:40:01.0: AER: device recovery failed [ 234.157244] igb 0000:41:00.0: IOV Disabled [ 371.619705] INFO: task irq/35-aerdrv:257 blocked for more than 122 seconds. [ 371.627489] Not tainted 6.4.0-dirty #2 [ 371.632257] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this. [ 371.641000] task:irq/35-aerdrv state:D stack:0 pid:257 ppid:2 f0 [ 371.650330] Call Trace: [ 371.653061] <TASK> [ 371.655407] __schedule+0x20e/0x660 [ 371.659313] schedule+0x5a/0xd0 [ 371.662824] schedule_preempt_disabled+0x11/0x20 [ 371.667983] __mutex_lock.constprop.0+0x372/0x6c0 [ 371.673237] ? __pfx_aer_root_reset+0x10/0x10 [ 371.678105] report_error_detected+0x25/0x1c0 [ 371.682974] ? __pfx_report_normal_detected+0x10/0x10 [ 371.688618] pci_walk_bus+0x72/0x90 [ 371.692519] pcie_do_recovery+0xb2/0x330 [ 371.696899] aer_process_err_devices+0x117/0x170 [ 371.702055] aer_isr+0x1c0/0x1e0 [ 371.705661] ? __set_cpus_allowed_ptr+0x54/0xa0 [ 371.710723] ? __pfx_irq_thread_fn+0x10/0x10 [ 371.715496] irq_thread_fn+0x20/0x60 [ 371.719491] irq_thread+0xe6/0x1b0 [ 371.723291] ? __pfx_irq_thread_dtor+0x10/0x10 [ 371.728255] ? __pfx_irq_thread+0x10/0x10 [ 371.732731] kthread+0xe2/0x110 [ 371.736243] ? __pfx_kthread+0x10/0x10 [ 371.740430] ret_from_fork+0x2c/0x50 [ 371.744428] </TASK> The reproducer was a simple script: #!/bin/sh for i in `seq 1 5`; do modprobe -rv igb modprobe -v igb max_vfs=1 sleep 1 modprobe -rv igb done It turned out that this could only be reproduce on 82580 (quad and dual-port), but not on 82576, i350 and i210. Further debugging showed that igb_enable_sriov()'s call to pci_enable_sriov() is failing, because dev->is_physfn is 0 on 82580. Prior to commit 50f303496d92 ("igb: Enable SR-IOV after reinit"), igb_enable_sriov() jumped into the "err_out" cleanup branch. After this commit it only returned the error code. So the cleanup didn't take place, and the incorrect VF setup in the igb_adapter structure fooled the igb driver into assuming that VFs have been set up where no VF actually existed. Fix this problem by cleaning up again if pci_enable_sriov() fails.

Severity

No CVSS data available.

Assigner

Linux mitre root

References

2 references

URL	Tags
https://git.kernel.org/stable/c/0e3ea7e82a06014b9…
https://git.kernel.org/stable/c/bc6ed2fa24b14e40e…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: 50f303496d92e25b79bdfb73e3707ad0684ad67f , < 0e3ea7e82a06014b9baf1b84ba579c38cbff3558 (git) Affected: 50f303496d92e25b79bdfb73e3707ad0684ad67f , < bc6ed2fa24b14e40e1005488bbe11268ce7108fa (git)
Linux	Linux	Affected: 6.3 Unaffected: 0 , < 6.3 (semver) Unaffected: 6.5.4 , ≤ 6.5.* (semver) Unaffected: 6.6 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ethernet/intel/igb/igb_main.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "0e3ea7e82a06014b9baf1b84ba579c38cbff3558",
              "status": "affected",
              "version": "50f303496d92e25b79bdfb73e3707ad0684ad67f",
              "versionType": "git"
            },
            {
              "lessThan": "bc6ed2fa24b14e40e1005488bbe11268ce7108fa",
              "status": "affected",
              "version": "50f303496d92e25b79bdfb73e3707ad0684ad67f",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ethernet/intel/igb/igb_main.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.3"
            },
            {
              "lessThan": "6.3",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.5.*",
              "status": "unaffected",
              "version": "6.5.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.6",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.5.4",
                  "versionStartIncluding": "6.3",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6",
                  "versionStartIncluding": "6.3",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nigb: clean up in all error paths when enabling SR-IOV\n\nAfter commit 50f303496d92 (\"igb: Enable SR-IOV after reinit\"), removing\nthe igb module could hang or crash (depending on the machine) when the\nmodule has been loaded with the max_vfs parameter set to some value != 0.\n\nIn case of one test machine with a dual port 82580, this hang occurred:\n\n[  232.480687] igb 0000:41:00.1: removed PHC on enp65s0f1\n[  233.093257] igb 0000:41:00.1: IOV Disabled\n[  233.329969] pcieport 0000:40:01.0: AER: Multiple Uncorrected (Non-Fatal) err0\n[  233.340302] igb 0000:41:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fata)\n[  233.352248] igb 0000:41:00.0:   device [8086:1516] error status/mask=00100000\n[  233.361088] igb 0000:41:00.0:    [20] UnsupReq               (First)\n[  233.368183] igb 0000:41:00.0: AER:   TLP Header: 40000001 0000040f cdbfc00c c\n[  233.376846] igb 0000:41:00.1: PCIe Bus Error: severity=Uncorrected (Non-Fata)\n[  233.388779] igb 0000:41:00.1:   device [8086:1516] error status/mask=00100000\n[  233.397629] igb 0000:41:00.1:    [20] UnsupReq               (First)\n[  233.404736] igb 0000:41:00.1: AER:   TLP Header: 40000001 0000040f cdbfc00c c\n[  233.538214] pci 0000:41:00.1: AER: can\u0027t recover (no error_detected callback)\n[  233.538401] igb 0000:41:00.0: removed PHC on enp65s0f0\n[  233.546197] pcieport 0000:40:01.0: AER: device recovery failed\n[  234.157244] igb 0000:41:00.0: IOV Disabled\n[  371.619705] INFO: task irq/35-aerdrv:257 blocked for more than 122 seconds.\n[  371.627489]       Not tainted 6.4.0-dirty #2\n[  371.632257] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this.\n[  371.641000] task:irq/35-aerdrv   state:D stack:0     pid:257   ppid:2      f0\n[  371.650330] Call Trace:\n[  371.653061]  \u003cTASK\u003e\n[  371.655407]  __schedule+0x20e/0x660\n[  371.659313]  schedule+0x5a/0xd0\n[  371.662824]  schedule_preempt_disabled+0x11/0x20\n[  371.667983]  __mutex_lock.constprop.0+0x372/0x6c0\n[  371.673237]  ? __pfx_aer_root_reset+0x10/0x10\n[  371.678105]  report_error_detected+0x25/0x1c0\n[  371.682974]  ? __pfx_report_normal_detected+0x10/0x10\n[  371.688618]  pci_walk_bus+0x72/0x90\n[  371.692519]  pcie_do_recovery+0xb2/0x330\n[  371.696899]  aer_process_err_devices+0x117/0x170\n[  371.702055]  aer_isr+0x1c0/0x1e0\n[  371.705661]  ? __set_cpus_allowed_ptr+0x54/0xa0\n[  371.710723]  ? __pfx_irq_thread_fn+0x10/0x10\n[  371.715496]  irq_thread_fn+0x20/0x60\n[  371.719491]  irq_thread+0xe6/0x1b0\n[  371.723291]  ? __pfx_irq_thread_dtor+0x10/0x10\n[  371.728255]  ? __pfx_irq_thread+0x10/0x10\n[  371.732731]  kthread+0xe2/0x110\n[  371.736243]  ? __pfx_kthread+0x10/0x10\n[  371.740430]  ret_from_fork+0x2c/0x50\n[  371.744428]  \u003c/TASK\u003e\n\nThe reproducer was a simple script:\n\n  #!/bin/sh\n  for i in `seq 1 5`; do\n    modprobe -rv igb\n    modprobe -v igb max_vfs=1\n    sleep 1\n    modprobe -rv igb\n  done\n\nIt turned out that this could only be reproduce on 82580 (quad and\ndual-port), but not on 82576, i350 and i210.  Further debugging showed\nthat igb_enable_sriov()\u0027s call to pci_enable_sriov() is failing, because\ndev-\u003eis_physfn is 0 on 82580.\n\nPrior to commit 50f303496d92 (\"igb: Enable SR-IOV after reinit\"),\nigb_enable_sriov() jumped into the \"err_out\" cleanup branch.  After this\ncommit it only returned the error code.\n\nSo the cleanup didn\u0027t take place, and the incorrect VF setup in the\nigb_adapter structure fooled the igb driver into assuming that VFs have\nbeen set up where no VF actually existed.\n\nFix this problem by cleaning up again if pci_enable_sriov() fails."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T19:54:53.709Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/0e3ea7e82a06014b9baf1b84ba579c38cbff3558"
        },
        {
          "url": "https://git.kernel.org/stable/c/bc6ed2fa24b14e40e1005488bbe11268ce7108fa"
        }
      ],
      "title": "igb: clean up in all error paths when enabling SR-IOV",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2023-54070",
    "datePublished": "2025-12-24T12:23:14.182Z",
    "dateReserved": "2025-12-24T12:21:05.093Z",
    "dateUpdated": "2026-05-11T19:54:53.709Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

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.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

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.