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

111–120 of 280 posts

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

#111

Post by pcwalton »

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?

> This wouldn't be a problem if "int" was defined as the same size as size_t.

ILP64 causes a lot of problems, most notably needlessly-increased memory usage and, in C, the inconvenience of requesting a 32-bit type when int is 64-bit. It's rather uncommon to actually need the extra 64-bit range except when describing pointer addresses and memory/disk sizes, both of which benefit from an explicit intptr_t/size_t type for readability if nothing else.

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

#112

Post by formerly_proven »

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 goes to 260 chars, but the underlying system supports something like 64K, which means you can have files on Windows which are largely untouchable by built-in tools (Windows Explorer, file dialogs etc.)

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

#113

Post by cannabis_sam »

I’m still amazed that we allow compilation of so obviously faulty programs.

It’s like you sent a 1kg package through the postal service, and then the recipient gets an envelope containing a piece of cardboard from the original packaging.. And everyone involved is somehow A-OK with all of this.

If your programming language silently converts between types (in any direction), just to accommodate the programmer, instead of them specifying what they actually want to compute, you simply have failed as a programming language designer.

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

#114

Post by paavohtl »

Already__Taken wrote: post #110
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

AFAIK the limit has been lifted since Windows NT (so since the 90s), but only if you use the obscure NT path prefix (\\?\).

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

#115

Post by divingdragon »

Already__Taken wrote: post #110
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

IIRC you still need to use a special flag to enable it, right?

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

#116

Post by anyfoo »

greesil wrote: post #35

https://org.cs.pub.ro/dragos.tarcatu/llvmlinux/commit/058504... m->size must be of type size_t. It's slightly mind-blowing to me that casting to a smaller unsigned int can cause a vulnerability. But I guess unintended behavior (not undefined) can do that.

It's very common. All that needs to happen, as just one example, is the variable of the smaller type being used as an index into an array. You might get an out of bounds access, or even just an access to the wrong element.

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

#117

Post by mgraczyk »

eloff wrote: post #85
ridiculous_fish wrote: post #36

Earlier quoted context omitted.

into() does not work from size. It's rather frustrating in practice. https://stackoverflow.com/questions/62832438/why-is-rusts-us...

Yeah, that is frustrating since there are no platforms where that would fail today, and it's hard to imagine why we would ever want one with 256bit pointers. We don't even use full 64bit pointers today on x64.

The Ethereum virtual machine addresses it's storage with 256 bits, so there's one wild example. Although in this case you'd probably not want to use usize directly to represent storage.

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

#118

Post by jerf »

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 don't need arbitrary-sized integers; we need exceptions on overflow (or underflow, but I'll stick to overflow for the rest of this post) to be the default, or similar language features as appropriate.

I for one am tired of the chicken & egg issue of "CPUs don't support efficient overflow checking because nobody uses it, so it's slow" and "Overflow checking is slow because the CPU doesn't support it, so nobody uses it". For all the other good security work done in both software and hardware, much for things far more complex than this, this seems like an absolutely batshit insane oversight considering the cost/benefits for fixing this.

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

#119

Post by dragonwriter »

Already__Taken wrote: post #110
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

> Windows lifted that limit a few years ago

IIRC, its a mess because it was lifted inconsistently for different access methods (APIs, and as a consequence UI/CLI methods that depend on them), and at least for some in ways which also are or were dependent on how paths are expressed.

So it is, or at least has historically been after it was first “lifted”, a minefield of inconsistent, surprising behaviors with plenty of gotchas if you didn’t treat it as if it were still a limit.

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

#120

Post by andyjohnson0 »

cannabis_sam wrote: post #113

I’m still amazed that we allow compilation of so obviously faulty programs. It’s like you sent a 1kg package through the postal service, and then the recipient gets an envelope containing a piece of cardboard from the original packaging.. And everyone involved is somehow A-OK with all of this. If your programming language silently converts between types (in any direction), just to accommodate the programmer, instead…

> you simply have failed as a programming language designer

That's some hubris. The C language is 49 years old. Dennis Ritchie made reasonable design decisions for the time he found himself in. I think we should be understanding of that, and the network effects that lead to large parts of the world's critical software infrastructure being implemented in C. I don't think he failed at anything.

I used to be a C developer. I know how easy it is shoot your foot off in C. I think that, arguably, as an industry we should think twice before building more big and/or critical systems in C. There are better tools now.

But we are where we are and it's important to understand how we got here. Castigating our predecessors as failures does them a disservice.

Post reply on HN