I love the little nugget in the mitigations section. You can plug the hole for a normal filesystem, but then FUSE filesystems have an additional problem: "if an attacker FUSE-mounts a long directory (longer than 8MB), then systemd exhausts its stack, crashes, and therefore crashes the entire operating system (a kernel panic)." If there's one place other than the kernel where truly defensive programming should be appl…
systemd? More like systemK! But seriously, are non-systemd systems not vulnerable to the FUSE portion of this? (CVE-2021-33910)
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…
Cached 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?
Local root escalation is very common vulnerability. It's almost pointless to expect that attacker will not be able to escalate his privileges given enough time, if he got user account access. One weak layer of defense at most.
> 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.
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);
}
I love the little nugget in the mitigations section. You can plug the hole for a normal filesystem, but then FUSE filesystems have an additional problem: "if an attacker FUSE-mounts a long directory (longer than 8MB), then systemd exhausts its stack, crashes, and therefore crashes the entire operating system (a kernel panic)." If there's one place other than the kernel where truly defensive programming should be appl…
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 your comment, though?
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
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.
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
Yeah; AFAIK you need something like clang-tidy's cppcoreguidelines-narrowing-conversions check (which everyone should definitely be using). (edit: But I'm wrong! That check is apparently similar to the -Wconversion mentioned by someone else.)