Hacker News new | past | comments | ask | show | jobs | submit login

Isn't it in practice a "this code wouldn't exist in the first place" situation? (I mean in context of Rust and many others) Either you'd have to go into unsafe{} block, of the buffer would simply be a Vec<>, which oom()'s on allocation issue.

I mean theoretically the issue still exists, because you can run allocation yourself and get back null. But without unsafe this shouldn't be possible.




Rust-the-language does not understand allocation, so it depends on the API that you give to whichever allocation functions.

Rust's standard library aborts on OOM.


That's what I meant - if you go through actual allocators, then of course such bug can exist. As you say <<the needed feature to mitigate this specific vulnerability is "throws exception on malloc failure">>. But it seems to me like any language providing resizable buffers with bound checking in standard library is unlikely to get code like this in the first place. And that's a massive scope reduction.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: