Can we not have one integer type in c that can grow like in js as required and become bigint if too big?
>that can grow like in js
I thought js "integers" are just floating point numbers?
size_t-to-int vulnerability in Linux’s filesystem layer
41–50 of 280 posts
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#42Afaik this should work on Android for some time now too right?
Got unrootable old (but still fully working) phone there, might try to play with it.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#43This 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…
C/C++ compilers commonly have warnings for narrowing conversions, and separate warnings for mixing signed/unsigned conversions for same-sized values.
While some folks aren't too fussed about warnings like this, those folks generally aren't writing secure code like kernels. I'm very surprised that kind of conversion was permitted in the code.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#44Can we not have one integer type in c that can grow like in js as required and become bigint if too big?
Yes, arbitrary precision integers could theoretically become a C language/library feature. But let's say that it gets proposed and accepted and it's integrated into popular compiler toolchains. The kernel wouldn't leverage it here or likely anywhere else because of its cost.
A newly designed OS kernel could perhaps take on this kind of feature. This would be the kind of OS that could be formally verified and would be willing to pay that runtime cost for arbitrary precision.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#45Anyone knows how to try the PoC ( https://www.openwall.com/lists/oss-security/2021/07/20/1/1 ) ? For me it crashes into the fork_userns:177 PS: don't need to downvote. Sometimes managers want you to prove that there's a need to patch. It's dumb but it's what it is
Your linux distro may already have unprivileged user namespaces disabled. See the "mitigations" section of the post, and check /proc/sys/kernel/unprivileged_userns_clone
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#46This 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…
> 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. It's important to still have the option for efficient truncating semantics, though; some software (e.g. emulators) needs to chunk large integers into 2/4/8 smaller ones, and rotation + truncating a…
It would be nice if CPU's had an instruction for "read the low 8 bits of this register, and require the high bits all be zeros (otherwise throw an exception)".
Then safety is free...
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#47Can we not have one integer type in c that can grow like in js as required and become bigint if too big?
Haha, yeah JS integers "can grow". Kind of. And then they bite you in the worst way possible. Especially when combined with cryptography (e.g. nonces).
Try this:
>> const x = 288230376151711740;
>> x == x + 1
true
>> 2\*1024
Infinity
If you want a better example of arbitrary precision integers, try Python, for example.
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#48Can we not have one integer type in c that can grow like in js as required and become bigint if too big?
>that can grow like in js I thought js "integers" are just floating point numbers?
I believe the poster you were replying to was talking about JS's new `BigInt` type.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#49This 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…
I wish clippy had a lint against downcasts specifically. I aso like that rust has no “int” type
Re: size_t-to-int vulnerability in Linux’s filesystem layer
#50> 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.
GCC and Clang (the predominant Linux and Mac compilers) mostly don’t warn by default, you need -Wall or other flags (-Wextra, -Weverything, or specific flags like -Wconversion).