frr
frr copied to clipboard
Potential uncontrainted memeory allocation issue.
Hi, there I find code in here may has a potential uncontrolled memory allocation issue.
Here are details.

Label 1 (read msg but no limit to its length) -> Label 2 (obtain the msg's length) -> Label 3 (alloca memory according to the msg's length).
@rzalamena can you take a look here? It sure looks like later code does work to ensure we do not read past the end of the packet later in the code but I want you to double check.
The issue here is that we read a uint32 off the wire and then use it as an amount of memory to allocate without having a reasonable upper bound on it, which will simply terminate the program if it's too big (XMALLOC will assert, which also makes the code following the XMALLOC dead). Seems legit to me.
The issue here is that we read a uint32 off the wire and then use it as an amount of memory to allocate without having a reasonable upper bound on it, which will simply terminate the program if it's too big (
XMALLOCwill assert, which also makes the code following theXMALLOCdead). Seems legit to me.
I believe attackers can utilize this bug to crash remote servers running bfdd. so, hope the bug can be fixed asap
This bug is a little more serious than an assert - it's possible to manipulate plen such that the arithmetic for what buffer size to allocate (line 452) wraps, allocating a small buffer. Thank you @yiyuaner for pointing that out.
This issue is stale because it has been open 180 days with no activity. Comment or remove the autoclose label in order to avoid having this issue closed.
This issue will be automatically closed in the specified period unless there is further activity.