Remote code execution vulnerability in Samba

Indeed, as a developer 6% is rather a lot. As a user, I would and have chosen 6% CPU time hits in the name of security, and scarcely noticed the difference. Not really sure how to reconcile these two perspectives :)

>If I were doing Samba again from scratch, I'd do it in Google go.

Is this just an offhand glib comment, or do you mean it literally?

If that latter, I'm curious why it would be Go that you'd pick specifically, because at first glance it seems like Rust would be a better fit for Samba.

> If I were doing Samba again from scratch, I'd do it in Google go.

A fine idea,. If you don't ever need to use a debugger. Or compile for anything except x86 and ARM (using the official toolchain anyway).

Crashing on uninitialized access would be nice, but how it could be implemented? For example, how a C compiler can deduce that the following should terminate the program:

int foo(int *bar) {
return *bar;
}

int test;
foo(&test);

when foo lives in a shared library and no whole program analysis is possible?

So it sounds like that the most pragmatic solution is to require by default that one can get a pointer only for already initialized things unless the compiler can prove that &uninitialized is safe. This should be compatible with older compilers.

-fsanitize=undefined does not catch use of uninitialized values. You want -fsanitize=memory for that. http://clang.llvm.org/docs/MemorySanitizer.html (Mind you, -fsanitize=bool is something of a cheap msan, but we don't deliberately initialize bool objects to a non-true/non-false value.)

Clang's -Wuninitialized and -Wsometimes-uninitialized will probably do what you actually want in a warning. The "sometimes uninitialized" warning works by assuming that if you have an if-statement then you intend for it to potentially be false sometimes or true sometimes, and therefore that the value must be initialized either way (similarly for other control flow constructs), however if it can't show otherwise then it will assume that you have arranged multiple variables to be correlated and suppresses the warning if it's a false positive. (Note: passing an uninitialized value as a parameter has undefined behaviour before the callee ever runs.)

You may think that you want it to warn more aggressively, but then I suggest you try clang or gcc's -Wconditional-uninitialized warning. It's useless because it fires everywhere. -Wsometimes-uninitialized can be used with -Werror.

Why not both? Since it's undefined behavior, a compiler can zero-initialize uninitialized variables while at the same time producing a compile-time warning.

> ...while at the same time annoying Windows developers, since last I looked their default compiler still didn't allow for mixed statements and declarations, a 15-year-old feature of the C language.

I happen to have a few MS-VC compilers around... A quick check with:

int main() { 0; int class; }

(the variable is named `class` to prevent accidental compiling as C++).

VC-2010 (CL version 16): error C2143: syntax error : missing ';' before 'type'
VC-2012 (CL version 18): OK!

So they finally did it, it just took 12 years.

> What if all the paths that use the variable initialize it, but the compiler can't see it? For instance, if the variable is only used if a complicated condition is true, and earlier in the function initialized only if a different complicated condition (which is a superset of the other condition) is true?

Then you have control flow with complex variable interdependencies that is confusing not only to the compiler but the more so to all the human readers of your code. Refactor! ;) But I know what you're talking about. I see this pattern a lot with null pointer analysis done by some tools for Java. I always try to take these warnings seriously even if the code is in fact correct, if only because getting rid of it (and not by simply silencing it) would make the code clearer.

A code base in C that does all this wrapping malloc stuff is postgresql, with palloc and pfree. This is actually a hierarchical memory context allocator, to allow for allocating storage for the right lifetime, primarily targeted at avoiding memory leaks. It uses the 'allocation header just above the allocated memory' style system mentioned above, and does what it can to validate that an arbitrary pointer passed to it is in fact something allocated by palloc. Of course, pfree() itself mostly just makes that memory available to be reused in its allocation context pool: it's not freed to the system until that context is destroyed.

> [malloc] I still think that more safety by default would help everyone.

Seems that you already have it for a long time, you just did not even try to read the right manual, and never tried setting the variable MALLOC_CHECK_ in your .bashrc because it takes too much CPU time:

man 3 malloc
...
Recent versions of Linux libc (later than 5.4.23) and glibc (2.x) include a malloc() implementation which is tunable via environment variables. When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple errors, such as double calls of free() with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be protected against, however, and memory leaks can result.
If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic message is printed on stderr; if set to 2, abort(3) is called immediately; if set to 3, a diagnostic message is printed on stderr and the program is aborted.

Obviously, you also do not want to see the warnings so you do not keep stderr open/visible - same you do not keep an xconsole open when running X neither.

The C language is made for people who know what they do, if a variable is not initialised it is because it shall not be initialised. If you modify a function in C you have to understand the whole function first; if your way to program is to modify random lines and see with a debugger if your own test case works then you'd better use another language.