I 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?
Still not fixed in the mainline kernel, it seems.
It's fixed in 5.13.4.
size_t-to-int vulnerability in Linux’s filesystem layer
21–30 of 280 posts
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#22> 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.
Too bad that most projects are so full of integer size and signedness warnings that people get warning fatigue and just completely ignore them.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#23I've always thought implicit parameter conversion in general (narrowing or otherwise) was fraught at worst, and code smell at best. If some function takes a size_t, why are you passing something other than a size_t to it? If your eventual call into "code you don't control" takes type X, make sure the value that you eventually pass is type X all the way through the code you do control. Even casting is kind of the lazy way out. I used to be pretty dogmatic about this and more than a few times got called a pedantic nitpicker (size_t is just like an int, bro! Don't worry about it--we got to ship in a week!). You can probably find serious bugs in any C or C++ software project simply by turning on the implicit cast warnings.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#24This 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…
That's cool! And some languages like Go don't even allow implicit widening conversions: https://play.golang.org/p/a5C5jsHypmu
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#25Can we not have one integer type in c that can grow like in js as required and become bigint if too big?
No, because that would require implicit dynamic allocation, which would defeat the entire point of using C.
Only when limits are getting breached, otherwise it is one if statement extra on every access. This happens in Java and other languages.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#26This 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…
That's cool! And some languages like Go don't even allow implicit widening conversions: https://play.golang.org/p/a5C5jsHypmu
Rust doesn't allow them either: https://play.rust-lang.org/?version=stable&mode=debug&editio...
Adding .into() works though, which is the recommended method if the conversion can be statically guaranteed (otherwise try_into should be used, which will become easier in the 2021 edition as the TryInto trait will become part of the prelude).
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#27Earlier quoted context omitted.
I don't see any warnings for this narrowing parameter conversion. #include "stddef.h" short foo(short a) { return a % 42; } size_t bar(void) { size_t sz = ~0UL; return foo(sz); } https://godbolt.org/z/3ec9v8Pa4
It warns if you add -Wconversion. Unfortunately, that flag generates lots of false positives (at least in gcc), so using it isn't always a good idea.
It isn't ever a good idea. C programmers are just supposed to know about the conversion and promotion rules, every time they add a line, even though the rules are actually insanely complicated. Compiler warnings can't overcome this because programmers have no way of just discovering one of GCC's 726 warning flags, only a few of which are enabled by -Wall and -Wextra, most of which are way too noisy to serve a useful purpose.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#28Earlier quoted context omitted.
No, because that would require implicit dynamic allocation, which would defeat the entire point of using C.
Only when limits are getting breached, otherwise it is one if statement extra on every access. This happens in Java and other languages.
It doesn’t matter if it only happens occasionally. It’s completely inappropriate for C, which has no implicit memory allocation. There’s not even a clear way to include implicit allocation in the semantics of C.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#29Earlier quoted context omitted.
AFAIK most compilers by default will output a warning in this case.
I don't see any warnings for this narrowing parameter conversion. #include "stddef.h" short foo(short a) { return a % 42; } size_t bar(void) { size_t sz = ~0UL; return foo(sz); } https://godbolt.org/z/3ec9v8Pa4
On MSVC, default project settings I get:
warning C4267: 'argument': conversion from 'size_t' to 'short', possible loss of data
I saw these warnings so often that I assumed that every compiler had them.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#30Cached 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?
Pulling this attack off requires enough access to the machine to either run the unprivileged commands needed to create the exploit condition or to upload a binary/script that runs unprivileged that in turn creates the exploit condition.
If the attacker already has that level of unauthorized access, you're already doomed.