Serious Linux kernel security hole uncovered

[thmm]

The Zero Day Initiative originally rated this Linux 5.15 in-kernel SMB server, ksmbd, bug a perfectly awful 10.

https://www.zdnet.com/article/patch-now-serious-linux-kernel-security-hole-uncovered/

[keskiverto]

"This new program [ksmbd], which was introduced to the kernel in 2021, was developed by Samsung."

"[SMB2_TREE_DISCONNECT] has a use-after-free and OOPS"


Joys of cutting edge. The latest RHEL distro [9] was released last May and is not affected as its kernel does not yet (if ever) contain that feature.


use-after-free

Scopes, lifetime, and memory management are common topic on this fora, but how common are use-after-free questions here? I don't recall many.

[JLBorges]

> how common are use-after-free questions here?

A use-after-free bug is extremely rare in a small code base, maintained by a single programmer.

It is a pretty common bug in large (non-RAII) code bases, where concurrency and many programmers are involved.
For instance, in the Chromium family (pre MiraclePtr<T>),

Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs.
https://www.chromium.org/Home/chromium-security/memory-safety/

[thmm]

Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs.
https://www.chromium.org/Home/chromium-security/memory-safety/

Mozilla and Microsoft said sth. similar. That's the reason why they want to use Rust.

[jonnin]

Why its still happening... would be interesting to know if its 40+ year old code or just screw ups. In the mid/late 80s I know people did this on purpose, accepting the risks in favor of performance, out of ignorance or desperation or whatever. I recall it being occasionally advocated during those years, by peers & professors here and there.

[thmm]

Chrome and Firefox certainly didn't exist 40 years ago.

[JLBorges]

> Why its still happening... would be interesting to know if its 40+ year old

It is a large code base that uses a lot of raw owning pointers. I guess, from a fear of loss of performance with smart pointers.

[jonnin]

Chrome and Firefox certainly didn't exist 40 years ago.

True, but both inherit from original mozilla at some level, so ... ? 30 years then?

But, agree with JL .. probably just carelessness with raw pointers.

[thmm]

Mozilla was founded in 1998, so I guess they used very old C++ or maybe even C.
https://en.wikipedia.org/wiki/Mozilla

[seeplus]

Isn't it more relevant the experience of the programmers rather than the age of the system? And as anyone can have an 'off day' (including me! - and I've used C++ since the early 1990's), we have very rigorous code review. Only reviewed code can be moved into 'production'.

Aren't these memory issues etc more due to both the 'quality' of the programmers used and the testing/review processes?

[JLBorges]

> Aren't these memory issues etc more due to both the 'quality' of the
> programmers used and the testing/review processes?

It is not trivial to review and clean all the legacy code in a huge code base which has evolved over a number of years and is still continually evolving. 'Stop all new enhancements till legacy code is completely rewritten' is not a feasible proposition in a fiercely competitive domain.

In any case, rigorous code reviews alone would not guarantee temporal safety in code where performance is an overriding design goal.

[seeplus]

It is not trivial to review and clean all the legacy code in a huge code base which has evolved over a number of years and is still continually evolving.

I was referring more to when the code was written.

where performance is an overriding design goal.

Surely, the first priority is to have a correct, working program...

[JLBorges]

> I was referring more to when the code was written....

This kind of error need not be because of an obvious error in a piece of code as written by a single programmer. The code could have been robustly reviewed and found to be perfectly fine before it was committed. Much later, a change or addition to some other part of the code base, by another programmer, may violate the assumptions made by the original programmer about how that part of the code would be used. Now the code is broken, though when the code was originally written and reviewed, these assumptions appeared to be natural, sensible, reasonable.

[Duthomhas]

seeplus wrote:

Surely, the first priority is to have a correct, working program...

You’d be shocked, then, by how often that is not true.

Having a half-functional bird in the hand is better than two in the bush.


EDIT:
An apropos example is the Zoom app. That thing is a disaster on wheels. But everyone uses it. Why?

Because they cheated. They ignored sound programming principles to get their product out there first.

[seeplus]

Well hand-on-heart I've never knowingly issued production code with known bugs. I've issued code with missing features and code that later was found to have bugs but then all known ones were fixed before the next release.

Maybe I've been 'lucky' with the companies for which I've worked - as I've either worked for in-house development or for software houses that produced line-of-business software to spec (where the only competition was obtaining the contract in the first place). I've never worked in an environment/company that produced programs for public usage (and I'm not starting now as I'm now semi-retired!).

[George P]

Over the years I remember all the *nix cultists in my slice of reality gleefully chortling about all the security holes in Windows­­®, loudly declaiming the superiority of Linux, etc.

Nothing made by flawed human beings is without some defect. Software is no exception.

I personally won't gloat, much, about this vulnerability. Heh­™.

[seeplus]

Nothing made by flawed human beings is without some defect. Software is no exception.

Very true :)

[Ganado]

I personally won't gloat, much, about this vulnerability

And you shouldn't, it's quite a silly thing to gloat about. When you can't see the source code to something, or even when you can see it, and don't have control over it, there's really nothing you can do over it. You just gotta sit there and take it. That's what proprietary software is; you just have to sit there and watch what it does to your computer, and you have no say about it. (And that's if you even know about it; it could just be going on behind your back -- that doesn't mean the problems don't exist.)

That aside, Windows has its fair share of bugs/exploits like any other software. e.g. WannaCry. Or a WannaCry-like bug that was also recently brought forth. WannaCry required SMB (like the OP), while this latest bug affects more than just SMB. But on the up-side, this latest vulnerability was an N-day exploit that had a three-month patch time of preparation before it was publicly announced.
https://arstechnica.com/information-technology/2022/12/critical-windows-code-execution-vulnerability-went-undetected-until-now/

Not being able to see the bugs crawling on your skin doesn't mean they aren't there.

[George P]

@Ganado, have a nice hot cup of sarcasm to enjoy the New Year.

My comment about gloating was all that.

A riposte at all the *nix cultists who still act "Holier than Thou." Are you Part of The Body, Ganado? Are you an Archon?

[Cubbi]

this was the fix:
https://github.com/torvalds/linux/commit/cf6531d98190fa2cf92a6d8bbc8af0a4740a223c

	ksmbd_tree_conn_disconnect(sess, tcon);
+	work->tcon = NULL;
	return 0;

where the last line of ksmbd_tree_conn_disconnect is kfree(tree_conn);
a very C kind of a fix for a very C kind of a problem