SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,097
Original Poster
Rep:
Quote:
Originally Posted by GazL
Yeah I've seen some talk about a use-after-free local priv escalation vulnerability via the crypto API, so that may be one to keep an eye on.
IF we are talking about the same thing, it is CVE-2019-8912. I've just searched through the forth coming patches and did not find anything relating to that number, but this may be it?
Quote:
KASAN has found use-after-free in sockfs_setattr.
The existed commit 6d8c50dcb029 ("socket: close race condition between sock_close()
and sockfs_setattr()") is to fix this simillar issue, but it seems to ignore
that crypto module forgets to set the sk to NULL after af_alg_release.
KASAN report details as below:
BUG: KASAN: use-after-free in sockfs_setattr+0x120/0x150
Write of size 4 at addr ffff88837b956128 by task syz-executor0/4186
This may be totally unnecessary, but we actually had more patches come
in this last week than we had for rc7, which just didn't make me feel
the warm and fuzzies. And while none of the patches looked all that
scary, some of them were to pretty core files, so it wasn't all just
random rare drivers (although those kinds also existed).
So I agonized about it a bit, and then decided to just say "no hurry"
and make an rc8. And after I had tagged the rc, I noticed a patch in
my inbox that I had missed that was a regression from one of the very
patches this last week, so that made me feel like rc8 was the right
decision.
Anyway, maybe I should have just checked my email more carefully, and
maybe I'm just being unnecessarily worried. I could have just untagged
the rc release (it hadn't actually gone public when I noticed),
applied the missing patch, and called it good. But instead I took it
as confirmation that we should bake this thing one more week.
Confirmation bias? Maybe. Because while rc8 is bigger than rc7, it's
not *hugely* so, and none of the changes look all that controversial.
About 30% drivers (gpu, net, rdma, sound, scsi..), 20% networking, and
the rest is arch updates, some mm fixes, some key handling fixes,
filesystem, include files..
But on the whole I just felt happier with an extra rc than worrying
about things.
Shortlog appended for some flavor of the details.
Linus
---
Last edited by cwizardone; 02-24-2019 at 07:08 PM.
Linux 5.0
From: Linus Torvalds
Date: Sun Mar 03 2019 - 19:43:23 EST
Ok, so the last week of the 5.0 release wasn't entirely quiet, but
it's a lot smaller than rc8 was, and on the whole I'm happy that I
delayed a week and did an rc8.
It turns out that the actual patch that I talked about in the rc8
release wasn't the worrisome bug I had thought: yes, we had an
uninitialized variable, but the reason we hadn't immediately noticed
it due to a warning was that the way gcc works, the compiler had
basically initialized it for us to the right value. So the same thing
that caused not the lack of warning, also effectively meant that the
fix was a no-op in practice.
But hey, we had other bug fixes come in that actually did matter, and
the uninitialized variable _could_ have been a problem with another
compiler.
Regardless - all is well that ends well. We have more than a handful
of real fixes in the last week, but not enough to make me go "Hmm,
things are really unstable". In fact, at least two thirds of the
patches are marked as being fixes for previous releases, so it's not
like 5.0 itself looks bad.
Knock wood.
Anyway, with this, the merge window for 5.1 is obviously open, and I'm
happy to see that I already have several early pull requests. Which
I'll start processing tomorrow.
And appended is - as usual - the shortlog just for the last week. The
overall changes for all of the 5.0 release are much bigger. But I'd
like to point out (yet again) that we don't do feature-based releases,
and that "5.0" doesn't mean anything more than that the 4.x numbers
started getting big enough that I ran out of fingers and toes.
Linus
---
Last edited by cwizardone; 03-04-2019 at 07:06 AM.
Linux version 5.0.0-local (build@ws1) (gcc version 8.3.0 (GCC)) #1 SMP PREEMPT Mon Mar 4 11:43:59 GMT 2019
Seems ok, so far.
I even enabled the newly included terminus-32 console font.
It's a little bit big on my 100dpi laptop screen, but I'll take that over it being too small. Gives me 85x24, which is more or less the same as the old-school terminals would give you, and it'll do nicely until rc.font gets a chance to run.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
