# CVE-2026-98749: tty: serial: max3100: shut down timer before freeing port

CVE-2026-98749 is fixed in 2 products on 1 platform, first by DEBIAN-CVE-2026-98749, released October 19, 2026. It is not reported as exploited. Patch Radar priority: Routine.

- Web page: https://patchblox.com/security/cve/CVE-2026-98749
- Priority: Routine
- CVSS: 5.7 (Moderate)
- EPSS: 0.0019
- CISA KEV: not listed
- Exploited (vendor report): no
- Publicly disclosed: no
- Published: Oct 18, 2026
- Vendor advisory: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-98749

## Description

In the Linux kernel, the following vulnerability has been resolved:  tty: serial: max3100: shut down timer before freeing port  max3100_shutdown() stops the polling timer but returns early during system suspend. If the SPI device is unbound before resume, the serial core does not call max3100_shutdown() again, so max3100_remove() frees the port while the timer remains armed. max3100_timeout() may then access the freed port and re-arm the timer.  Add final timer teardown to max3100_remove() and use timer_shutdown_sync() to prevent a racing callback from re-arming it. Also free the IRQ and destroy the workqueue there before freeing the port. Keep timer_delete_sync() in max3100_shutdown() so that a subsequent open() can re-arm the timer.  The workqueue is created before request_irq() and destroyed on both request_irq() failure and normal shutdown. Its presence at remove thus identifies the IRQ left registered when suspend bypasses shutdown.  Free the IRQ before destroying the workqueue, in both max3100_shutdown() and max3100_remove(), and cancel the pending work in between. free_irq() waits for a running interrupt handler to finish and no new handler can start afterwards, so a racing handler cannot queue work on a workqueue that is being destroyed; the force_end_work check in max3100_dowork() only narrows that window, as a handler delayed between the check and queue_work() could still run after the teardown has cleared the workqueue pointer. Cancelling the work also keeps destroy_workqueue() from waiting on a queued work item in case remove() ever runs while the freezable workqueue is still frozen, e.g. device removal during the resume window, before workqueues are thawed.  This issue was found by an in-house static analysis tool.

## Where it's fixed

| Platform | Product | Fixed in | Fix | Released |
|---|---|---|---|---|
| Linux | linux Debian 13.5 (trixie) | 6.12.113-1 | [DEBIAN-CVE-2026-98749](https://patchblox.com/security/data/fix/linux/debian-cve-2026-98749.md) | Oct 19, 2026 |
| Linux | linux Debian 14 | 7.2.10-1 | [DEBIAN-CVE-2026-98749](https://patchblox.com/security/data/fix/linux/debian-cve-2026-98749.md) | Oct 19, 2026 |
| Linux | linux-6.12 Debian 12.15 (bookworm) | 6.12.113-1~deb12u1 | [DEBIAN-CVE-2026-98749](https://patchblox.com/security/data/fix/linux/debian-cve-2026-98749.md) | Oct 19, 2026 |

---

Data as of 2026-11-08T13:06:02Z UTC. Source: Patchblox Patch Radar (https://patchblox.com/security/patch-radar). Patchblox finds out-of-date software on Windows, macOS and Linux and updates it through release rings: https://patchblox.com/demo

Free to use with attribution: show "Data: Patchblox Patch Radar" with a link to https://patchblox.com/security/patch-radar. Terms, including what needs a written agreement: https://patchblox.com/security/patch-radar/use-the-data

Product names, logos and trademarks shown on Patch Radar belong to their respective owners. They are used only to identify the software each security fix applies to and to help readers find their platform. Their use does not imply any affiliation with, or endorsement by, those owners, and Patchblox is not affiliated with any of them.