
So if I get this correctly, the kernel tries to read the memory after returning from the function without allocating/clearing/filling it first?
Got FreeBSD? Get busy on the patch, because a problem with its TCP ordering has emerged, with both denial-of-service and data leakage as possible effects. The issue exists in how the popular Unix-like operating system handles TCP packets received out-of-order. Packets are held in a reassembly queue until they can be re-ordered …
From reading the advisory text I would think it was this old C gem...
void foo (void)
{
struct packet hope_this_works = bar ();
add_to_list (&hope_this_works); /* Uh oh */
}
When foo returns, the stack space assigned for hope_this_works is no longer meaningful, and subsequent attempts to dereference the pointer stored by add_to_list will access junk.
Who came up with McAfee, Checkpoint Bluecoat and IronPort?
Whilst I don't know all the products from all the manufactures above, I've had hands on experience with a decent selection of there stuff:
From McAffe's product range, every thing that I have used so far is running a customised RHEL, and most of those are based on RHEL 6.
Current versions of Checkpoint firewall (R76 - R77) are using a horribly hacked up RHEL5.
IronPort, last time I used it was running a variant of RHEL4, though this was a fair time ago, so they could have changed.
Finally I've been told by people at Bluecoat that it is either a completely proprietary OS (marketing people...) or its a customised RHEL OS as well.