Исследователи безопасности из компании Cisco раскрыли детали уязвимости (CVE-2020-6096) в реализации предоставляемой в Glibc функции memcpy() для 32-разрядной платформы ARMv7. Проблема вызвана некорректной обработкой отрицательных значений параметра, определяющего размер копируемой области. Вызов memcpy() на системах ARMv7 с отрицательным  размером приводит к некорректному сравнению значений и записи в области вне границ указанного буфера из-за использования ассемблерных оптимизаций, манипулирующих знаковыми 32-разрядными целыми числами...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53003

• Критическая уязвимость в реализации функции memcpy для ARMv7...,Ordu, 10:33 , 22-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,CAE, 12:20 , 22-Май-20
    • Критическая уязвимость в реализации функции memcpy для ARMv7...,смузихлеб вейпер тимлид, 12:41 , 22-Май-20
    • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 05:13 , 24-Май-20
    • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 01:49 , 25-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 13:54 , 22-Май-20
    • Критическая уязвимость в реализации функции memcpy для ARMv7...,Ordu, 14:29 , 22-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,PnD, 14:26 , 22-Май-20
    • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 09:37 , 23-Май-20
      • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 05:23 , 24-Май-20
    • Критическая уязвимость в реализации функции memcpy для ARMv7...,BSA, 15:33 , 23-Май-20
      • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 07:00 , 24-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,InuYasha, 17:12 , 23-Май-20
    • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 05:28 , 24-Май-20
      • Критическая уязвимость в реализации функции memcpy для ARMv7...,InuYasha, 11:11 , 24-Май-20
      • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 09:34 , 27-Май-20
• Уязвимость в реализации функции memcpy для ARMv7 из состава ...,native76, 23:29 , 21-Май-20
  • Уязвимость в реализации функции memcpy для ARMv7 из состава ...,BSDun, 23:38 , 21-Май-20
    • Уязвимость в реализации функции memcpy для ARMv7 из состава ...,Аноним, 00:21 , 22-Май-20
      • Уязвимость в реализации функции memcpy для ARMv7 из состава ...,Аноним, 00:57 , 22-Май-20
        • Уязвимость в реализации функции memcpy для ARMv7 из состава ...,sabretoothedhamster, 15:06 , 28-Май-20
    • Уязвимость в реализации функции memcpy для ARMv7 из состава ...,Аноним, 17:49 , 22-Май-20
    • Уязвимость в реализации функции memcpy для ARMv7 из состава ...,погроммист, 00:29 , 23-Май-20
  • Уязвимость в реализации функции memcpy для ARMv7 из состава ...,Ivan_83, 00:58 , 22-Май-20
    • Уязвимость в реализации функции memcpy для ARMv7 из состава ...,sfdsf, 08:58 , 22-Май-20
    • Уязвимость в реализации функции memcpy для ARMv7 из состава ...,Аноним, 09:23 , 22-Май-20
      • Уязвимость в реализации функции memcpy для ARMv7 из состава ...,Анон123, 14:07 , 22-Май-20
    • Уязвимость в реализации функции memcpy для ARMv7 из состава ...,пох., 11:51 , 22-Май-20
• Уязвимость в реализации функции memcpy для ARMv7 из состава ...,Аноним, 23:47 , 21-Май-20
  • Уязвимость в реализации функции memcpy для ARMv7 из состава ...,Аноним, 23:54 , 21-Май-20
  • Уязвимость в реализации функции memcpy для ARMv7 из состава ...,Sw00p aka Jerom, 23:55 , 21-Май-20
  • Уязвимость в реализации функции memcpy для ARMv7 из состава ...,Аноним, 10:11 , 22-Май-20
    • Уязвимость в реализации функции memcpy для ARMv7 из состава ...,териванов, 21:01 , 22-Май-20
• Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 23:53 , 21-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 23:56 , 21-Май-20
    • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 23:58 , 21-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,gogo, 00:30 , 22-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,vitalif, 00:43 , 22-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 00:57 , 22-Май-20
    • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 01:40 , 22-Май-20
      • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 09:36 , 22-Май-20
        • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 10:14 , 22-Май-20
        • Критическая уязвимость в реализации функции memcpy для ARMv7...,Школьник, 14:16 , 22-Май-20
        • Критическая уязвимость в реализации функции memcpy для ARMv7...,с, 15:30 , 22-Май-20
        • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 18:40 , 22-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,Anonn, 10:47 , 23-Май-20
• Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 03:42 , 22-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 08:24 , 22-Май-20
    • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 08:50 , 22-Май-20
      • Критическая уязвимость в реализации функции memcpy для ARMv7...,Жека Воробьев, 14:27 , 22-Май-20
        • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 05:31 , 24-Май-20
          • Критическая уязвимость в реализации функции memcpy для ARMv7...,cool29, 12:54 , 25-Май-20
• Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 06:21 , 22-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,Онаним, 08:21 , 22-Май-20
    • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 09:51 , 22-Май-20
    • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 09:51 , 22-Май-20
      • Критическая уязвимость в реализации функции memcpy для ARMv7...,Zenitur, 11:22 , 22-Май-20
        • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 18:46 , 22-Май-20
      • Критическая уязвимость в реализации функции memcpy для ARMv7...,Онаним, 11:45 , 22-Май-20
      • Критическая уязвимость в реализации функции memcpy для ARMv7...,Онаним, 11:53 , 22-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 18:42 , 22-Май-20
• Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 07:13 , 22-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,пох., 12:00 , 22-Май-20
    • Критическая уязвимость в реализации функции memcpy для ARMv7...,Lex, 08:11 , 23-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,iPony129412, 07:30 , 25-Май-20
• Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 08:55 , 22-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 10:12 , 22-Май-20
    • Критическая уязвимость в реализации функции memcpy для ARMv7...,Sw00p aka Jerom, 11:50 , 22-Май-20
    • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 18:49 , 22-Май-20
    • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 06:02 , 23-Май-20
      • Критическая уязвимость в реализации функции memcpy для ARMv7...,BSA, 15:39 , 23-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 05:54 , 23-Май-20
• Критическая уязвимость в реализации функции memcpy для ARMv7...,ЛениваяЖ, 09:05 , 22-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 11:26 , 22-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,пох., 12:02 , 22-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,BSA, 15:41 , 23-Май-20
• Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 11:17 , 22-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,vle, 23:52 , 26-Май-20
• Критическая уязвимость в реализации функции memcpy для ARMv7...,mos87, 18:36 , 22-Май-20
• Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 18:55 , 22-Май-20
• Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 20:56 , 23-Май-20
  • Критическая уязвимость в реализации функции memcpy для ARMv7...,Аноним, 00:39 , 24-Май-20

Наблюдаю в комментах непонимание, поэтому краткая справка для далёких от машинного представления чисел.

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

0 <=> 0
1 <=> 1
...
2^31-2 <=> 2^31-2
2^31-1 <=> 2^31-1
2^31 <=> -2^31
2^31+1 <=> -2^31+1
...
2^32-1 <=> -1

Для знакомых с группами вычетов Z/nZ: знаковые и беззнаковые -- это одна и та же факторизация множества целых чисел, но представители классов выбраны разные. Это как группу Z/3Z можно представлять как множество элементов {0, 1, 2}, а можно как {-1, 0, 1}.

(Кстати обратите внимание, если не сталкивались с этим раньше: abs(abs(x)) не всегда равен x. -2^31 -- это самое большое по модулю число, и оно одно, для него нет положительной пары. Бага системы кодирования чисел, которая иногда становится занозой в заднице).

При этом, что удачно, при таком подходе к кодированию целых, можно использовать одни и те же операции сложения/вычитания для работы как со знаковыми числами, так и с беззнаковыми. Но когда речь заходит об умножении, делении, сравнении чисел, на уровне машинных команд код начинает различаться, в зависимости от знаковости аргументов.

Обсуждаемый бажный memcpy работал с size как со знаковым числом. Для значений меньше чем 2^31 это работало как надо, потому что если такие беззнаковые числа интерпретировать как знаковые, то они по смыслу будут тем же самым. А вот для значений больше либо равных 2^31 уже не работало, потому что если их интерпретировать как знаковые, то получатся отрицательные числа.

И собственно эксплуатация бага свелась к тому, чтобы добиться передачи в memcpy буфера с размером в 2Gb или больше. То есть код, использующий memcpy может быть 100% безбажным, и тем не менее эксплоит будет возможен, при наличии такой бажной реализации memcpy.

Гм. Современное поколение программистов не знает что такое прямой, обратный и дополнительный код? :))

эй потише там

Программист - слишком громкое название для вебмакаки, там из образования книжка по пэхапэ прочитанная за неделю. И все, можно идти твАрить.

Ох уж эта русскоязычная терминология. Конечно, современные программисты ее не знают.
По-английски это называется ones’ complement.

> abs(abs(x)) не всегда равен x.

Вообще-то никогда не равен, если x - отрицательное.

