Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

size_t-to-int vulnerability in Linux’s filesystem layer

openwall.com

Post reply on HN
Print view View original

101–110 of 280 posts

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#101

Post by rocqua »

aaronmdjones wrote: post #82
simias wrote: post #72

Earlier quoted context omitted.

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; }

-Wall -Wextra -Wpedantic does not enable all diagnostics. This is GNU's idea of "all". Contrast to Clang's -Weverything, which will.

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.

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#102

Post by eloff »

wizzwizz4 wrote: post #88
eloff wrote: post #78

Earlier quoted context omitted.

I would prefer not to see that happen, I'm fine with as and the safer options as they are currently. It would be a big job to update all the code in the wild when you want to move to the newer edition.

You don't need to do that. Rust editions are fully backwards-compatible, since they can depend on code from different editions.

I'm aware of that, which is why I specified when you want to move to the newer edition.

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#103

Post by chippiewill »

derefr wrote: post #32
cesarb wrote: post #7

This 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…

> are there any low-level/systems languages where a demoting cast with a generated runtime check gets the simple/clean syntax-sugared semantics (to encourage/favor its use), while truncating demotion requires a clumsier syntax (to discourage its use)?

Not exactly the same thing, but in a related area C++ does this a bit.

In C++ you can always still do a c-style cast `(int) some_var` (and the implicit casts obviously), but in general you're meant to use the C++ style explicit casts like `static_cast` and `const_cast`. These are generally tidy, but the most powerful and dangerous of these casts is deliberately awkwardly named as `reinterpret_cast(some_var)` rather than something terse.

It's always easy to spot during a code review.

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#104

Post by thayne »

dbrgn wrote: post #47
airocker wrote: post #9

Can 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 Or this: >> 2\*1024 Infinity JS doesn't even have integers. It only has floats. JS is by far the worst language I know of when it comes to integer support. If you want a better example of arbitrary precisio…

GP may have been referring to BigInt.

Although, C does have an equivalent to that: the GNU MP library (and probably others as well).

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#105

Post by chippiewill »

phkahler wrote: post #83
cesarb wrote: post #7

This 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…

This wouldn't be a problem if "int" was defined as the same size as size_t. The solution is probably to change all those functions to take a parameter of size_t instead of int. IMHO one should always be using C99 types instead of int, but Linux predates that. Also, shouldn't that implicit conversion cause a compiler warning?

> IMHO one should always be using C99 types instead of int, but Linux predates that.

"Always" is a strong way of putting it, there are often times where it makes sense to use the platform's "natural" word sizes (which is the entire point of having `int` `long` `long long` etc.)

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#108

Post by airocker »

infamouscow wrote: post #52
airocker wrote: post #9

Can we not have one integer type in c that can grow like in js as required and become bigint if too big?

We can do this in software because there's virtually no limit to the abstractions people make, but hardware doesn't work like that. At some point in the software stack we need to draw a line and say this is a 64-bit signed integer that hardware can understand.

But should it be everywhere including the fs/virtual fs layer? Could we limit it only to device drivers? Not a kernel expert here and would love to hear thoughts.

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#109

Post by airocker »

thayne wrote: post #104
dbrgn wrote: post #47

Earlier quoted context omitted.

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 Or this: >> 2\*1024 Infinity JS doesn't even have integers. It only has floats. JS is by far the worst language I know of when it comes to integer support. If you want a better example of arbitrary precisio…

GP may have been referring to BigInt. Although, C does have an equivalent to that: the GNU MP library (and probably others as well).

I was referring to bigint not js bigint, checking for overflows if optimized could be just 1 instruction.

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#110

Post by Already__Taken »

habibur wrote: post #107

> deep directory structure whose total path length exceeds 1GB [...] Oh, I didn't know Linux supports GB long path name. On Windows it's limited to something like MAX_PATH_LENGTH which was defined as 200+ chars when I worked on it.

Windows lifted that limit a few years ago
Post reply on HN