Владимир Дубровин

Можно использовать:
1. Именованные семафоры - "из коробки" предназначены для вашей задачи
2. Неименованные семафоры + shared memory (на 1 и 2 есть примеры в https://stackoverflow.com/questions/8359322/how-to...)
3. Атомарные переменные в shared memory (пример в https://stackoverflow.com/questions/48614784/alloc...) + футекс (футексы есть в линукс, но использовать их можно только через системный вызов, если что-то не поменялось) - наиболее эффективный способ, т.к. системный вызов дергается только если требуется блокировка процесса, но плохо документирован, если интересен поищите реализации критической секции через футекс, вам надо примерно то же самое
4. мутексы в shared memory c PTHREAD_PROCESS_SHARED

1. В read наверняка надо передавать buf а не &buf (точно сказать нельзя т.к. описания нет)
2. В зависимости от того, как вы запускаете процесс, дочерний процесс может получить SIGHUP при закрытии родительского процесса или SIGPIPE на printf, стоит добавить обработчики сигналов до fork().

Первый аргумент функции printf() char * а не char. Кроме того, первый аргумент это форматный спецификатор. Т.е. правильное использование printf("%c", x).

Сделать с gap-буфером можно, информацию о позиции курсора храните отдельно при изменении позиции курсора меняете позицию gap, в общем-то оно на это и рассчитано.
Я не знаю, как принято реализовывать в реальных текстовых редакторах, я бы сделал структуру похожую на btree без ключа
https://ru.wikipedia.org/wiki/B-%D0%B4%D0%B5%D1%80...
в каждом узле хранить либо указатель на фрагмент текста + его длину либо признак конца абзаца/спецсимвола либо ссылку на другой узел. Каждый фрагмент и строку хранить отдельным узлом.
Фактически это возможность иметь неограниченное количество гапов в произвольных местах без необходимости их двигать. Как бонус, такая структура легко позволяет делать навигацию, undo/redo, т.к. каждая запись хранится отдельным узлом copy, paste и все остальное что обычно требуется. Поддержать форматированный текст так же очень легко, достаточно добавить признаки форматирования как еще один тип узла.

man signal

#include <signal.h>
void sigprocess (int sign){
 /* process signal here */
}

...
int main(){
...
 signal (SIGUSR1, sigprocess);
...
}

P.S. если обработчик не нужен, можно
signal(SIGUSR1, SIG_IGN);

Нет, вы поняли неправильно. Во-первых, эксплуатация переполнения буфера зависит от того, где расположен буфер. Скорей всего вы имеете ввиду переполнение стекового буфера aka stack overrun.
При "классической" прямой эксплуатации переполнения буфера в стеке "по aleph1" в буфере размещается шел-код, затем сохраненный в стеке адрес возврата перезаписывается адресом, указывающим внутрь буфера (на шелкод), при возврате из функции выполняется шелкод.

Однако, такие приемы работали до того, как появились технологии защиты стека, неисполняемой памяти и рандомизации размещения в адресном пространстве. Сейчас для эксплуатации переполнений стека на практике обычно требуются приемы ROP (return oriented programming), т.е. ваши знания очень сильно устарели.

Написать программу и вставить ее код в чистом виде нереально даже в случае классической эксплуатации, т.к. шел-код должен быть привязан к определенному состоянию адресного пространства эксплуатируемого приложения, и попадает в адресное пространство минуя стандартные механизмы загрузки и динамической линковки. Обычно шел-код пишется на ассемблере, либо под определенные фиксированные адреса, либо так, чтобы не иметь привязки к адресному пространству или с учетом необходимых дополнительных операций (например получения адресов вызываемых функций) для привязки к адресному пространству.

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