Vulnerability-Lookup

GHSA-4FRH-9V5H-WQJ6

Vulnerability from github – Published: 2026-08-27 06:31 – Updated: 2026-08-27 06:31

Details

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

eth: bnxt: avoid deadlock when canceling IRQ affinity notifier

Unregistering IRQ affinity notifiers waits for the callback synchronously. bnxt takes the netdev instance lock in the notifier (to restart the queue) and cancels the work under the same lock. This may obviously deadlock.

Move the restart to the async service task. The queue restart isn't super time sensitive. Store the new TPH tag, schedule the task. Safely canceling the service task is already ironed out.

In bnxt_request_irq() the order of registering notifier, affinity and initial TPH programming has to be inverted. I think it was racy previously since user may trigger an update as soon as notifier is installed.

There's a small known gap - if pcie_tph_get_cpu_st() fails at init and the target tag is 0 we may miss programming the entry. This does not seem worth fixing, the code has skip-on-failure all over the place, anyway.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-74745"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-26T15:16:53Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\neth: bnxt: avoid deadlock when canceling IRQ affinity notifier\n\nUnregistering IRQ affinity notifiers waits for the callback synchronously.\nbnxt takes the netdev instance lock in the notifier (to restart the queue)\nand cancels the work under the same lock. This may obviously deadlock.\n\nMove the restart to the async service task. The queue restart isn\u0027t\nsuper time sensitive. Store the new TPH tag, schedule the task.\nSafely canceling the service task is already ironed out.\n\nIn bnxt_request_irq() the order of registering notifier, affinity and\ninitial TPH programming has to be inverted. I think it was racy\npreviously since user may trigger an update as soon as notifier\nis installed.\n\nThere\u0027s a small known gap - if pcie_tph_get_cpu_st() fails at init\nand the target tag is 0 we may miss programming the entry.\nThis does not seem worth fixing, the code has skip-on-failure\nall over the place, anyway.",
  "id": "GHSA-4frh-9v5h-wqj6",
  "modified": "2026-08-27T06:31:30Z",
  "published": "2026-08-27T06:31:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74745"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/51e96fa31f7e7eac2cba8f854e24d36600cc040b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8b1118fc5a5d2cdc21cc07b5106921ad4f77c544"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CVE-2026-74745 (GCVE-0-2026-74745)

Vulnerability from cvelistv5 – Published: 2026-08-26 14:36 – Updated: 2026-08-27 05:01

Title

eth: bnxt: avoid deadlock when canceling IRQ affinity notifier

Summary

In the Linux kernel, the following vulnerability has been resolved: eth: bnxt: avoid deadlock when canceling IRQ affinity notifier Unregistering IRQ affinity notifiers waits for the callback synchronously. bnxt takes the netdev instance lock in the notifier (to restart the queue) and cancels the work under the same lock. This may obviously deadlock. Move the restart to the async service task. The queue restart isn't super time sensitive. Store the new TPH tag, schedule the task. Safely canceling the service task is already ironed out. In bnxt_request_irq() the order of registering notifier, affinity and initial TPH programming has to be inverted. I think it was racy previously since user may trigger an update as soon as notifier is installed. There's a small known gap - if pcie_tph_get_cpu_st() fails at init and the target tag is 0 we may miss programming the entry. This does not seem worth fixing, the code has skip-on-failure all over the place, anyway.

Severity

7.5 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Assigner

Linux mitre root

References

2 references

