{"api_version":"1","generated_at":"2026-09-20T21:39:28+00:00","cve":"CVE-2026-80997","urls":{"html":"https://cve.report/CVE-2026-80997","api":"https://cve.report/api/cve/CVE-2026-80997.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-80997","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-80997"},"summary":{"title":"net: ipa: fix stalled modem TX queue after runtime resume","description":"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's 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's 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.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-09-11 20:19:06","updated_at":"2026-09-13 07:17:06"},"problem_types":[],"metrics":[{"version":"3.1","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","score":"7.5","severity":"HIGH","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","baseScore":7.5,"baseSeverity":"HIGH","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"7.5","severity":"HIGH","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","data":{"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"}}],"references":[{"url":"https://git.kernel.org/stable/c/62da38b4b3a0dd74a3e0eecf4992d40385924205","name":"https://git.kernel.org/stable/c/62da38b4b3a0dd74a3e0eecf4992d40385924205","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/30d5226bac52073c91ce85c2dcff93b866baefdb","name":"https://git.kernel.org/stable/c/30d5226bac52073c91ce85c2dcff93b866baefdb","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/3cbfd627ee720f3d2460d2cbe2fe9e4130240db6","name":"https://git.kernel.org/stable/c/3cbfd627ee720f3d2460d2cbe2fe9e4130240db6","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/30cef9c1229a36a9c80edb29296459849a2fbaa3","name":"https://git.kernel.org/stable/c/30cef9c1229a36a9c80edb29296459849a2fbaa3","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-80997","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80997","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 688de12f080f10dff8f3ddc80103e432ad8deb0b 30d5226bac52073c91ce85c2dcff93b866baefdb git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 688de12f080f10dff8f3ddc80103e432ad8deb0b 62da38b4b3a0dd74a3e0eecf4992d40385924205 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 688de12f080f10dff8f3ddc80103e432ad8deb0b 30cef9c1229a36a9c80edb29296459849a2fbaa3 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 688de12f080f10dff8f3ddc80103e432ad8deb0b 3cbfd627ee720f3d2460d2cbe2fe9e4130240db6 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.9","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.9 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.109 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.50 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.4 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3-rc1 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":{"cve_year":"2026","cve_id":"80997","cve":"CVE-2026-80997","epss":"0.006030000","percentile":"0.470080000","score_date":"2026-09-14","updated_at":"2026-09-15 00:00:42"},"legacy_qids":[]},"source_records":{"cve_program":{"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's 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's 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's 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"},"nvd":{"publishedDate":"2026-09-11 20:19:06","lastModifiedDate":"2026-09-13 07:17:06","problem_types":[],"metrics":{"cvssMetricV31":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","baseScore":7.5,"baseSeverity":"HIGH","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"},"exploitabilityScore":3.9,"impactScore":3.6}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"80997","Ordinal":"1","Title":"net: ipa: fix stalled modem TX queue after runtime resume","CVE":"CVE-2026-80997","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"80997","Ordinal":"1","NoteData":"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's 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's 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.","Type":"Description","Title":"net: ipa: fix stalled modem TX queue after runtime resume"}]}}}