А, простите, перепутал операцию. Да, имелось в виду -(-x).

Объяснил так объяснил. Для далёких. Попробую показать "на пальцах" для остальных.
Число внутри 32-разрядного процессора состоит из 32 записанных друг за другом "битов", содержащих либо "0" либо "1".
Т.о. привычный нам ноль — это 32 бита с "0" внутри процессора.
Дальше будем полагать что числа пишутся/читаются в привычном нам порядке, слева направо. Бывает и наоборот. С какого конца читать — указывают в названии архитектуры процессора (big|litle endian).

Единица в самом правом разряде "00000000000000000000000000000001" соответствует 2º (в степени 0), т.е. = 1. Следующие биты справа налево кодируют 2¹=2, 2²=4 и т.д.
Двоичное число "01000000000000000000000000000000" (единица в 31-м разряде) соответствует 2³º= 1073741824 (десятичное представление).

Чтобы записывать отрицательные числа, договорились использовать 32-й (самый левый) бит.
При этом число "10000000000000000000000000000000" = 2³¹ кодирует самое маленькое (для 32-разрядного процессора) число -2³¹. И оно уникально, т.к. соответствующее ему положительное число в 32 разряда не лезет (или надо знак убирать).

Остальные биты при этом обозначают сколько надо прибавить к -2³¹. То есть:
"10000000000000000000000000000001" = -2³¹ + 1 = -2147483647
"11111111111111111111111111111111" = -1 (прибавили всё кроме последней единицы)

В этом месте нетрудно заметить, что операция сложения чисел со знаком ничем не отличается от той же самой операции "без знака". Например, "-1 + 1":
"11111111111111111111111111111111" + "00000000000000000000000000000001" = "00000000000000000000000000000000".
* Разряды переполнились и обнулились. Не хуже чем на старых арифмометрах.

** В умных книжках такой способ представления отрицательных чисел называется "второе дополнение": в первом дополнении число "переворачивают": например из "1100" получается "0011". Во втором — добавляют 1 (получим "0100"). Но это выносит неокрепший моск и напрочь убивает понимание как с этим обращается процессор.

Даёшь троечную систему счисление!!!

Такая даже была на заре развития компьютеров, но популярности не снискала, только тогда уж "троичная".

"Второе дополнение"? Обычно, это называется просто "дополнительный код числа" и он именно от "дополнения единицей". Число не "переворачивают", а инвертируют: 0 заменяют на 1, а 1 на 0.
Ваше объяснение тоже не сильно лучше.  А местами просто вводит в заблуждение.

да он только вчера книжку прочитал, ещё не все термины запомнил, вероятно, имелось в виду "дополнение до двух"

С древних времён у меня вызывало недоумение: кто и зачем всякие memcpy() определяет в signed-типами?...
Ну и всякие int count, int size и т.п. Проверки на -1 - не оправдание - это симптом уже случившегося кабздеца.

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

Как максимум процессоры взводят флаг состояний. Но если после каждой операции проверять эти флаги - это перестанет быть си и станет чем-то типа яваскрипта по скоростью работы. Потому что 2/3 операций будут не тем что хотелось посчитать, а кучей проверок "а как посчиталось?!". Ну и кому будет надо всю алгоритмику на скорости 1/3 от того что сейчас есть, даже если это чуть безопаснее? Это ж заякорит в 3 раза вообще всю систему, на самых базовых уровнях. В бенчах будет швах и это даром никто не возьмет.

> Ну и кому будет надо всю алгоритмику на скорости 1/3 от того что
> сейчас есть, даже если это чуть безопаснее?

Всем. В debug-версии. И ещё горы ASSERT-ов и логов. Отладил - и можно в релиз, где проверок меньше. А в редко используемых функциях типа Init и Create я проверки вообще не вырубаю.

нужна аппаратная поддержка корректности
типа (условный ассемблер)
add Ax,Bx ; сложение когда переполнение не ошибка
add Ax,Bx ; сложение когда переполнение ошибка, выполняется процем параллельно и на производительность не влияет.

звучит страшновато

Хорошо звучит. Можно будет рутовать ARMv7 устройства, а затем обновлять глибси.

Всякую встроенку которая никогда не обновится теперь можно ломать.

Во всякой встроенке скорее всего будет другая libc.

Вот, кстати, да, про другие либы что-нибудь пишут (типа uClibc/ng)?

Welchia 2.0

Надо только сначала найти ARMv7 устройство с более чем 2гб памяти.

