The vulnerability could allow remote code execution if an attacker sends a continuous flow of specially crafted UDP packets to a closed port on a target system.
So while a huge amount of UDP packets with all bits set to zero may result in a crash, it is unlikely that it will result in code execution. They need to contain content specifically written to exploit the issue.
It is an reference counter overflow according to the same Microsoft source.
What is a reference counter?
When a program allocates a block of memory, a reference counter may be used to manage it. Whenever a part of the program code wants to access it, the counter is incremented. Whenever this part of code is done working with the memory block, the counter is decremented. When the counter reaches 0, nobody is interested in the memory block any more, and it is freed.
What is an integer overflow?
Integers are numbers used for counting. They have a fixed size in computer memory. For example 32 bit or 64 bit. So unlike integers, you know from mathematics, there is a largest possible number. Adding 1 to that number will either result in a very negative number or 0.
In other words, if you add 1 again and again, you will end up with 0.
What is a reference counter vulnerability?
A reference counter vulnerability is usually caused by a program path that fails to decrement the reference counter. The attacker is therefore able to increment the counter again and again.
As a result, he can get the counter to 0 and beyond (see previous section). After he got the counter to overflow and ended up at 1 again, he will trigger the normal program path that will decrement the counter.
Now the counter reached 0. 0 means, nobody is interested in the memory block anymore, so it will be freed.
What is the error path in this context?
The program path that fails to decrement the counter is used when there is no service listening on the UDP port.
It is easy to conclude that an open UDP port is required for the final decrement to exploit the issue. Microsoft, however, did not mention this. Furthermore they stated that the Windows Firewall offers no protection against this bug. Therefore the conclusion is likely wrong.
Why is freeing used memory blocks a bad thing?
Freeing memory just means that it is marked as "available". Someone else, who requests a block of memory, may therefore get it. But the original program still thinks, it owns the block and can use it as it wants.
So we end up with two programs using the same memory block without being aware of each other. This obviously leads to data inconsistencies.
With a bit of bad luck and special crafting, one of this programs may do bad things to the other. Imagine that the other program is storing program code, pointers to program code, or trusted data that will result in pointers to program code in this memory block.
Is this a real risk?
Yes. It is not easy to exploit and sending a such a huge amount of UDP packets over a slow Internet connection will likely be noted. But it is real issue that needs to be patched.