{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.105-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.9-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux-6.12"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.107-1~deb12u1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: TC, Check if flow is PEER before acquiring devcom lock  In case __mlx5e_add_fdb_flow() fails in lower levels, the flow is deleted via mlx5e_tc_del_flow(), and mlx5e_tc_del_flow() is acquiring ESW devcom lock without condition. In addition, in case of peer_flow, __mlx5e_add_fdb_flow() is called while holding ESW devcom comp lock. This results in an AA deadlock.  To fix this, introduce a new PEER flag that is set on flows created as peer flows (the duplicate flows on peer devices), and check it in mlx5e_tc_del_flow() before acquiring ESW devcom lock.  Lockdep splat: ============================================ WARNING: possible recursive locking detected ============================================  Possible unsafe locking scenario:        CPU0        ----   lock(\u0026comp-\u003elock_key#2);   lock(\u0026comp-\u003elock_key#2);  *** DEADLOCK *** Call Trace:  \u003cTASK\u003e  dump_stack_lvl+0x69/0xa0  print_deadlock_bug.cold+0xbd/0xca  __lock_acquire+0x1671/0x2ec0  lock_acquire+0x10e/0x2e0  down_read+0x95/0x430  mlx5_devcom_for_each_peer_begin+0x4e/0xe0 [mlx5_core]  mlx5e_tc_del_flow+0x11d/0xa70 [mlx5_core]  mlx5e_flow_put+0x99/0x100 [mlx5_core]  __mlx5e_add_fdb_flow+0x409/0xf00 [mlx5_core]  mlx5e_configure_flower+0x2a86/0x4100 [mlx5_core]  mlx5e_rep_setup_tc_cls_flower+0x12f/0x1b0 [mlx5_core]  mlx5e_rep_setup_tc_cb+0x153/0x750 [mlx5_core]  tc_setup_cb_add+0x1dc/0x470  fl_change+0x2f4d/0x626d [cls_flower]  tc_new_tfilter+0x79b/0x2310  rtnetlink_rcv_msg+0x778/0xad0  do_syscall_64+0x70/0x960  entry_SYSCALL_64_after_hwframe+0x4b/0x53  \u003c/TASK\u003e",
  "id": "DEBIAN-CVE-2026-80739",
  "modified": "2026-09-19T21:47:30.863271159Z",
  "published": "2026-09-03T13:06:13.040Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-80739"
    }
  ],
  "upstream": [
    "CVE-2026-80739"
  ]
}