CVE-2019-5736: runc container breakout

Posted Feb 12, 2019 19:34 UTC (Tue) by excors (subscriber, #95769)
In reply to: CVE-2019-5736: runc container breakout by sorokin
Parent article: CVE-2019-5736: runc container breakout

Reporting errors when out of memory seems difficult, unless you're extremely careful to implement the entire error-reporting path with no memory allocation at all (including in any third-party libraries you call into). More practical to just fail in a secure and obvious way (like abort() or (if you can expect the user to notice and debug/kill the process) loop forever).

to post comments

CVE-2019-5736: runc container breakout

Posted Feb 12, 2019 20:26 UTC (Tue) by sorokin (guest, #88478) [Link]

> Reporting errors when out of memory seems difficult, unless you're extremely careful to implement the entire error-reporting path with no memory allocation at all (including in any third-party libraries you call into).

I completely agree. It is understandably difficult to be 100% exception-safe. That is why under "report the error" I meant reporting in general. "fprintf(stderr, ...); abort();" fine. "errno = ENOMEM; return -1;" fine. "throw std::bad_alloc();" fine. I would say that any kind of error reporting is OK as far as no data is lost and the operation can be retried.

> if you can expect the user to notice and debug/kill the proces

That is what I think is not reasonable to expect. When some KDE application hung using 100% CPU time, the last idea that will come to my mind is that it lacks memory. Also most users don't know how to use gdb.