Earlier quoted context omitted.
> and the compiler doesn't even warn you that size is bigger than x That's not true tho, compiler with reasonable flags set will definitely warn you and if you really don't like this kind of code you can force compiler to issue an error instead
What flags you have in mind? Because this code doesn't generate any warning with GCC 11.1.0 with -Wall -Wextra: int main(void) { int some_int = 1234567; char c = some_int; return c; }
size_t-to-int vulnerability in Linux’s filesystem layer
171–180 of 280 posts
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#172This 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 va…
In Haskell I would use an exception, and mark the function as unsafe, but the stdlib seems to disagree with me here.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#173Earlier quoted context omitted.
What the hell is systemd doing that a 8MB long file path can exhaust its stack? Is it doing some recursive parsing or is it just doing something plain stupid like using a VLA to store user provided data?
Probably unbounded alloca() as always.
I also do never understand why some libraries use "faster" methods everywhere, unless safer ones. it's not like all interfaces to systemd would need to be fast. but they should be secure.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#174Earlier quoted context omitted.
The reason for this decision is so that compiler upgrades with -Wall and -Werror don't break builds. I can see the reason behind it, but I feel that this behavior is something you opt into when you use -Werror.
> The reason for this decision is so that compiler upgrades with -Wall and -Werror don't break builds. It feels like the "right thing" here would instead be for the compiler to allow build scripts to reference a specific point-in-time semantics for -Wall. For example, `-Wall=9.3.0` could be used to mean "all the error checks that GCC v9.3.0 knew how to run". Or better yet (for portability), a date, e.g. `-Wall=202107…
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#175Earlier quoted context omitted.
CPU would raise a signal just as null pointer exception? And it seems a lot of code (for eg, safeintadd metioned below) assumes no exception. Would not all that code get messed up? Would it be possible to just silently replace with arbitrary sized integer and not break any code like safeintadd?
CPUs don't raise exceptions, that is a software concept. CPUs do have traps, like for division by zero, but those are not exceptions in the way you think. Null pointers are also handled by the kernel, not the CPU. Its called a segmentation fault because you are trying to access a memory segment that the OS doesn't want you to.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#176Earlier quoted context omitted.
CPU would raise a signal just as null pointer exception? And it seems a lot of code (for eg, safeintadd metioned below) assumes no exception. Would not all that code get messed up? Would it be possible to just silently replace with arbitrary sized integer and not break any code like safeintadd?
In C, you can't "just" replace with arbitrary-sized integers. They are fundamentally different memory shapes. You may not be able to turn enforcement on for all code immediately. There's even the rare bits of code that depend on current overflow behavior. (Due to our human brains and the fact that we can easily name these bits of code, making the cognitively available, people often grotesquely overestimate the amount…
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#177Earlier quoted context omitted.
I wonder if just restarting PID1 could be viable alternative?
It's generally dangerous to restart PID1 in an enviroment where, by definition, something happened to PID1 that it wasn't expecting. The state of the system is now unreliable, and it's exactly the sort of unreliable in exactly the right place that tends to lead to whopping security issues. Far too easy to end up with "Crash PID1 with 'blah blah blah', then when it restarts it ends up doing bad things X & Y".
In a server I generally want a crash immediately. But on a desktop I'd rather it limp along and give me a chance to finish writing my Hackernews post.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#178Earlier quoted context omitted.
Swift checks all arithmetic by default: https://swift.godbolt.org/z/rW614G5aq It seems obvious that future Apple CPUs will have hardware support for this, if they don't already.
I don’t see this happening unless it makes it into the ARM ISA.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#179Earlier quoted context omitted.
I don’t see this happening unless it makes it into the ARM ISA.
I don’t know the terms of Apple’s license with ARM, do you? I’m quite interested. Given that Apple was one of the original founders of ARM it’s quite possible that their license allows much more latitude anyone else’s.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#180Earlier quoted context omitted.
I don’t see this happening unless it makes it into the ARM ISA.
I'm not familiar with ARM ISA, but from the godbolt disassembly, it doesn't look like anything special going on here - just the ASM being generated. What's happening here is it just does the add, jumps on overflow flag set to an invalid opcode...