Skip to content
Heist/ feed
Back to feed
HighFix available

net: ipa: fix stalled modem TX queue after runtime resume

Type: advisorySources: OSV

In the Linux kernel, the following vulnerability has been resolved: net: ipa: fix stalled modem TX queue after runtime resume ipa_start_xmit() unconditionally stops the TX queue before calling pm_runtime_get(), relying on the wake scheduled by runtime resume (ipa_modem_wake_queue_work()) to restart it once power is ACTIVE. But that work is queued from within the runtime resume callback, before the device's power state reaches RPM_ACTIVE, so it can run while the device is still RPM_RESUMING. The wake is then consumed too early: the transmit it restarts stops the queue again, pm_runtime_get() returns -EINPROGRESS without arranging any future wake (deferred_resume exists only for RPM_SUSPENDING), and after the resume completes nothing is left to wake the queue. Transmit stalls permanently: packets pile up in the qdisc behind the stopped queue, the device runtime-suspends, and since the netdev registers no ndo_tx_timeout the watchdog never fires. Observed on SM7635 (Fairphone 6) as the cellular data path going permanently deaf within hours, RX included, since nothing resumes the suspended endpoints. Close the window by making the wake work wait for the resume to complete (pm_runtime_get_sync()) before waking the queue. Every queue stop is then guaranteed a later wake that happens while power is ACTIVE; a transmit racing a new suspend/resume cycle re-schedules the work. If the device could not be resumed, wake the queue anyway so pending packets are dropped by the transmit path ra

Products
Kernel
Affected versions
Not specified
Fixed versions
6.12.109, 6.18.50, 7.2.4
CVEs
CVE-2026-80997
Confirmed fixed CVEs
Not specified
Updated in this feed
4 Nov 2026, 16:05 UTC · Revision 1

Source evidence

net: ipa: fix stalled modem TX queue after runtime resume

core-osv · Original source

Published 11 Sept 2026, 19:42 UTC

In the Linux kernel, the following vulnerability has been resolved: net: ipa: fix stalled modem TX queue after runtime resume ipa_start_xmit() unconditionally stops the TX queue before calling pm_runtime_get(), relying on the wake scheduled by runtime resume (ipa_modem_wake_queue_work()) to restart it once power is ACTIVE. But that work is queued from within the runtime resume callback, before the device's power state reaches RPM_ACTIVE, so it can run while the device is still RPM_RESUMING. The wake is then consumed too early: the transmit it restarts stops the queue again, pm_runtime_get() returns -EINPROGRESS without arranging any future wake (deferred_resume exists only for RPM_SUSPENDING), and after the resume completes nothing is left to wake the queue. Transmit stalls permanently: packets pile up in the qdisc behind the stopped queue, the device runtime-suspends, and since the netdev registers no ndo_tx_timeout the watchdog never fires. Observed on SM7635 (Fairphone 6) as the cellular data path going permanently deaf within hours, RX included, since nothing resumes the suspended endpoints. Close the window by making the wake work wait for the resume to complete (pm_runtime_get_sync()) before waking the queue. Every queue stop is then guaranteed a later wake that happens while power is ACTIVE; a transmit racing a new suspend/resume cycle re-schedules the work. If the device could not be resumed, wake the queue anyway so pending packets are dropped by the transmit path ra

osv:CVE-2026-80997

Kernel

Fixed versions: 6.12.109, 6.18.50, 7.2.4

Complete source record
{
  "id": "9fee7d3214fe145e1a885d51ae3ce00d78276c95f0067399db51abaeffc1ac93",
  "url": "https://osv.dev/vulnerability/CVE-2026-80997",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "net: ipa: fix stalled modem TX queue after runtime resume",
    "summary": "In the Linux kernel, the following vulnerability has been resolved: net: ipa: fix stalled modem TX queue after runtime resume ipa_start_xmit() unconditionally stops the TX queue before calling pm_runtime_get(), relying on the wake scheduled by runtime resume (ipa_modem_wake_queue_work()) to restart it once power is ACTIVE. But that work is queued from within the runtime resume callback, before the device's power state reaches RPM_ACTIVE, so it can run while the device is still RPM_RESUMING. The wake is then consumed too early: the transmit it restarts stops the queue again, pm_runtime_get() returns -EINPROGRESS without arranging any future wake (deferred_resume exists only for RPM_SUSPENDING), and after the resume completes nothing is left to wake the queue. Transmit stalls permanently: packets pile up in the qdisc behind the stopped queue, the device runtime-suspends, and since the netdev registers no ndo_tx_timeout the watchdog never fires. Observed on SM7635 (Fairphone 6) as the cellular data path going permanently deaf within hours, RX included, since nothing resumes the suspended endpoints. Close the window by making the wake work wait for the resume to complete (pm_runtime_get_sync()) before waking the queue. Every queue stop is then guaranteed a later wake that happens while power is ACTIVE; a transmit racing a new suspend/resume cycle re-schedules the work. If the device could not be resumed, wake the queue anyway so pending packets are dropped by the transmit path ra",
    "evidence": "osv:CVE-2026-80997",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "6.12.109",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.18.50",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "7.2.4",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "high",
    "structured": {
      "id": "CVE-2026-80997",
      "aliases": [
        "CVE-2026-80997"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "688de12f080f10dff8f3ddc80103e432ad8deb0b"
                },
                {
                  "fixed": "30d5226bac52073c91ce85c2dcff93b866baefdb"
                },
                {
                  "fixed": "62da38b4b3a0dd74a3e0eecf4992d40385924205"
                },
                {
                  "fixed": "30cef9c1229a36a9c80edb29296459849a2fbaa3"
                },
                {
                  "fixed": "3cbfd627ee720f3d2460d2cbe2fe9e4130240db6"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-80997.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.9.0"
                },
                {
                  "fixed": "6.12.109"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.13.0"
                },
                {
                  "fixed": "6.18.50"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.19.0"
                },
                {
                  "fixed": "7.2.4"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-80997.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:37.192272431Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/30cef9c1229a36a9c80edb29296459849a2fbaa3",
        "https://git.kernel.org/stable/c/30d5226bac52073c91ce85c2dcff93b866baefdb",
        "https://git.kernel.org/stable/c/3cbfd627ee720f3d2460d2cbe2fe9e4130240db6",
        "https://git.kernel.org/stable/c/62da38b4b3a0dd74a3e0eecf4992d40385924205",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80997.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-80997",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80997.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-80997",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 504491,
  "published_at": "2026-09-11T19:42:52.215+00:00"
}