Katalog CVE

CVE-2026-74745

WysokieCVSS 7.5
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.36%

Percentyl 29 - wyżej niż 29% wszystkich znanych CVE

Streszczenie

W jądrze Linuxa w sterowniku bnxt (Broadcom NetXtreme) występuje podatność na zakleszczenie (deadlock) podczas anulowania notyfikatora powinowactwa IRQ. Notyfikator wywołuje restart kolejki pod zamkiem instancji netdev, a anulowanie czeka na zakończenie callbacku, co prowadzi do zakleszczenia.

Ocena ryzyka

Zakleszczenie może spowodować zawieszenie działania interfejsu sieciowego, co prowadzi do niedostępności usług sieciowych i potencjalnych przerw w działaniu.

Rekomendacja

Zaleca się zastosowanie łatki jądra, która przenosi restart kolejki do asynchronicznego zadania serwisowego, oraz aktualizację sterownika bnxt.

Inne podatności w Linux kernel

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

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.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS