> На первый взгляд обе уязвимости относятся к race condition. Чтобы
> такое выловить надо найти код, выполнение которого зависит от данных, которые
> можно изменить кодом в другом потоке. То есть надо построить некую
> карту покрытия кода и данных разными потоками и найти, где они
> пересекаются, когда работают параллельно.

Я (также будучи дилетантом) мыслю в том же направлении: построить модель, определить "проблемные места" и попытаться с ними "что-то сделать", применяя различные формы обратной связи в поиске вариантов решений, оценке результатов и для уточнения модели. Беда в том, что, в частности, проблема взаимодействия через семафоры (блокировки по коду и данным) более чем трёх процессов является математически неразрешимой. Поэтому результаты любого моделирования ситуаций гонки с количеством процессов больше двух в принципе будут неполны и не дадут никаких строгих гарантий для защищающейся стороны, но при этом в принципе способны полностью удовлетворять нужды атакующей стороны: выявлять некоторое количество подходящих уязвимостей, поддающихся эксплуатации.

> Grsecurity уже пытается строить карту допустимых
> вызовов в рамках RAP-а, может её можно расширить и на race
> conditions?

Положительный ответ на этот вопрос был бы слишком большим обобщением, практически лишённым содержания. Но саму парадигму моделирования - да, можно и нужно применить.