* SECURITY UPDATE: denial of service via crafted WebSocket frame with a 64-bit payload length whose most significant bit is set. The extended payload length read in WsFrameBase.processRemainingHeader() was assembled into a Java long without validation. With bit 63 set the value became negative, which the consumer then used as a loop bound, causing an infinite loop and exhausting CPU on the server thread. Affects Apache Tomcat 7.0.0 to 7.0.104, 8.5.0 to 8.5.56, 9.0.0.M1 to 9.0.36, and 10.0.0-M1 to 10.0.0-M6. - debian/patches/CVE-2020-13935.patch: validate the 64-bit payload length in processRemainingHeader() and reject frames with a negative value by throwing a WsIOException carrying a PROTOCOL_ERROR close reason; add the wsFrame.payloadMsbInvalid message to LocalStrings.properties. Also fold the companion fix 4c04982870 to apply the same validation to the legacy org/apache/catalina/websocket/WsFrame parser (still packaged in catalina.jar via WebSocketServlet), and the regression follow-up 34d19fbe24 in WsFrameBase.byteArrayToLong() (0xFF -> 0xFFL) that prevents silent corruption of payload lengths >= 4 bytes from int-shift promotion. Additionally fold b517002093 to apply the same 0xFF -> 0xFFL fix to the parallel helper Conversions.byteArrayToLong() in java/org/apache/catalina/util/Conversions.java, which is the helper used by the legacy WsFrame parser; without it the new < 0 check in the legacy parser would falsely reject legitimate large frames. Backport of upstream commits f9f75c14, 34d19fbe24, 4c04982870 and b517002093 (https://github.com/apache/tomcat/commit/f9f75c14 https://github.com/apache/tomcat/commit/34d19fbe24 https://github.com/apache/tomcat/commit/4c04982870 https://github.com/apache/tomcat/commit/b517002093) - CVE-2020-13935