size_t-to-int vulnerability in Linux’s filesystem layer
1–10 of 280 posts
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#2> Unfortunately, this size_t is also passed to functions whose size argument is an int (a signed 32-bit integer), not a size_t.
Is this the type of things that could be caught by a linter or strict compilation rules? This seems to be to be a failure of the type system.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#3> Unfortunately, this size_t is also passed to functions whose size argument is an int (a signed 32-bit integer), not a size_t. Is this the type of things that could be caught by a linter or strict compilation rules? This seems to be to be a failure of the type system.
AFAIK most compilers by default will output a warning in this case.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#4Cached mirror - https://webcache.googleusercontent.com/search?q=cache:LwH96X...
I'm clueless about security: where does this fall on the scale of non-issue to critical? It strikes me as tending towards the latter, given that it enables unprivileged users to become root. Any insight into past Linux Kernel vulnerabilities that were severe?
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#5> Unfortunately, this size_t is also passed to functions whose size argument is an int (a signed 32-bit integer), not a size_t. Is this the type of things that could be caught by a linter or strict compilation rules? This seems to be to be a failure of the type system.
At this point, you can—and probably should—consider C and “C-with-analysers” two different languages. If you use static (and dynamic, if you have tests) code analysis, making software without these issues is way easier, and doing so without these tools is essentially impossible. Both because of the C language itself as well as because of the culture of “bytes go brrr” and “just use a debugger” that a lot of middle-level C programmers have in my experience.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#6I see in the mail that Red Hat sent out patches to resolve this. Are those patches already merged, or is this a CVE about a live exploit?
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#7This kind of issue is the reason why some more modern languages like Rust or Go do not have implicit narrowing conversions. For instance, on Rust, trying to simply pass an usize (Rust's equivalent of size_t) to a function which expects an i32 (Rust's equivalent of int) will not compile; the programmer has to write "size as i32" (Rust's equivalent of "(int) size"), which makes it explicit that it might truncate the value at that point.
(Some Rust developers argue that even "size as i32" should be avoided, and "size.try_into()" should be used instead, since it forces the programmer to treat an overflow explicitly at runtime, instead of silently wrapping.)
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#8I love the little nugget in the mitigations section. You can plug the hole for a normal filesystem, but then FUSE filesystems have an additional problem: "if an attacker FUSE-mounts a long directory (longer than 8MB), then systemd exhausts its stack, crashes, and therefore crashes the entire operating system (a kernel panic)."
If there's one place other than the kernel where truly defensive programming should be applied, it is systemd.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#9Can we not have one integer type in c that can grow like in js as required and become bigint if too big?
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#10Can we not have one integer type in c that can grow like in js as required and become bigint if too big?
We can. But it would be very inefficient. There's no point to use C at all, if you can accept that level of performance.