{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.180-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.100-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.5-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  net/9p: fix race condition on rdma-\u003estate in trans_rdma.c  The rdma-\u003estate field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition:  - recv_done() running in softirq completion context sets   rdma-\u003estate = P9_RDMA_FLUSHING without acquiring req_lock  - p9_cm_event_handler() modifies rdma-\u003estate at multiple points   (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without   req_lock  - rdma_request() uses spin_lock_irqsave(\u0026rdma-\u003ereq_lock, flags) to   protect the read-modify-write of rdma-\u003estate  The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown.  Fix by adding req_lock protection to all rdma-\u003estate modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context.  Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma-\u003estate with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.",
  "id": "DEBIAN-CVE-2026-72491",
  "modified": "2026-09-14T16:47:47.406008244Z",
  "published": "2026-08-15T06:22:23.400Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-72491"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-72491"
  ]
}