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

261–270 of 280 posts

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

#261

Post by CrazyPyroLinux »

saurik wrote: post #17
CrazyPyroLinux wrote: post #11

Earlier quoted context omitted.

systemd? More like systemK! But seriously, are non-systemd systems not vulnerable to the FUSE portion of this? (CVE-2021-33910)

FWIW, I feel like your comment is responding to an implicit critique of systemd, but even if one was warranted I didn't read that comment as implying such (as the premise would just be that systemd is a key place in the stack where you would need to be super careful, not that it is somehow less careful than other projects... even if I might claim as such for at least logging ;P); it could be that I am misinterpreting…

Yeah, I think you and a lot of other people misinterpreted my comment, since it was oddly one of my most-downvoted-ever.

My "systemK" joke was indeed implying what you said, that systemd is "a key place in the stack where you would need to be super careful." (Almost Kernel-like.)

And my question was legitimate, although poorly-researched. Answering myself: CVE-2021-33910 only affects systemd, not all FUSE in general.

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

#262

Post by SolarNet »

codedokode wrote: post #193
Zababa wrote: post #2

> 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.

Yes, this can be caught by a static analyzer and it is sad that Linux doesn't use it. I wonder, is it because the code quality is low and there would be too many warnings?

They do use them, but only in a narrow fashion. A lot of people have tried to make default kernel wide static analyzers but they are mostly not useful.

And it's because the kernel does a lot of non-standard things, mostly because it has to. It is not a normal program.

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

#263

Post by dezgeg »

pornel wrote: post #187
eloff wrote: post #85

Earlier quoted context omitted.

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.

Even worse, there are platforms with >=128-bit pointers but 64-bit address space. Rust has chosen usize to be uintptr_t rather than size_t, even though it mostly uses it as if it was size_t. A ton of code is going to subtly break when these two sizes ever differ. Rust is likely already doomed on >64-bit platforms, and is going to be forced to invent its own version of a LLP64 workaround.

"Fortunately" there will be bigger problems than Rust on 128-bit machines - lots of UAPI structures in the Linux kernel have pointer size hardcoded to 64 bits.

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

#264

Post by gaul »

Zababa wrote: post #2

> 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.

clang's -Wshorten-64-to-32 can catch this:

https://clang.llvm.org/docs/DiagnosticsReference.html#wshort...

The more general-purpose -Wconversion has many false positives, often around int to char conversion. Some functions like int toupper(int) have an unexpected int return type to deal with special out-of-bound values like EOF.

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

#265

Post by lazide »

BoorishBears wrote: post #256
lazide wrote: post #254

Earlier quoted context omitted.

If said beginning friendly IDE is used by only a couple percent of the ecosystem, it seems disingenuous to use it as proof this isn't a problem in this context?

Ok so we're going to keep shifting the goalposts, now it's "there aren't enough beginners relative to total usage so beginner friendly IDE isn't enough"... I mean MSVS uses Clang-tidy too, Clang-tidy integrates style guides provided by Mozilla and Google. Most C++ Google projects have clang-tidy configs. Clang-tidy is literally table-stakes for modern C++ tooling. Github shows 970,000 commits related to setting up cl…

I’m definitely not moving any goalposts I know of!

I thought the point I had been making, as had others, is that by default this is an easy footgun.

There are all sorts of things that can be added on to all languages to help - if you know it’s a problem worth solving, etc. which is inevitably after you’ve footgunned yourself with it bad enough you felt the need to research how to prevent it.

Other languages just do the safer thing (or most compilers By default warn at least about common footguns) more - which is the whole point of this thread?

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

#266

Post by account42 »

derefr wrote: post #251
wheybags wrote: post #174

Earlier quoted context omitted.

The real solution: leave Werror off by default, activate it only during CI builds

That's even worse, because then an upgrade to the compiler in the managed CI runner (e.g. Github Actions') base-image will translate to the same version of the code failing where it previously succeeded, with nobody sure why. At least with -Werror on at all times, devs will tend to upgrade before the very-stable CI environment does, and thereby catch the problem at development time (usually less time-pressure) rather…

> That's even worse, because then an upgrade to the compiler in the managed CI runner (e.g. Github Actions') base-image will translate to the same version of the code failing where it previously succeeded

If you don't want your build to fail on warnings, don't use -Werror. If you want it to only fail on specific warnings, use -Werror=...

> with nobody sure why

Unless they look at the errors in the compiler output. What does it matter if it was brought on by a compiler update or a push?

> At least with -Werror on at all times, devs will tend to upgrade before the very-stable CI environment does

Nothing wrong with -Werror for devs - the problem is when you ship code to others and leave -Werror on by default.

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

#267

Post by account42 »

GoblinSlayer wrote: post #245
rocqua wrote: post #101

Earlier 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.

Is -Werror really supposed to not break builds?

The whole point of -Werror is to break builds and -Wall / -Wextra are definitely not frozen. If you can't handle compiler updates resulting in errors, don't use -Werror in that environment.

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

#268

Post by account42 »

130e13a wrote: post #92
aaronmdjones wrote: post #82

Earlier quoted context omitted.

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

keep in mind though that -Weverything is not intended to be used in production: https://quuxplusone.github.io/blog/2018/12/06/dont-use-wever...

-Weverything is great for CI though, in compination with lots of -Wno-... flags to disable warnings you don't want. Instead of having to manually look out for new warning flags you will get all automatically.

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

#269

Post by account42 »

not2b wrote: post #184
gumby wrote: post #163

Earlier quoted context omitted.

> This is GNU's idea of "all". Unfortunately, over the years people baked the semantics of -Wall into their builds so new diagnostics could not be added to that flag. And clang’s -Weverything shows how the opposite can fail as well

There are some very wrong-headed warning options in gcc, such that turning them on and avoiding getting them will make your code worse. So -Wall means 'all recommended warnings'. Also there are some warnings that won't be produced if you compile without optimization, because the needed analysis isn't performed.

And yet we have things like -Wmaybe-uninitialized in -Wall which by definition will occasionally warn on perfectly good code.

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

#270

Post by account42 »

airocker wrote: post #175
dahfizz wrote: post #135

Earlier quoted context omitted.

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.

I dont think kernel handles NPEs: https://stackoverflow.com/questions/63091446/what-happens-at...

From your link:

A NULL pointer in most (but not all) C implementations is address 0. Normally this address is not in a valid (mapped) page.

Any access to a virtual page that's not mapped by the HW page tables results in a page-fault exception. e.g. on x86, #PF.

This invokes the OS's page-fault exception handler to resolve the situation.

Post reply on HN