In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
net: ipa: fix stalled modem TX queue after runtime resume<\/p>\n
ipa_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.<\/p>\n
Close 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.<\/p>\n
The 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.<\/p>\n
With 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.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
net: ipa: fix stalled modem TX queue after runtime resume<\/p>\n
ipa_start_xmit() unconditionally stops the TX queue before calling
\npm_ru<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-21330","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/21330","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=21330"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=21330"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=21330"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}