Към съдържанието

CVE-2026-64210: Linux, състезание за ресурс

7.5

CVSS 3.1

Няма данни

Вероятност да бъде експлоатирана в следващите 30 дни (EPSS)

Няма потвърждение

Атакува се

Няма данни

Време до експлоатация

Атакува се по мрежата, без особени условия, без вход и без действие от потребителя.

CVE радар: още уязвимости от този вид

  • Експлоатация: няма данни за експлоатация
  • Атаката може да се автоматизира

Описание

Оригинално описание

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix unlocked writing to ICOSQ During napi poll, when the affinity changes and there's still XSK work to be done, we trigger an ICOSQ interrupt on the new CPU. However, this triggering on the ICOSQ is done unprotected. There are 2 such races: A) mlx5e_trigger_irq() is called while mlx5e_xsk_alloc_rx_mpwqe() is running from a different CPU due to affinity change. This can happen because IRQ triggering is done after napi_complete_done(). At this point the NAPI can be scheduled on a different CPU. Like this: CPU A (old affinity, NAPI tail) CPU B (new affinity, fresh NAPI) ------------------------------- -------------------------------- napi_complete_done() clears SCHED mlx5e_cq_arm(...) napi_schedule_prep() sets SCHED mlx5e_napi_poll() mlx5e_xsk_alloc_rx_mpwqe() mlx5e_icosq_sync_lock() // noop memcpy 640 B UMR body advance sq->pc by 10 mlx5e_trigger_irq(&c->icosq) wqe_info[pi] = {NOP, 1} mlx5e_post_nop() advances sq->pc B) mlx5e_trigger_irq() is called on the ICOSQ when mlx5e_trigger_napi_icosq() is running. The obvious fix would be to lock the ICOSQ. But ICOSQ has an optimized locking scheme that doesn't work for this scenario. Kick the async ICOSQ instead which is always locked. This issue was noticed in the wild with the following splat: netdevice: ge-0-0-1: Bad OP in ICOSQ CQE: 0xd WARNING: drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:826 [...] [...] Call Trace: <IRQ> mlx5e_napi_poll+0x11d/0x7f0 [mlx5_core] __napi_poll+0x30/0x200 ? skb_defer_free_flush+0x9c/0xc0 net_rx_action+0x2fe/0x3f0 handle_softirqs+0xd8/0x340 __irq_exit_rcu+0xbc/0xe0 common_interrupt+0x85/0xa0 </IRQ> <TASK>

Засегнати продукти

  • Linux Linux: db05815b36cbd486c86fd002dfa81c9af6245e25 преди 0c8f331485656d5937d56a488016b944a038fe2f; db05815b36cbd486c86fd002dfa81c9af6245e25 преди f3d8c2fd591bb603b069e151881a317e26a3f478; db05815b36cbd486c86fd002dfa81c9af6245e25 преди f37adef34eb7ebe29a534d20ccadd72bd7ff664e; db05815b36cbd486c86fd002dfa81c9af6245e25 преди 54a97ef1025236cc1bc54d79c7ae2eb8027ce4b8; db05815b36cbd486c86fd002dfa81c9af6245e25 преди 8d3b91e7d81000d295cd914d4d9d6f860252e2bf; db05815b36cbd486c86fd002dfa81c9af6245e25 преди c326f9c68921e2f14dfcecb2f6b4216313d50248
  • Linux Linux: 5.3; преди 5.3; 6.1.188 до 6.1.*; 6.6.157 до 6.6.*; 6.12.110 до 6.12.*; 6.18.52 до 6.18.*; 7.0.11 до 7.0.*; от 7.1 нататък

Вид слабост

История

  • 24 юли 2026 Публикувано

Други уязвимости в Linux Linux

Първоизточници