Использование после освобождения.

Use-After-Free (UAF) возникает, когда указатель продолжает ссылаться на объект после того, как free()/delete освободил память. Если атакующий добивается, чтобы та же область памяти была повторно выделена под другой объект — приём, называемый heap grooming или «heap feng shui», — висячий указатель фактически даёт ему type confusion, идеальную для перезаписи указателей виртуальных функций, адресов колбэков или важного состояния. UAF доминируют в эксплуатации браузеров и ядер и каталогизированы как CWE-416.

Известные случаи иллюстрируют последствия. CVE-2018-8174, UAF в движке VBScript, доступном через Internet Explorer, был превращён в оружие в составе zero-day «Double Kill» и включён в наборы эксплойтов. CVE-2022-0609, UAF в компоненте Animation браузера Chrome, эксплуатировался в реальных атаках как zero-day; группа Threat Analysis Group компании Google приписала эти кампании северокорейским государственным акторам, нацеленным на медиа- и финтех-компании. Распространённость подобных ошибок объясняет, почему и Microsoft, и Google сообщают, что около 70% их исторических CVE связаны с ошибками безопасности памяти, что подталкивает индустрию к переходу на Rust.

flowchart TD
  A[Объект выделен, указатель P ссылается на него] --> B["вызван free() / delete"]
  B --> C[P теперь висячий, память возвращена аллокатору]
  C --> D[Атакующий заполняет кучу, чтобы вернуть слот]
  D --> E[Та же память выделена под объект атакующего]
  E --> F[Программа разыменовывает P]
  F --> G[Type confusion -> перехват vtable и потока управления]

Защита включает дисциплинированные модели владения (RAII, smart pointers), языки со сборкой мусора или memory-safe, такие как Rust, усиленные аллокаторы (карантин, изолированные пулы, GWP-ASan) и тестирование с KASAN/Valgrind. Браузеры также применяют защиты типа MiraclePtr и PartitionAlloc.