Last Modified: Apr 22, 2021
See more info
Known Affected Versions:
14.1.0, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 14.1.2, 15.0.0, 15.0.1
15.1.0, 18.104.22.168, 22.214.171.124
Opened: Mar 07, 2019
Related AskF5 Article: K36350541
TMSH does not correctly handle absence of input stream after closing an interactive SSH session and remains active in an infinite loop using 100% CPU.
The equivalent of one CPU core is utilized to 100% by the TMSH process. It may be mostly scheduled on one core or spread over multiple control plane cores.
If TMSH is a process group leader, it is not killed when the parent shell is terminated upon SSH session close. This is a rare case, as TMSH must be deliberately promoted to a process group leader, e.g., with the 'setsid' command. Usually the shell process is a group leader and, when it is terminated upon SSH session close, it kills its child processes, including TMSH.
TMSH should not be intentionally promoted to a process group leader. You can kill all TMSH processes using the command: killall -9 tmsh Warning: This command kills both abandoned and in-use TMSH processes. The latter can include other users' TMSH shells, and even system-level processes invoking the TMSH utility internally. Killing all TMSH processes can lead to various unexpected failures. You can use the 'top' command to see which TMSH process is using high CPU (e.g., 90% or more), and kill just those, as those are the likely zombie processes. pstree may also show the problem TMSH processes with no sshd ancestor. You can kill specific TMSH processes using the command: kill -9 <pid> Where <pid> is the process ID of the TMSH instance to kill. Possible mitigation =================== Set a CLI idle timeout to a value lower than the sshd idle timeout (which is not set by default): tmsh modify cli global-settings idle-timeout <timeout in minutes>
I/O error handling in TMSH has been corrected, so it no longer ignores absence of input stream, which led to infinite loop.