Если у тебя в memcpy() приходит контролируемое удалённым пользователем значение длинны и код его до этого никак не валидировал - то memcpy() не виновато что в него мусор заслали.
И вообще станно, у memcpy() для размера должен sixe_t использоваться, а он без знаковый.

Короче, если и найдётся софт в котором из за этого дырка - то там она будет явно не одна.

> станно, у memcpy() для размера должен sixe_t использоваться, а он без знаковый

Вы Чукчи Писатели уже раздражать начинаете. Черным по бежевому написано же:
>>в реализации для ARMv7 вместо size_t в добавленных для оптимизации ассемблерных вставках оно обрабатывается как signed integer

Во времена мамонтов были процессоры в которых беззнаковая арифметика была реализована, как то иначе чем у большинства. Из за этих героев весь мир должен страдать многие десятки лет.

То ли ещё было во времена грекоримлян...

> Если у тебя в memcpy() приходит контролируемое удалённым пользователем значение длинны

в memcpy, внезапно, частенько приходят данные пользователя - и длинна их контролируется, хотя и косвенно, пользователем. Сколько прислали (в пределах разумного, но это, например - адресное пространство целиком вполне может быть), столько и копируем.

> и код его до этого никак не валидировал

а зачем коду его валидировать? Код просто посчитал, сколько байтиков ему прислали. Правильно посчитал. А там ляп-ляп-ляп, забыли про unsigned.

> И вообще станно, у memcpy() для размера должен sixe_t использоваться, а он без знаковый.

к сожалению, ассемблер ничего не знает ни про какие size_t.

> Короче, если и найдётся софт в котором из за этого дырка - то там она будет явно не одна.

в glibc-то? Да кто б сомневался. Особенно на редких и немодных платформах.

Что-то непонятное на скриншоте. Вроде речь идёт о системе, основанной на GLibc, а запускают какой-то ехешник.

Что тут непонятно, запустили netcat на винде для атаки на внешний хост по сети.

на скриншоте показано подключение к сокету, который уже был открыт после экслоитинга.

Взлом системы с уже открытым портом, на котором уже висит рут-шелл с помощью вантузного нетката. Что непонятного? Это сиска... Там ещё питоновские файлы в некрософт-шояде редактируют и перфорс используют вместо гита. Сам видел. А ещё там заставляют людей использовать cisco-webex тех, кто не убедил начальство переползти на slack или skype, на худой уонец.

Кул стори, бро...

Стоит отметить, что и Android проблема тоже не затрагивает ввиду использования bionic вместо libc. Мало ли кто об этом не знает.

А какая связь bionic и glibc (GNU libc)? Это совершенно разные libc.

ой, прочитал "не затрагивает" как "затрагивает".

Не знает тот, кто не прочитал статью, а строчит комменты.

а жаль!

Потому что android единственный нормальный линукс, а все остальное - унылые неработающие поделки.

Не работающие… Ты или поехавший, либо мелкий траль. Как насчёт потоньше? Иди лучше бсдшников поразвлекай этим аргументом, или макосников. Вот у них проблемки, да.

Я еще понимаю критику windows и из пользователей.

Но, что вам сделали BSD и osx?
Это отличные ос, которые ничуть не хуже линукса.

И что вам сделали пользователи bsd и макоси, что вы их так ненавидите и ставите себя выше их?
У линуксоидов была какая-то травма в детстве, связанная с этим?
Верно говорят, что линуксоиды ставят свою ос на уровне бога и критикуют и ненавидят все, что не связано с ним.
Моральные уроды вы линуксоиды и больше никто.

Я могу ответить. Пользователи эскбсд достали своим хэйтом, а проблемы с запуском софта у них и правда есть. Пользоваться osx же откровенно больно. И где ты увидел критику?

Если вкратце, то каков поп, таков и приход.

> Верно говорят, что линуксоиды ставят свою ос на уровне бога

А как должно быть? за 42 года какие достижения? Линукс в 2 раза младше, а достижений гораздо больше.

> что вам сделали пользователи bsd

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

>Я еще понимаю критику windows и из пользователей.

А чем Макось и её пользователи лучше? Тоже закрытая хрень. И кому до того какое дело, что она официально сертифицирована на UNIX.

Ну вот, а Google винили в NIH-синдроме. Не даром они и boring ssl сделали, и много чего другого.

Совершенно непонятная новость. У memcpy аргумент имеет тип size_t как он в безанковый тип передали отрицательное число?

В коде использовались ассемблерные вставки с инструкциями для работы со знаковыми числами.

