Nepřipadá mi že by v tom OpenSSL bylo úplně nevinně, když se nechá přesvědčit k tomu aby zbytečně alokovalo až 131 KB RAM na základě přijetí o několik řádů menšího objemu nedůvěryhodných dat. Kombinace s následným memory managementem glibc to ještě zhoršuje, ale to je zase vina OpenSSL že v tomto případě tento memory management glibc využívá místo aby použili něco lepšího.
Zřejmě máte pravdu. Z pohledu webové služby a jak se bránit Slowloris je chybou alokovat tolik paměti dopředu i když se neví že těch dat opravdu tolik dorazí (viz. oprava v podobě přírustkové alokace bufferu #30792, #30793 a #30794). Z pohledu čistě vývojářského by to neměl být problém - jakou paměť od OS dostanu tu také vrátím. Nebo snad ne? No sám jsem byl překvapen, že v případě glibc se vracená paměť vždy nemusí vrátit OS - tedy po dobu co běží proces. Popis chování glibc, jak je možné toto chování ovlivnit a případně zvolit jiný alokátor rozepisuje dobře na svém Linkedin profilu jistý Anmol TYAGI: https://www.linkedin.com/posts/anmol-tyagi-4994a612b_why-your-free-doesnt-free-memory-the-activity-7314282452087119873--Q9b.