Здесь логическая ошибка могла бы остаться логической, без privilege escalation.

Если б они взяли итератор поверх argv, отгрызли бы и выкинули несуществующий нулевой элемент от него (что есть логическая ошибка, наверное?), то затем они столкнулись бы с тем, что итератор дальше не идёт, и программа бы пришла к выводу, что ей не передали необходимого аргумента и завершилась бы с ошибкой. То есть, это в некотором смысле, даже если бы это и можно было бы назвать логической ошибкой, то она была бы нивелирована, и программа работала бы корректно, хоть может и странные сообщения об ошибках выдавала бы.

Но тут всё настолько запутано, итератор или принудительные проверки на выход индекса за границы массива -- это лишь один из распространённых способов, который помог бы.

Есть и другие -- скажем мозги покоцанные функциональным программированием испытывали бы неловкость от идеи модифицировать argv переданный туда извне. Тем более, что разве кто-то даёт гарантий, что argv и envp будут находится в непересекающихся областях памяти? По-моему, нет. Просто так всегда получается, но нигде такого не написано, то есть это недокументированное свойство их. А если это недокументированное свойство, то значит не документированы те изменения, которые произойдут при изменении argv. У тебя может поменяться envp заодно.

И возможно функциональным программированием покоцанные мозги решили бы, что лучше создать модифицированную копию, а избавление от "ненужного" копирования занести в список возможных оптимизаций, которые будут проведены тогда, когда профайлер покажет что они нужны. Профайлер бы показал, что они не нужны, и при таком подходе новые копии argv и envp не пересекались бы гарантированно, даже несмотря на выход за границу массива в переданном в main argv. И модификации argv не заносили бы ничего плохого в envp. То есть, с этой точки зрения, причина этой дыры находится в "корне всех проблем": в преждевременной оптимизации.

Или, допустим, в OpenBSD решили другую проблему -- там execve возвращает ошибку, если переданный ему argv=={NULL}. ad hoc решение, которое решает очень узкий класс потециальных проблем, но тем не менее сия дыра на OpenBSD -- не дыра вовсе.