4 ms·
> Take for instance malloc. It can return NULL but you don't check for it, because that's just the way it's done. malloc is worth null-checking, if only to ass
by MaulingMonkey 6y ago
> Take for instance malloc. It can return NULL but you don't check for it, because that's just the way it's done.
malloc is worth null-checking, if only to assert/panic/breakpoint/fatal early and cleanly.
Even on linux with overcommit, it'll return null on memory space exhaustion, which can easily happen even in a 64-bit processes if someone feeds your program maliciously crafted data with an oddball size. A crash dump at the point of allocation failure, when the sizes are still on the call stack / in registers, instead of minutes later - when the pointer is actually used - is also a vastly better debugging experience when fuzzing for such bugs.
If malicious data can control offsets into the (null) pointer, an allocation failure can turn into an exploitable buffer overflow (just make the offset large enough), even if the offset is bounds-checked against the "expected" (even larger) allocation size.
- im3w1l 6y agoThat's a very interesting idea for exploitation, I bet a lot of things are vulnerable to that. But anyway I doubt that people do it even though they should.
- MaulingMonkey 6y ago> But anyway I doubt that people do it even though they should. A lot of codebases certainly skip such checks. But it's also fairly common to at least have a wrapper function that mallocs + triggers a fatal error if it returned null - and then to use that wrapper throughout the codebase. Gamedev tends to roll it's own allocators anyways, or need oddball system allocators for some resources, so they typically have a decent place to stick such checks already.