{"api_version":"1","generated_at":"2026-08-29T02:26:56+00:00","cve":"CVE-2026-74745","urls":{"html":"https://cve.report/CVE-2026-74745","api":"https://cve.report/api/cve/CVE-2026-74745.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-74745","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-74745"},"summary":{"title":"eth: bnxt: avoid deadlock when canceling IRQ affinity notifier","description":"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't\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's 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.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-08-26 15:16:53","updated_at":"2026-08-27 06:17:24"},"problem_types":[],"metrics":[{"version":"3.1","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","score":"7.5","severity":"HIGH","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","baseScore":7.5,"baseSeverity":"HIGH","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"7.5","severity":"HIGH","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","data":{"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"}}],"references":[{"url":"https://git.kernel.org/stable/c/8b1118fc5a5d2cdc21cc07b5106921ad4f77c544","name":"https://git.kernel.org/stable/c/8b1118fc5a5d2cdc21cc07b5106921ad4f77c544","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/51e96fa31f7e7eac2cba8f854e24d36600cc040b","name":"https://git.kernel.org/stable/c/51e96fa31f7e7eac2cba8f854e24d36600cc040b","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-74745","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74745","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected c214410c47d6ec3128143370747d9e388bab21d7 8b1118fc5a5d2cdc21cc07b5106921ad4f77c544 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected c214410c47d6ec3128143370747d9e388bab21d7 51e96fa31f7e7eac2cba8f854e24d36600cc040b git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.15","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.15 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.1.10 7.1.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":{"cve_year":"2026","cve_id":"74745","cve":"CVE-2026-74745","epss":"0.003590000","percentile":"0.286600000","score_date":"2026-08-27","updated_at":"2026-08-28 00:03:39"},"legacy_qids":[]},"source_records":{"cve_program":{"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't\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's 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"},"nvd":{"publishedDate":"2026-08-26 15:16:53","lastModifiedDate":"2026-08-27 06:17:24","problem_types":[],"metrics":{"cvssMetricV31":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","baseScore":7.5,"baseSeverity":"HIGH","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"},"exploitabilityScore":3.9,"impactScore":3.6}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"74745","Ordinal":"1","Title":"eth: bnxt: avoid deadlock when canceling IRQ affinity notifier","CVE":"CVE-2026-74745","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"74745","Ordinal":"1","NoteData":"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't\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's 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.","Type":"Description","Title":"eth: bnxt: avoid deadlock when canceling IRQ affinity notifier"}]}}}