You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While reproducing rapid7/metasploit-framework#12888 on Linux, I also discovered that at least with the HTTP transport, it is easy to catch mettle in a bad state when it does not recognize that the connection on the upstream of a network connection is closed, causing it to attempt a socket write and it ends up segfaulting. This can be reproduced by trying to send data across the connection in step 4 of rapid7/metasploit-framework#12888.
It appears that this is a possibility across all connection behaviors as a race condition, but it is especially bad when the client sends some data and closes the connection right away (the server on the other end closed the connection right away, but ~30s later the channel was not marked closed):
While reproducing rapid7/metasploit-framework#12888 on Linux, I also discovered that at least with the HTTP transport, it is easy to catch mettle in a bad state when it does not recognize that the connection on the upstream of a network connection is closed, causing it to attempt a socket write and it ends up segfaulting. This can be reproduced by trying to send data across the connection in step 4 of rapid7/metasploit-framework#12888.
It appears that this is a possibility across all connection behaviors as a race condition, but it is especially bad when the client sends some data and closes the connection right away (the server on the other end closed the connection right away, but ~30s later the channel was not marked closed):
In a bi-directional case:
Server:
Client:
Mettle:
The text was updated successfully, but these errors were encountered: