[
https://issues.apache.org/jira/browse/FLUME-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roshan Naik reassigned FLUME-2798:
----------------------------------
Assignee: Roshan Naik
> Malformed Syslog messages can lead to OutOfMemoryException
> ----------------------------------------------------------
>
> Key: FLUME-2798
> URL: https://issues.apache.org/jira/browse/FLUME-2798
> Project: Flume
> Issue Type: Bug
> Components: Sinks+Sources
> Affects Versions: v1.4.0, v1.5.0, v1.6.0
> Reporter: Phil D'Amore
> Assignee: Roshan Naik
> Priority: Critical
> Attachments: FLUME-2798.patch
>
>
> It's possible for a client submitting syslog data which is malformed in
> various ways to convince SyslogUtils.extractEvent to continually fill the
> ByteArrayOutputStream it uses to collect the event until the agent runs out
> of memory. Since the OOM condition affects the whole agent, it's possible
> that a client sending such data (due to accident or malicious intent) to
> disable the agent, as long as it remains connected.
> Note that this is probably only possible using SyslogTcpSource although the
> fix touches common code in SyslogUtils.java.
> The issue can happen in two ways:
> Scenario 1: Send a message like this:
> {{<> some more stuff here}}
> This causes a NumberFormatException:
> {code}
> Sep 11, 2015 2:27:07 AM org.jboss.netty.channel.SimpleChannelHandler
> WARNING: EXCEPTION, please implement
> org.apache.flume.source.SyslogTcpSource$syslogTcpHandler.exceptionCaught()
> for proper handling.
> java.lang.NumberFormatException: For input string: ""
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:504)
> at java.lang.Integer.parseInt(Integer.java:527)
> at org.apache.flume.source.SyslogUtils.buildEvent(SyslogUtils.java:198)
> at
> org.apache.flume.source.SyslogUtils.extractEvent(SyslogUtils.java:344)
> at
> org.apache.flume.source.SyslogTcpSource$syslogTcpHandler.messageReceived(SyslogTcpSource.java:76)
> at
> org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
> at
> org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:94)
> at
> org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:364)
> at
> org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:238)
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:38)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> This exception does not get handled, and it happens before reset() can be
> called. The result is that the state machine in SyslogUtils gets stuck in
> the DATA state, and all subsequent data just gets appended to the baos, while
> the above exception streams to the log. Eventually the agent runs out of
> memory.
> Scenario 2: Send some data like this:
> {{<123...........}}
> No length checking is done in the PRIO state so you could potentially fill
> the agent memory this way too.
> I'm attaching a patch which handles both of these issues and adds more
> exception handling to buildEvent to make sure that reset() is called in
> future unforeseen situations.
> Thanks also to [~roshan_naik] for helping to make this patch better.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