Нет там вставок, функция целиком на ассемблере написана.

а еще у математиков бывают пустые множества, прикинь какая боль

Боль - это пытаться объяснить вебмакаке как работает рид-соломон :)

Не МАКАКА А МИСТЕР ГОРИЛЛА! Понял, да!? А ты УДАВ УЗЛОВАТЫЙ!

Предупреждали - не делать в коде С ассемблерных системно зависимых вставок.

Увы, если в коде эмбедовки делать это не делать - она ворочаться будет как Windows 2000 на 80486-25.

Согласен. Сам таким баловался, когда по просьбе знакомых докторов вьвер для томографа написал в начале 90-х.

Не запустится. 80486 на 25 МГц — это SX, без сопроцессора, и более чем уверен, что специфические для Pentium инструкции были использованы. Плюс я не помню чипсетов для 80486, поддерживающих хотя бы 32 МБ ОЗУ (минимум для первых версий винтукея, на которых он только и может, что запуститься, где-то за полчаса).

Сопроцессоры для 486 SX выпускались отдельно. https://ru.wikipedia.org/wiki/Intel487SX

У меня на материнке с Am386DX-40 (1993 год) можно максимум установить 32 Мб ОЗУ, судя по документации. 8 30-pin SIMM-модулей по 4 Мб каждый. Но я не пробовал. На 486 и 72-pin SIMM не должно быть проблем

Ты на Avito покупаешь или продаёшь?

> минимум для первых версий винтукея, на которых он только и может, что запуститься, где-то за полчаса).

Вот!

> 80486 на 25 МГц — это SX

Am486 DX-25 был вполне себе с сопром. Более того, двухштучник сопра и P5 не требовал и за полчасика взлетал и на SX.

>Предупреждали - не делать в коде С ассемблерных системно зависимых вставок.

Кто и кого предупреждал?

"встроенный в автомобильные информационные системы http-сервер". блин, дайте мне другой глобус

В принципе, и этот глобус - достаточно большой, чтобы хватило на всех веб-макак.
Я думаю, даже 2x1.5 им жырно, можно просто сваливать в одну траншею.
Хотя, с другой стороны, чего матеръял-то зря переводить...

"За холмом открывалось огромное поле. В поле, точно по линеечке,
стояли рядами не то кресты, не то деревья, не то вязанки рогов. И перед
каждым из них виднелись могильные холмики."

Веб-макаками уже стали ассемблерные программисты под арм?)

А вообще, даже забавно наблюдать за настолько нелепыми ошибками у «системных_и_не_веб_программистов»

Было бы чего плохого...

В новости ошибка. ВСЯ ФУНКЦИЯ ЦЕЛИКОМ НА АССЕМБЛЕРЕ. Нет никаких "вставок". https://code.woboq.org/userspace/glibc/sysdeps/arm/memcpy.S....

Директивы препроцессора на С. (Хотя не знаю, можно ли препроцессор считать частью языка).

А, еще комментарии сишные есть!

Ага, с прототипом где явно указано size_t :)

Нельзя. Препроцессор о синтаксисе C не знает, он просто тупо подставляет. Поэтому не может давать адекватных сообщений о проблемах.

Во многих ассемблерах были макросы (TASM, MASM), но в линуксовом их нет и добавили препроцессор из С. Этот препроцессор для много чего может использоваться, можно вызывать его отдельно.

Есть там макросы .macro/.endm. Они позволяют создавать макросы, используемые как инструкции.

Три человека, что поставили минус. Всё теперь ясно о компетентности комментаторов в программировании.

Размер копируемой должен быть от 2 Гб, для того, чтобы получить отрицательное значение

2ГБ чтобы выйти на минус и ещё 2ГБ чтобы указатель сместить в конец первых 2ГБ. Следующие данные уже полезут за ожидаемый буфер.

и вот тебе жалко 2г нулей ради хорошего дела?!

Если послать через сжатый канал (например, http+gzip), то объемы будут значительно меньше.

Разработчики glibc в принципе не умеют в форматирование кода? Что там за каша?

Это "всеми любимый" gnu coding style ;-)

нестрашно, добрый вендор всегда оберегает тебя через TrustZone бггг

просто надо было писать на rush а параметры передавать через https+json

Какой идиот додумался для РАЗМЕРА использовать знаковое целочисленное?

Кто-то из POSIX. Глупые наверное, и конвенции сишные глупые выдумали. Совсем дурачки. Ты-то умный, вон сразу видно, надо было спросить у тебя.