All vulnerabilities
CVE-2026-98749

Linux: tty: serial: max3100: shut down timer before freeing port

Linux LinuxOperating systems
CVSS
NoneNot scored
ExploitationNo known exploitationNot in CISA KEV, which does not prove it is unexploitedCISA KEV
Exploit odds (EPSS)0.18%Chance of exploitation activity in the next 30 days, higher than 6% of CVEs. Scored 23 Oct 2026FIRST EPSS
Fixed in158a07da2da720f2f98b4bea129212c6805d8ee0Also 2c8614981d3e6e000427de0ab2426ab68274d850, 247b8f680876313586aed4d267bfcceddc2b4901CVE List
Published18 Oct 2026Updated 21 Oct 2026CVE List

What fixes it

  • 158a07da2da720f2f98b4bea129212c6805d8ee0LinuxCVE List
  • 2c8614981d3e6e000427de0ab2426ab68274d850LinuxCVE List
  • 247b8f680876313586aed4d267bfcceddc2b4901LinuxCVE List

A fixed version on one release line is not the upgrade target for every line. Check your exact version and any vendor backports.

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.

Text from CVE List

Affected versions 12

  • Linuxaffected: 7831d56b0a3544cbb6f82f76c34ca95e24d5b676 before 158a07da2da720f2f98b4bea129212c6805d8ee0CVE List
  • Linuxaffected: 7831d56b0a3544cbb6f82f76c34ca95e24d5b676 before fb668620e3b163962dabe1a674725a07aa44ff4aCVE List
  • Linuxaffected: 7831d56b0a3544cbb6f82f76c34ca95e24d5b676 before 2c8614981d3e6e000427de0ab2426ab68274d850CVE List
  • Linuxaffected: 7831d56b0a3544cbb6f82f76c34ca95e24d5b676 before 247b8f680876313586aed4d267bfcceddc2b4901CVE List
  • Linuxaffected: 7831d56b0a3544cbb6f82f76c34ca95e24d5b676 before db0949bbd06db0a75b4b1076f1e25194be7d956aCVE List
  • Linuxaffected: 2.6.30CVE List
  • Linuxunaffected: all versions before 2.6.30CVE List
  • Linuxunaffected: 6.6.160 through 6.6.*CVE List
  • Linuxunaffected: 6.12.113 through 6.12.*CVE List
  • Linuxunaffected: 6.18.56 through 6.18.*CVE List
  • Linuxunaffected: 7.2.10 through 7.2.*CVE List
  • Linuxunaffected: 7.3CVE List

References 5