We have a mechanism in place to prevent someone tricking the services in to allocating lots of memory by sending a massive XML-RPC message. However that mechanism is buggy and results in a traceback when triggered: > 2021-03-09 07:48:31 ERROR vsmserver: Unhandled XMLRPC exception: <type 'exceptions.TypeError'> unsupported operand type(s) for -: 'NoneType' and 'int' Traceback (most recent call last): > File "/opt/thinlinc/modules/thinlinc/vsm/asyncbase.py", line 105, in ooOOOoOO0 > obj . handle_read_event ( ) > File "/usr/lib64/python2.7/asyncore.py", line 449, in handle_read_event > self.handle_read() > File "/usr/lib64/python2.7/asynchat.py", line 142, in handle_read > self.terminator = self.terminator - lb > TypeError: unsupported operand type(s) for -: 'NoneType' and 'int' The bug is that you cannot change the terminator inside collect_incoming_data(), which we do when we encounter an error. We have unit tests for this scenario, but they fail to test this specific detail. It was caught by the system tests instead. Fortunately this traceback still has the intended purpose of killing the request, so the protection is still in place. It just looks ugly in the logs.
This can also easily be provoked by doing: > (printf "POST /RPC2 HTTP/1.1\r\nContent-Length: 10000000\r\n\r\n" ; dd if=/dev/urandom) | nc localhost 9000 or > (printf "POST /RPC2 HTTP/1.1\r\nContent-Length: 10000000\r\n\r\n" ; dd if=/dev/urandom) | nc localhost 904
Works well now. No more noise in logs when running the above commands.
Could reproduce the problem. Tested the fix and it works fine.
