Vulnerability-Lookup

GHSA-4HQP-W86V-96HH

Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-09-13 09:32

Details

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 rather than stranded.

The STARTED power flag used to narrow this window: a wake running before the transmit path's stop suppressed that stop, but only once, as the flag was cleared by the first stop it absorbed. Removing the flag made a single transmit during an in-flight resume sufficient to strand the queue, which is the form observed.

With an accelerated reproducer (autosuspend delay shortened to 5 ms, ~20 packets/s of TX), an unpatched kernel stalled three times in 230 s / 4380 packets; with this patch the same test ran 3601 s / 70298 packets without a stall.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-80997"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-11T20:19:06Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipa: fix stalled modem TX queue after runtime resume\n\nipa_start_xmit() unconditionally stops the TX queue before calling\npm_runtime_get(), relying on the wake scheduled by runtime resume\n(ipa_modem_wake_queue_work()) to restart it once power is ACTIVE.\nBut that work is queued from within the runtime resume callback,\nbefore the device\u0027s power state reaches RPM_ACTIVE, so it can run\nwhile the device is still RPM_RESUMING.  The wake is then consumed\ntoo early: the transmit it restarts stops the queue again,\npm_runtime_get() returns -EINPROGRESS without arranging any future\nwake (deferred_resume exists only for RPM_SUSPENDING), and after the\nresume completes nothing is left to wake the queue.  Transmit stalls\npermanently: packets pile up in the qdisc behind the stopped queue,\nthe device runtime-suspends, and since the netdev registers no\nndo_tx_timeout the watchdog never fires.  Observed on SM7635\n(Fairphone 6) as the cellular data path going permanently deaf\nwithin hours, RX included, since nothing resumes the suspended\nendpoints.\n\nClose the window by making the wake work wait for the resume to\ncomplete (pm_runtime_get_sync()) before waking the queue.  Every\nqueue stop is then guaranteed a later wake that happens while power\nis ACTIVE; a transmit racing a new suspend/resume cycle re-schedules\nthe work.  If the device could not be resumed, wake the queue anyway\nso pending packets are dropped by the transmit path rather than\nstranded.\n\nThe STARTED power flag used to narrow this window: a wake running\nbefore the transmit path\u0027s stop suppressed that stop, but only once,\nas the flag was cleared by the first stop it absorbed.  Removing the\nflag made a single transmit during an in-flight resume sufficient to\nstrand the queue, which is the form observed.\n\nWith an accelerated reproducer (autosuspend delay shortened to 5 ms,\n~20 packets/s of TX), an unpatched kernel stalled three times in\n230 s / 4380 packets; with this patch the same test ran 3601 s /\n70298 packets without a stall.",
  "id": "GHSA-4hqp-w86v-96hh",
  "modified": "2026-09-13T09:32:10Z",
  "published": "2026-09-11T21:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80997"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/30cef9c1229a36a9c80edb29296459849a2fbaa3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/30d5226bac52073c91ce85c2dcff93b866baefdb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3cbfd627ee720f3d2460d2cbe2fe9e4130240db6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/62da38b4b3a0dd74a3e0eecf4992d40385924205"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CVE-2026-80997 (GCVE-0-2026-80997)

Vulnerability from cvelistv5 – Published: 2026-09-11 19:42 – Updated: 2026-09-13 06:29

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 rather than stranded. The STARTED power flag used to narrow this window: a wake running before the transmit path's stop suppressed that stop, but only once, as the flag was cleared by the first stop it absorbed. Removing the flag made a single transmit during an in-flight resume sufficient to strand the queue, which is the form observed. With an accelerated reproducer (autosuspend delay shortened to 5 ms, ~20 packets/s of TX), an unpatched kernel stalled three times in 230 s / 4380 packets; with this patch the same test ran 3601 s / 70298 packets without a stall.

Severity

7.5 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Assigner

Linux mitre root

References

4 references

URL	Tags
https://git.kernel.org/stable/c/30d5226bac52073c9…
https://git.kernel.org/stable/c/62da38b4b3a0dd74a…
https://git.kernel.org/stable/c/30cef9c1229a36a9c…
https://git.kernel.org/stable/c/3cbfd627ee720f3d2…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: 688de12f080f10dff8f3ddc80103e432ad8deb0b , < 30d5226bac52073c91ce85c2dcff93b866baefdb (git) Affected: 688de12f080f10dff8f3ddc80103e432ad8deb0b , < 62da38b4b3a0dd74a3e0eecf4992d40385924205 (git) Affected: 688de12f080f10dff8f3ddc80103e432ad8deb0b , < 30cef9c1229a36a9c80edb29296459849a2fbaa3 (git) Affected: 688de12f080f10dff8f3ddc80103e432ad8deb0b , < 3cbfd627ee720f3d2460d2cbe2fe9e4130240db6 (git)
Linux	Linux	Affected: 6.9 Unaffected: 0 , < 6.9 (semver) Unaffected: 6.12.109 , ≤ 6.12.* (semver) Unaffected: 6.18.50 , ≤ 6.18.* (semver) Unaffected: 7.2.4 , ≤ 7.2.* (semver) Unaffected: 7.3-rc1 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ipa/ipa_modem.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "30d5226bac52073c91ce85c2dcff93b866baefdb",
              "status": "affected",
              "version": "688de12f080f10dff8f3ddc80103e432ad8deb0b",
              "versionType": "git"
            },
            {
              "lessThan": "62da38b4b3a0dd74a3e0eecf4992d40385924205",
              "status": "affected",
              "version": "688de12f080f10dff8f3ddc80103e432ad8deb0b",
              "versionType": "git"
            },
            {
              "lessThan": "30cef9c1229a36a9c80edb29296459849a2fbaa3",
              "status": "affected",
              "version": "688de12f080f10dff8f3ddc80103e432ad8deb0b",
              "versionType": "git"
            },
            {
              "lessThan": "3cbfd627ee720f3d2460d2cbe2fe9e4130240db6",
              "status": "affected",
              "version": "688de12f080f10dff8f3ddc80103e432ad8deb0b",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ipa/ipa_modem.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.9"
            },
            {
              "lessThan": "6.9",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.109",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.50",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3-rc1",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.109",
                  "versionStartIncluding": "6.9",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.50",
                  "versionStartIncluding": "6.9",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2.4",
                  "versionStartIncluding": "6.9",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3-rc1",
                  "versionStartIncluding": "6.9",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipa: fix stalled modem TX queue after runtime resume\n\nipa_start_xmit() unconditionally stops the TX queue before calling\npm_runtime_get(), relying on the wake scheduled by runtime resume\n(ipa_modem_wake_queue_work()) to restart it once power is ACTIVE.\nBut that work is queued from within the runtime resume callback,\nbefore the device\u0027s power state reaches RPM_ACTIVE, so it can run\nwhile the device is still RPM_RESUMING.  The wake is then consumed\ntoo early: the transmit it restarts stops the queue again,\npm_runtime_get() returns -EINPROGRESS without arranging any future\nwake (deferred_resume exists only for RPM_SUSPENDING), and after the\nresume completes nothing is left to wake the queue.  Transmit stalls\npermanently: packets pile up in the qdisc behind the stopped queue,\nthe device runtime-suspends, and since the netdev registers no\nndo_tx_timeout the watchdog never fires.  Observed on SM7635\n(Fairphone 6) as the cellular data path going permanently deaf\nwithin hours, RX included, since nothing resumes the suspended\nendpoints.\n\nClose the window by making the wake work wait for the resume to\ncomplete (pm_runtime_get_sync()) before waking the queue.  Every\nqueue stop is then guaranteed a later wake that happens while power\nis ACTIVE; a transmit racing a new suspend/resume cycle re-schedules\nthe work.  If the device could not be resumed, wake the queue anyway\nso pending packets are dropped by the transmit path rather than\nstranded.\n\nThe STARTED power flag used to narrow this window: a wake running\nbefore the transmit path\u0027s stop suppressed that stop, but only once,\nas the flag was cleared by the first stop it absorbed.  Removing the\nflag made a single transmit during an in-flight resume sufficient to\nstrand the queue, which is the form observed.\n\nWith an accelerated reproducer (autosuspend delay shortened to 5 ms,\n~20 packets/s of TX), an unpatched kernel stalled three times in\n230 s / 4380 packets; with this patch the same test ran 3601 s /\n70298 packets without a stall."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:N - Qualcomm IPA is the cellular WAN datapath on phones and similar devices. Remote packets on that internet-facing path wake runtime-suspended IPA via the suspend interrupt, resume endpoints, and induce TX (TCP RST/ACK or ICMP) through ipa_start_xmit during the resume window.\nAC:L - After the 500ms autosuspend delay, a single TX while resume is still RPM_RESUMING permanently strands the queue. The attacker controls the traffic that starts resume and the TX that consumes the premature wake, and can retry the idle-then-send pattern until the pm_wq race hits.\nPR:N - Triggering requires only unauthenticated packets to the device\u0027s cellular IP (or any induced TX on an already-up rmnet_ipa interface). No local account, capability, or init-namespace privilege is needed; modem-stack interface bring-up is an infrastructure prerequisite.\nUI:N - No victim interaction is required beyond normal operation of an already-up cellular interface. The attacker only needs to wait for runtime autosuspend and send packets that cause TX during resume.\nS:U - The stall is confined to the IPA modem netdev TX/RX path in the same host kernel and does not cross a VM, IOMMU, or sandbox security boundary.\nC:N - The defect only mismanages netif TX queue start/stop around runtime PM. There is no out-of-bounds access, use-after-free, or other information-disclosure primitive.\nI:N - No memory corruption, arbitrary write, or control-flow hijacking occurs. Packets are stranded or later dropped; the attacker cannot modify kernel or user data.\nA:H - When the premature wake is consumed during RPM_RESUMING, the TX queue stays stopped with no ndo_tx_timeout recovery. Packets pile up, IPA runtime-suspends, and RX also dies, permanently silencing the cellular data path until reboot."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-13T06:29:00.065Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/30d5226bac52073c91ce85c2dcff93b866baefdb"
        },
        {
          "url": "https://git.kernel.org/stable/c/62da38b4b3a0dd74a3e0eecf4992d40385924205"
        },
        {
          "url": "https://git.kernel.org/stable/c/30cef9c1229a36a9c80edb29296459849a2fbaa3"
        },
        {
          "url": "https://git.kernel.org/stable/c/3cbfd627ee720f3d2460d2cbe2fe9e4130240db6"
        }
      ],
      "title": "net: ipa: fix stalled modem TX queue after runtime resume",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-80997",
    "datePublished": "2026-09-11T19:42:52.215Z",
    "dateReserved": "2026-08-26T14:34:25.812Z",
    "dateUpdated": "2026-09-13T06:29:00.065Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.