Коротко — потому что по стандарту C после free(p) указатель p становится «висячим» (dangling), а любая операция доступа через висячий указатель (чтение или запись) даёт неопределённое поведение (undefined behavior, UB). Стандарт не описывает, что должно произойти, поэтому всё, что угодно, допустимо.

Почему это UB (интуитивно)

free освобождает область памяти и возвращает её системе/аллокатору. Содержимое памяти перестаёт быть «вашим» — аллокатор может пометить её как свободную, перезаписать, вернуть другому запросу malloc и т. д.Стандарт говорит, что доступ к памяти после освобождения — UB; компилятор и транслятор могут оптимизировать код, опираясь на это предположение (например, убрать код, считая, что такого доступа не будет).Следствие: чтение *p после free(p) формально не имеет смысла — компилятор и рантайм могут вести себя непредсказуемо.

Какие ошибки можно получить на практике

Ничего не произойдет (вы прочитаете старое значение — «кажется, всё ок»). Это вводит ложное чувство безопасности.Сегфолт / аварийное завершение (SIGSEGV) — если аллокатор вернул адрес пустой/неотображённой памяти или память была unmapped.Чтение / запись «чужих» данных — если аллокатор выделил ту же область другому объекту, вы можете повредить другие структуры (коррупция памяти).Нелокализуемые ошибки: зависания, случайные сбои в других частях программы.Вмешательство компилятора: оптимизации могут «переместить» или убрать нагрузки/записи, что делает поведение ещё более непредсказуемым.Уязвимости безопасности: use-after-free часто эксплуатируется для выполнения произвольного кода, обхода ASLR, раскрытия данных (info leak) и т. п.В многопоточных приложениях — гонки между free и использованием, приводящие к тонким багам и эксплойтам.

Как обнаружить use-after-free
Динамические инструменты

AddressSanitizer (ASan): флаг компиляции -fsanitize=address (gcc/clang). Очень эффективен для heap-use-after-free, быстрый и удобный для тестов/CI.Valgrind (memcheck): медленнее, но очень точен для поиска чтений/записей в освобождённую/неинициализированную память.UndefinedBehaviorSanitizer (UBSan): не ловит UAF напрямую, но полезен для других UB.MemorySanitizer (MSan): для неинициализированной памяти.ThreadSanitizer (TSan): для гонок, которые часто вызывают UAF в многопоточной среде.platform-specific: macOS GuardMalloc, Windows Application Verifier / PageHeap.

Статический анализ

Clang Static Analyzer, clang-tidy, cppcheck, PVS-Studio, Coverity — находят паттерны «free» + дальнейшее использование, утечки, некорректный контроль владения.Анализ кода (code review) с фокусом на владение/жизненный цикл объектов.

Тестирование и фуззинг

Fuzzинг (libFuzzer, AFL) в связке с ASan/UBSan часто выявляет UAF.Regression/Unit tests с sanitizers включёнными в CI.

Как предотвращать use-after-free в больших проектах
Горизонтальный (процессный) подход — сочетать политику, инструменты и практики:

1) Модель владения и конвенции

Ясно определите правила владения (кто владеет, кто за что отвечает). Документируйте их и проверяйте на ревью.Минимизируйте число мест, где выделяется и освобождается память — обёртки/фабрики/менеджеры памяти облегчают контроль.Для C++ используйте RAII и стандартные умные указатели:
unique_ptr для единоличного владения,shared_ptr + weak_ptr для совместного владения с возможностью «слабых» ссылок.Пример: вместо malloc/free — std::unique_ptr p = std::make_unique(42).Для C вводите явные «владельцы» (структуры, которые освобождают память) и используйте функции для доступа, а не свободные указатели.

2) Явное отключение висячих указателей

После free(p) устанавливайте p = NULL; это помогает обнаружить простые случаи (NULL-доступы легко отлавливаются), но не защищает от гонок в многопоточном коде и не гарантирует безопасность, если копии указателя где-то ещё.Лучше — минимизировать распространение «сырых» указателей.

3) Инструменты на этапе сборки и в CI

Включайте sanitizers (ASan, TSan) в отладочные/тестовые сборки и выполняйте весь тестовый набор в CI (unit + интеграционные тесты).Периодически прогоняйте Valgrind для критичных компонентов (хотя это медленно).Включайте статический анализ в пайплайн и фиксируйте предупреждения как blocker.

4) Отладочные/рантайм меры

Используйте жёсткий отладочный аллокатор (quarantine, redzones): т.н. «delay free»: аллокатор не сразу возвращает блок в систему, усложняя повторное использование памяти и повышая шанс поймать UAF.Включайте настройки аллокатора (jemalloc, tcmalloc) с детектированием ошибок, или используйте debug-коррекции malloc (например, glibc MALLOCPERTURB).В продакшн-сборках можно применить hardened allocators, guard pages или детекторы использования после free (падение производительности вероятно).

5) Многопоточность — разработать безопасные схемы освобождения

Если один поток может освободить память, а другой — использовать, нужна синхронизация.Используйте механизмы безопасного управления жизненным циклом:
reference counting (atomic reference counters),shared_ptr в C++ (atomic внутри),weak_ptr для наблюдателей,Hazard pointers, epoch-based reclamation (обёртки, библиотеки) для lock-free структур.Тщательно проектируйте API так, чтобы пользователь не мог случайно освободить объект, пока он используется.

6) Архитектурные и процедурные меры

Ограничьте использование malloc/free к минимуму; предпочитайте контейнеры/строки/умные указатели.Код-ревью и правила (например, запрет на «сырые» указатели в публичных интерфейсах).Документируйте ответственность за освобождение в API.Обучение команды: показать примеры ошибок и как их избежать.

Примеры практик и команд

Компиляция с ASan (gcc/clang): gcc -fsanitize=address -g -O1 your.c -o yourЗапуск Valgrind: valgrind --leak-check=full ./yourДля фуззинга: libFuzzer + ASan для быстрого обнаружения UAF.

Заключение — чеклист для проекта

Ввести и документировать модель владения.Сменить сырой malloc/free на RAII/умные указатели или ограниченные аллокаторы.Включить ASan/TSan в CI и запускать тесты с ними.Регулярно запускать статический анализ и фуззинг.В многопоточных местах применять надёжную синхронизацию/механизмы безопасной рекламации.Научить команду распознавать паттерны, ведущие к UAF.

Если хотите, могу:

показать пример безопасной замены вашего фрагмента на C++ с unique_ptr;дать набор команд для интеграции ASan в CI (пример .gitlab-ci.yml / GitHub Actions);помочь сформулировать правила владения для вашего кода (нужны детали проекта).