Cool idea, BUT nobody uses SCTP (packet based). UDP is not reliable (most applications dislike this), and TCP does not have "messages" actually requiring you to send length in some form...sort of like these guys did...
back
1 comments
Unless you have a fixed sized header which includes the size.
That's all that is needed to avoid people having to pull up a debugger to figure out why things are going bad in production.
> Unless you have a fixed sized header which includes the size.
Isn't that actually part the problem here? It's getting an erroneous size and trying to allocate a big buffer so it can read the data even though the data isn't really that big.
One solution might be a fixed header size, and a header checksum. Allocate space for the header, read what should be the header, including the checksum, and if the checksum is correct, then allocate the space requested for the data. A fixed size header doesn't really help unless you are actually checking that it's valid before proceeding.
The problem here was the memory leak, because it didn't free the enormous buffer in the failure path.
No, the original post was about a memory leak. This is really just a follow on about finding weird values popping up in protocols.
Also, even if we do constrain this to memory leaks, I would say that leaks just make the problem worse, and a real bad bug that causes a persistent DOS rather than just an ephemeral DOS, but it's still a problem without them.
Actually allocating the memory prior to confirming you need it is bad because if you get enough requests that do that quick enough, you eat up all the memory. If you aren't freeing the memory, you just don't have to be as quick. Considering that that crazy value in question here that is being passed to malloc represents over 1GB of memory, it wouldn't take that many requests at all.