Back to work, Linux admins: You may have a CVSS 10 kernel bug to address Merry Christmas, Linux systems administrators: here's a kernel vulnerability with a CVSS score of 10 potentially in your SMB server. It can be exploited to achieve unauthenticated user remote code execution. Yes, this sounds bad, and a severity score of 10 out of 10 isn't reassuring at all. Luckily for the sysadmins reaching …
Yeah. I mean, NFS (of any version) is kind of a mess, but the SMB protocol – yikes. I grabbed the spec 25 years or so ago, read it, and filed it away under "nope, never going to implement that if I can help it".
(I miss AFS. Also not perfect by any means, but it had some good ideas.)
I could see ksmbd being useful for office LANs where fast file access over 10 Gbps Ethernet is needed. Samba usually has odd performance problems that come with being an ancient Apache project. NFS with user-level permissions is something nobody wants to figure out.
As long as ksmbd is opt-in and documented as experimental during development, what's to complain about?
"As long as ksmbd is opt-in and documented as experimental during development, what's to complain about?"
If any vuln scores a Perfect 10, there definitely is something to complain about. Since it is created by Samsung, it is possible that some Samsung products has it enabled.
If the vuln was in Micros~1 product, this article would have garnered many times the current volume of comments denigrating M$ for shoddy code, lack of testing/QA. And rightfully so. No need for kid-glove treatment with MS or free software.
I know Samsung are fairly keen[1] on installing bloatware, but a kernel level SMB server? That seems a stretch to me. I hope I'm not wrong, and will of course cringe if that's ever released into the wild.
I agree with the sentiment that M$ articles get more comments. Perhaps that's proportional to them being so prevalent, so regular and so impactful on a large user base. Or perhaps it's because the vast majority of commentards are either extremely pissed right now, or dressed up as Santa and sneaking into their kids' rooms with a pillow sack over their shoulder!
Since I don't have a Santa costume, and I'm clearly not inebriated, I think I'll try to catch up on the first group. Here! Join me if you like --->
[1] English understatement!
Tizen is an utter car crash, and this sounds like it's continuing in the fine tradition of software development at Samsung.
Ah crapolla, I wasn't even considering TVs, but it's obvious now you've pointed it out. In my defence I've not owned a telly for 25 years.
I was wondering why Samsung was messing with kernel stuff. Now you've cleared that up for me I have to reverse my view to: oh yeah, ksmbd will be prevalent in the wild. And really cringe. Because as I'm sure we'd all agree, a TV is the ideal hardware for a home network server!
Cheers Dan :)
Yeah, NFS perms on an uncurated home LAN will probably get UID/GID collisions. I expect use of all_squash would solve most cases. If someone's trying to share something top secret (ie. "dodgy"), they'd better know better!
But in the "I could see... office LAN" scenario that really shouldn't be a problem. If each box has its own unique UID/GID config there, someone needs BOFHing in the eye. Hard!
NFS works OK if you have a central user directory running LDAP or something (RIP, NIS) and all of your systems are running the same OS. It becomes a nightmare otherwise. Interoperability even between different *nix flavors is mostly wishful thinking. And once you're maintaining an LDAP server you're like 90% of the way toward just firing up an Active Directory domain, because AD at least comes with management tools.
Rubbish. In the 1990s I routinely had NFS working among AIX, Solaris, HP-UX, SCO ODT, SCO Unixware, and Linux, because I was supporting a product on all those OSes and that was the easiest way to use a centralized source code repository.
Hell, I could mount my NFS filesystems under OS/2 when I was feeling really ambitious. Maybe got it working under Windows too; I don't remember now.
> "Samba usually has odd performance problems that come with being an ancient Apache project."
What are you smoking, and can I have some please ? :-).
Samba was started around 1992, before Apache was a gleam in anyone's eye.
As for performance, putting something in the kernel isn't an automatic "go faster" switch for the processor. See here for details:
https://samba.plus/blog/detail/ksmbd-a-new-in-kernel-smb-server
It's.. complicated. Right now there's no integration between ksmbd and Samba, although we collaborate on SMB3+POSIX extension development.
Samba is a large and old project, with many procedures in place to try and prevent accidents like this (although we're both written in C, so until we can port to a safer language - which will probably never happen - there will *always* be disasters like this).
Having said that IMHO the kernel cifsfs and ksmbd code have some quality issues which come down to insufficient code review practices. I have complained long and bitterly about this in the past and the people involved are well aware of my opinions.
Take a look at Samba's gitlab page:
https://gitlab.com/samba-team/samba/-/merge_requests
Every potential commit has to go through a full pipeline continuous integration build (look here for examples):
https://gitlab.com/samba-team/samba/-/pipelines
and all commits must have 2+ Samba Team engineer review and sign-off before merging into the upstream codebase. Currently I don't see something similar for cifsfs and ksmbd. I'd be a lot happier if they had something like this.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
