[erlang-bugs] file:sendfile/5 bug and possible DOS attack

Lukas Larsson <>
Mon Jan 27 15:22:14 CET 2014

I've now implemented the fix I proposed for this. You can view the fix 
If the tests pass I will merge it asap.


On 22/10/13 09:25, Lukas Larsson wrote:
> Hello Christopher,
> The reason behind favoring the async threads is that non-blocking 
> sendfile calls on some OSs sometimes behave incorrectly. Unfortunately 
> at the moment I cannot remember which OS it was, but it is none of the 
> majorly used ones.
> It is of course not good that this feature opens up the VM for that 
> kind of attack.
> My suggestion of a fix would be to add an option to sendfile/5 that 
> specifies whether async threads should be used or not, and default 
> this to false. This leaves the choice up to the user of sendfile/5 and 
> defaults to be safe from attacks.
> Thanks for reporting this quite serious flaw in the sendfile 
> implementation!
> Lukas
> On 21/10/13 15:02, Christopher Faulet wrote:
>> Hi,
>> This summer, at my company, we encountered a problem that leads to the
>> VM hanging. After some painful investigation, we found that the problem
>> came from thefile:sendfile/5  function.
>> When async threads are enabled, during a call tofile:sendfile/5  the
>> efile driver sets the TCP socket in blocking mode. So an unresponsive
>> client can block the sendfile() syscall, thus blocking an async thread.
>> With few unresponsive clients, all async threads can be blocked and the
>> VM hangs (no more I/O are possible).
>> I attached 2 escripts to reproduce the bug:
>> * server - listen on a socket and wait a client connection to send a
>> large file using gen_tcp:send orfile:sendfile:
>>    $> ./server 1234 /path/to/bigfile send
>> or
>>    $> ./server 1234 /path/to/bigfile sendfile
>> * slow_client - open a connection on the server and read incoming data
>> with a sleep of 10 seconds between each read:
>>    $> ./slow_client 1234
>> The server is started with 1 async thread. Every 2 seconds the server
>> tries to read the file info. When "sendfile" method is used, the call to
>> file:read_file_info/1  is blocked; all I/O are blocked, the VM is out.
>> When async threads are disabled or when the "send" method is used, there
>> is no problem. The file is sent (slowly) and the VM is still responsive.
>> So it is very easy to do a DOS attack on systems that use
>> file:sendfile/5  with async threads enabled. The problem comes from a
>> design choice of the efile driver. I have no solution to propose, but it
>> could be a good idea to add a warning in the documentation of
>> file:sendfile/5  (especially that the documentation encourages the use of
>> async threads).
>> Regards,
>> _______________________________________________
>> erlang-bugs mailing list
>> http://erlang.org/mailman/listinfo/erlang-bugs
> _______________________________________________
> erlang-bugs mailing list
> http://erlang.org/mailman/listinfo/erlang-bugs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20140127/2fc3bed7/attachment.html>

More information about the erlang-bugs mailing list