Talk:Buffer overflow/GA1

GA Review

Article (edit | visual edit | history) · Article talk (edit | history) · Watch

Reviewer: Maury Markowitz (talk · contribs) 21:34, 20 October 2016 (UTC)[reply]

Ok, here we go...

"Buffer overflows can be triggered by inputs that are designed to execute code" - this appears to be mixing two separate things. One is that buffer overflows can trigger code execution, and the other is that you may design a program to do that deliberately. Putting them both together in a single statement seems confusing.
"Bounds checking can prevent buffer overflows" - indeed, but it can also significantly effect performance. AFAIK this is the reason C++ did not add it, and I think that is important to mention even in the lede.
I really like the example section! My only concern here is the end, which seems WAY too inside baseball for this article?
"by overwriting a local variable that is near the buffer in memory on the stack to change the behavior of the program" - this does not parse... near...in...on...to change... Perhaps this can be rewritten?
"With a method called "trampolining"" - I would recommend re-writing this statement, it is very confusing to me in its current form. Particularity, "if the address of the user-supplied data is unknown, but the location is stored in a register" I can't seem to understand. Perhaps this can be (greatly) simplified?
"Stack-based buffer overflows are not to be confused with stack overflows." - why is this statement here?
"Also note that these vulnerabilities" - no! A fuzzer is worth mentioning, but that should definitely be in the Protective countermeasures, not just sort of floating about here.
"Barriers to exploitation" - this seems out of place too. It would seem this is a protective countermeasure too.
"NOP-sled" - is it NOP-sled or NOP slide? Suggest picking the later unless there's a good reason not to.

More later, gotta put the kid to bed. Maury Markowitz (talk) 23:56, 20 October 2016 (UTC)[reply]