Bug 1100491 - Buffer overflow when using web sockets
Summary: Buffer overflow when using web sockets
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ER6
: EAP 6.3.0
Assignee: Rémy Maucherat
QA Contact: Radim Hatlapatka
Russell Dickenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-22 22:03 UTC by Stuart Douglas
Modified: 2014-06-28 15:26 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-06-28 15:26:02 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Stuart Douglas 2014-05-22 22:03:27 UTC
I have observed this buffer overflow when running the autobahn test suite against the latest JBoss Web code. This appears to be a differed issue to https://bugzilla.redhat.com/show_bug.cgi?id=1097763.

16:58:49,454 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/jboss-as-autobahn].[default]] (http-/127.0.0.1:8080-86) JBWEB000374: IO listener processing for servlet default threw exception: java.nio.charset.CoderMalfunctionError: java.nio.BufferOverflowException
	at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:565) [rt.jar:1.7.0_51]
	at org.apache.tomcat.websocket.WsRemoteEndpointImplBase$TextMessageSendHandler.write(WsRemoteEndpointImplBase.java:675) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at org.apache.tomcat.websocket.WsRemoteEndpointImplBase$TextMessageSendHandler.onResult(WsRemoteEndpointImplBase.java:696) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.endMessage(WsRemoteEndpointImplBase.java:317) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at org.apache.tomcat.websocket.WsRemoteEndpointImplBase$EndMessageHandler.onResult(WsRemoteEndpointImplBase.java:463) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.clearHandler(WsRemoteEndpointImplServer.java:217) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:109) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsWriteListener.onWritePossible(WsHttpUpgradeHandler.java:215) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:605) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:228) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:935) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: java.nio.BufferOverflowException
	at java.nio.Buffer.nextPutIndex(Buffer.java:513) [rt.jar:1.7.0_51]
	at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:163) [rt.jar:1.7.0_51]
	at org.apache.tomcat.util.buf.Utf8Encoder.encodeNotHasArray(Utf8Encoder.java:168) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at org.apache.tomcat.util.buf.Utf8Encoder.encodeLoop(Utf8Encoder.java:39) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final]
	at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:561) [rt.jar:1.7.0_51]
	... 21 more

Comment 1 Rémy Maucherat 2014-05-24 17:37:11 UTC
This is (apparently) internal to the Tomcat code, but I cannot see any problem with it.

Comment 2 Stuart Douglas 2014-05-26 15:31:35 UTC
It looks like there is only one buffer that is used by all writes:

org.apache.tomcat.websocket.WsRemoteEndpointImplBase#encoderBuffer

I wonder if there is any chance that this is being used by multiple threads at once? Otherwise I can't see how this could happen, barring a bug in the encoder itself.

Comment 3 Rémy Maucherat 2014-05-26 16:18:30 UTC
This is called by the async IO completion onWritePossible, but I see nothing really preventing the user code from keeping using sendString, and there are no syncs. I think the idea is to run into the state check stateMachine.textStart().

I'm reluctant to make changes to the Tomcat code right now, I am probably more likely to cause new issues than fix things.

Comment 4 Kabir Khan 2014-06-03 19:16:20 UTC
Fixed by https://bugzilla.redhat.com/show_bug.cgi?id=1104206

Comment 5 Radim Hatlapatka 2014-06-12 14:22:42 UTC
I wasn't able to reproduce the Stuarts issue when running autobahn testsuite. I have tried it with EAP 6.3.0.ER5, which uses jbossweb-7.4.2.Final-redhat-1.jar, version which should be exposed, and I don't see the error

@Stuart could you please verify whether you are still seeing BufferOverflow exception with EAP 6.3.0.ER7.

Comment 6 Stuart Douglas 2014-06-12 14:43:11 UTC
It was very intermittent when I saw it, I think I only saw it twice in all the runs I did.

It may have already been fixed by some of the other web socket changes.

Comment 7 Radim Hatlapatka 2014-06-12 14:56:18 UTC
I've made multiple runs using both EAP 6.3.0.ER5 and EAP 6.3.0.ER7 and I haven't seen this issue. As I haven't seen it I am setting it as verified.


Note You need to log in before you can comment on or make changes to this bug.