Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

openwall.com

Post reply on HN
Print view View original

41–50 of 78 posts

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#41

Post by phh »

iforgotpassword wrote: post #30
Conan_Kudo wrote: post #11

Earlier quoted context omitted.

Note that Red Hat, SUSE, and Canonical all don't use them. They maintain their own kernel trees with their modifications. These kernel teams have different priorities: * stable ABI within a timespan (RH, SUSE) * feature backports based on customer demand (all three) * out of tree goop (Canonical) I've also heard from others (though notably, not folks specifically at these companies) that longterm kernels are iffier t…

Not in my experience. LTS never seems to break any compatibility, even internal kernel structs, function names, etc.

Actually LTS does break ABI, but gregkh is working with Android to make a partially ABI-stable LTS (I assume it would be a fork of the real LTS though?).

I know they are also working with RH and Suse, but I don't know if RH and Suse will only share the tools, or will also have the same LTS source tree.

When I say "partially-ABI" stable, their goal is to list acceptable symbols and automatically verify that vendor modules use those symbols, and only those accceptable symbols are ABI-stable.

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#42

Post by phh »

bluedays wrote: post #40
artistsvoid wrote: post #24

Earlier quoted context omitted.

Wrong, or at the least misleading. What do you mean by 'maintain' here? Because Arch is trying to stay on the bleeding edge side of things in a reasonable manner and is rolling release, they almost stay 1:1 with upstream, "maintains its own kernel" makes it sound like they would do some heavy patching and do active maintenance with certain kernel versions, et cetera. You can have a look yourself if you want to https:…

They have their own kernel as can be seen here: https://i.imgur.com/jP6Pdvq.png Also if you look at the diffstat you can see that there were a number of changes here: https://i.imgur.com/J2em78v.png It may be align with the majority of the kernel, but these patches exist in every version of the kernel that is released by Arch. What else could that be called aside from maintaining your own kernel? These changes are ex…

"maintaining your own kernel" in this context means that you're bringing bugfixes (including security) independently from the mainline Linux kernel, which would usually involve cherry-picking commits from the mainline.

Archlinux doesn't do that, and straight merges Linux mainline.

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#43

Post by m4r71n »

infogulch wrote: post #29
artistsvoid wrote: post #19

Earlier quoted context omitted.

Moderators can of course change the title, I don't think it's misleading and I was not trying to be. I guess 'reports' could be changed into 'finds' and it could be mentioned that it was found 'in its Linux kernel', not sure when the character limit would hit. 'current LTS kernels are not used in older Linux distros' - not sure what your point is with this. They absolutely could have used / can use LTS kernels if the…

"Red Hat finds security issue in Linux Kernel that had been fixed upstream for 17 months"

More like "Red Hat assigned a CVE to a security issue reported 17 months ago":

https://bugzilla.redhat.com/show_bug.cgi?id=1708775

I don't see what the big news here is, it's merely identifying a vulnerability with a proper CVE ID, end of story. The issue itself does not even have a serious security impact so it will likely never be fixed in RHEL.

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#44

Post by brozaman »

mikevm wrote: post #9

I really hate the fact that RHEL updates kernels so slowly. This becomes very painful when your product cannot take advantage of some advanced kernel features just because you have customers running RHEL :(.

If it's any consolation, I'm a software engineer working for Red Hat on the userspace part of one of our most bleeding edge products, and it's a pain for us too :). And it's a much bigger pain for our kernel guys

It would be way cheaper and easier for us to ship a newer kernel, we do it because it allows RHEL to have significantly less regressions than upstream kernels (and I'm talking about what the kernel engineers say, not some marketing bullshit).

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#45

Post by gbrown »

awill wrote: post #33
mikevm wrote: post #9

I really hate the fact that RHEL updates kernels so slowly. This becomes very painful when your product cannot take advantage of some advanced kernel features just because you have customers running RHEL :(.

It can be frustrating, but it's almost always worth it in a serious production environment. I have my own anecdote: I have serveral home servers running CentOS 7 (set up nearly 6 years ago). I update all the time and I've had zero issues. Literally nothing has ever broken. My previous servers ran CentOS 6, and were equally reliable. My desktop runs Arch Linux, and gets ever kernel dot release. I've had an unbootable…

Fedora seems like a sensible middle ground.

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#46

Post by gregkh »

despera wrote: post #39

While RedHat's backporting might not be great, i believe that upstream would do good if they would change their mind about having or not a well defined vulnerability identification and notification system. It's understandable that almost every piece of kernel code could potentially be a bad actor thus it would be tough to identify if every fix has security implications or not. Still there must be a middle ground arou…

And what would that "middle ground" look like?

With the current rate of change that the kernel community develops at, including the patches backported to the stable/longterm kernels, it's impossible to try to evaluate each and every patch for "is this something that could be exploited or not?"

Companies have tried, it was fun watching them, but they quickly gave up and declared it impossible and much safer to just take all stable patch updates instead.

I've also talked to MITRE about just applying for a CVE for ever stable kernel patch (20+ a day), and while they appreciated me not doing that, they agreed that the current model of CVEs just does not work at all for the Linux kernel and that what we are doing is fine.

See my Kernel Recipes talk last year for details about all of that if you are curious.

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#47

Post by josephcsible »

despera wrote: post #39

While RedHat's backporting might not be great, i believe that upstream would do good if they would change their mind about having or not a well defined vulnerability identification and notification system. It's understandable that almost every piece of kernel code could potentially be a bad actor thus it would be tough to identify if every fix has security implications or not. Still there must be a middle ground arou…

Not every security fix is known to be a security fix at the time. If such a system existed, people would be overconfident in it and this would happen even more.

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#48

Post by nordsieck »

radiator wrote: post #36
gregkh wrote: post #23

Earlier quoted context omitted.

Android doesn't seem to mind, they require the LTS updates to be taken for their devices (well, "require" is a strong word, they are pushing harder now than they were in the past, "required" will be happening in the future, hopefully...) As the number of systems running RHEL is really just a rounding error compared to the number of Android systems out there, maybe it doesn't really matter :)

But do the devices running Android generally operate with the same requirements as the servers running RHEL?

> But do the devices running Android generally operate with the same requirements as the servers running RHEL?

I guess it depends on the device and the business.

How many days of downtime on Amazon.com is the cost of bricking 1M phones? Or 100M?

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#49

Post by tssva »

bubblethink wrote: post #5
pjmlp wrote: post #4

Earlier quoted context omitted.

Probably drivers.

What about them ? I don't think the OP means using the upstream kernel directly, just why they don't use the same version as the LTS version.

Reasons I can think of include:

Not wanting to be tied to a kernel LTS release cycle you don't control.

The need to backport features and hardware enablement to the LTS kernel significantly offsets some of the benefits of using a LTS kernel.

The length of support for LTS kernels is significantly shorter than Redhat's length of support which means they would end up supporting it on their own for a significant timeframe anyways.

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#50

Post by jlg23 »

despera wrote: post #39

While RedHat's backporting might not be great, i believe that upstream would do good if they would change their mind about having or not a well defined vulnerability identification and notification system. It's understandable that almost every piece of kernel code could potentially be a bad actor thus it would be tough to identify if every fix has security implications or not. Still there must be a middle ground arou…

> i believe that upstream would do good if they would change their mind about having or not a well defined vulnerability identification and notification system.

No. Unless an issue is tested against HEAD, reporting it is just noise.

Reporting a fixed issue is a faux pas one has to pay for: Listening to snarky comments from friends and co-workers, or in this case, because they should know better, a few kegs of beer for the next FOSS event...

Post reply on HN