URL	Tags
https://git.kernel.org/stable/c/8b1118fc5a5d2cdc2…
https://git.kernel.org/stable/c/51e96fa31f7e7eac2…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: c214410c47d6ec3128143370747d9e388bab21d7 , < 8b1118fc5a5d2cdc21cc07b5106921ad4f77c544 (git) Affected: c214410c47d6ec3128143370747d9e388bab21d7 , < 51e96fa31f7e7eac2cba8f854e24d36600cc040b (git)
Linux	Linux	Affected: 6.15 Unaffected: 0 , < 6.15 (semver) Unaffected: 7.1.10 , ≤ 7.1.* (semver) Unaffected: 7.2 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ethernet/broadcom/bnxt/bnxt.c",
            "drivers/net/ethernet/broadcom/bnxt/bnxt.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "8b1118fc5a5d2cdc21cc07b5106921ad4f77c544",
              "status": "affected",
              "version": "c214410c47d6ec3128143370747d9e388bab21d7",
              "versionType": "git"
            },
            {
              "lessThan": "51e96fa31f7e7eac2cba8f854e24d36600cc040b",
              "status": "affected",
              "version": "c214410c47d6ec3128143370747d9e388bab21d7",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ethernet/broadcom/bnxt/bnxt.c",
            "drivers/net/ethernet/broadcom/bnxt/bnxt.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.15"
            },
            {
              "lessThan": "6.15",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.1.*",
              "status": "unaffected",
              "version": "7.1.10",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.1.10",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\neth: bnxt: avoid deadlock when canceling IRQ affinity notifier\n\nUnregistering IRQ affinity notifiers waits for the callback synchronously.\nbnxt takes the netdev instance lock in the notifier (to restart the queue)\nand cancels the work under the same lock. This may obviously deadlock.\n\nMove the restart to the async service task. The queue restart isn\u0027t\nsuper time sensitive. Store the new TPH tag, schedule the task.\nSafely canceling the service task is already ironed out.\n\nIn bnxt_request_irq() the order of registering notifier, affinity and\ninitial TPH programming has to be inverted. I think it was racy\npreviously since user may trigger an update as soon as notifier\nis installed.\n\nThere\u0027s a small known gap - if pcie_tph_get_cpu_st() fails at init\nand the target tag is 0 we may miss programming the entry.\nThis does not seem worth fixing, the code has skip-on-failure\nall over the place, anyway."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:N - Remote traffic can stall bnxt TX queues and fire netdev watchdog bnxt_tx_timeout(), driving bnxt_reset()/bnxt_close_nic() to bnxt_free_irq() under RTNL and netdev_lock on internet-facing Broadcom NetXtreme cloud/DC servers without local syscall access.\nAC:L - On TPH-capable bnxt NICs the affinity notifier is auto-registered; an attacker can repeatedly provoke TX-timeout teardown while system irqbalance or CPU hotplug migrates MSIX affinity, controlling both deadlock sides without uncontrollable memory layout or rare victim state.\nPR:N - Exploitation requires only sending traffic that triggers netdev TX-timeout recovery on an already-up bnxt interface; concurrent IRQ affinity updates are performed by irqbalance/hotplug without attacker credentials, CAP_NET_ADMIN, or init-namespace root.\nUI:N - No victim interaction is needed beyond normal operation of a bnxt uplink on a host running irqbalance; the attacker only sends traffic to provoke watchdog reset coincident with kernel-driven affinity migration.\nS:U - The netdev_lock/workqueue inversion deadlocks NIC teardown inside the host kernel and does not cross VM, container, or IOMMU boundaries to another security authority.\nC:N - This is a pure locking deadlock between irq_set_affinity_notifier cancel_work_sync and bnxt_irq_affinity_notify; there is no memory corruption, use-after-free, out-of-bounds access, or information disclosure.\nI:N - The flaw does not modify attacker-controlled data or achieve code execution; it only wedges threads waiting on netdev_lock during IRQ notifier cancellation without altering kernel memory contents.\nA:H - Deadlock during bnxt_close_nic/bnxt_free_irq leaves RTNL and netdev_lock held indefinitely, freezing host-wide network reconfiguration and the affected interface until reboot, matching CVSS guidance for kernel deadlocks."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-27T05:01:06.342Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/8b1118fc5a5d2cdc21cc07b5106921ad4f77c544"
        },
        {
          "url": "https://git.kernel.org/stable/c/51e96fa31f7e7eac2cba8f854e24d36600cc040b"
        }
      ],
      "title": "eth: bnxt: avoid deadlock when canceling IRQ affinity notifier",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-74745",
    "datePublished": "2026-08-26T14:36:55.372Z",
    "dateReserved": "2026-08-15T05:44:03.931Z",
    "dateUpdated": "2026-08-27T05:01:06.342Z",
    "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.