[Openswan Users] Pluto restart caused by incoming packet possible DOS
erich.titl at think.ch
Sat May 2 18:32:44 EDT 2009
Paul Wouters schrieb:
> On Thu, 30 Apr 2009, Erich Titl wrote:
>>>> Apr 30 08:57:27 gatekeeper-internal pluto: FATAL ERROR: packet
>>>> from 188.8.131.52:47156: unable to malloc 0 bytes for message buffer
>>>> in comm_handle()
>>> Are you sure your server did not just leak memory and ran out of ram?
>>> what the error implies.
>> The server definitely did not run out of memory, I am running cacti
>> against it and the graph does not show anything alike. Also these
>> servers typically run 7x24 for months and years with many tunnels open
>> and I never saw anything alike.
> Well, check the code...
> comm_handle(const struct iface_port *ifp)
> static struct msg_digest *md;
> md = alloc_md();
> Note that nothing of the packet is actually used here, and you crashed.
> You did not crash on a malicious packet, you crashed do to an internal
Of course I do not have your deep insight to pluto's operation, but
pluto did not crash, it stopped gracefully on an allocation of 0 bytes.
Looking at the code I _believe_ it must be due to the following, which
is way past alloc_md
/* Clone actual message contents
* and set up md->packet_pbs to describe it.
, clone_bytes(_buffer, packet_len, "message buffer in
, clone_bytes(bigbuffer, packet_len, "message buffer in
, packet_len, "packet");
because the error message is exactly this one. Now packet_len is 0 in
this case, so no copying can be done anyway.
Looking that the packet_len is determined at
packet_len = recvfromto(ifp->fd, bigbuffer
, sizeof(bigbuffer), /*flags*/0
, &from.sa, &from_len
, &to.sa, &to_len);
and is not modified until to some code in the NAT_TRAVERSAL stuff
recvfromto returns either the return from recvmsg or from revcfrom. If I
understand the manual correctly, this should not occur on UDP
These calls return the number of bytes received, or -1 if an
error occurred. The return
value will be 0 when the peer has performed an orderly shutdown.
Anyway, the value of 0 appears not to be checked and is passed to
> But without a core file or other data, there is not much to post mortem
I understand and will of course give details should I ever get them.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3396 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.openswan.org/pipermail/users/attachments/20090503/7ed8f587/attachment.bin
More information about the Users