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

71–78 of 78 posts

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

#71

Post by fomine3 »

jcrawfordor wrote: post #66
8organicbits wrote: post #10

Can someone in the kernel dev space give a longer explanation for this? This looks to me like Red Hat assigning a CVE to something patched a long time ago. Is this just record keeping to label security issues with CVEs or has Red Hat left this unpatched for 17 months? (Or something else?)

Red Hat's security program includes disclosing and tracking security vulnerabilities found in its products. As part of doing this, they obtain CVEs for any vulnerabilities which did not previously have them. CVE IDs are required by US gov't and many corporate security programs, as the broader point of the CVE system is not only to provide standardized identification of vulnerabilities but also assign certain metadata…

Great explanation.

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

#72

Post by fomine3 »

Conan_Kudo wrote: post #11
baggy_trough wrote: post #3

Why don't Red Hat et al use the LTS kernels?

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…

Because release schedule doesn't match to LTS release schedule? Distributors may want to ship OS with latest kernel than latest LTS.

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

#73

Post by bonzini »

ebiggers wrote: post #69
jcrawfordor wrote: post #66

Earlier quoted context omitted.

Red Hat's security program includes disclosing and tracking security vulnerabilities found in its products. As part of doing this, they obtain CVEs for any vulnerabilities which did not previously have them. CVE IDs are required by US gov't and many corporate security programs, as the broader point of the CVE system is not only to provide standardized identification of vulnerabilities but also assign certain metadata…

> In this somewhat unusual case, the problem was found and corrected in the Linux kernel through a typical bug-fix process and not handled as a security vulnerability, so no CVE was assigned. This isn't unusual. This is actually the usual case. The unusual thing here is actually that someone downstream noticed they were missing a fix (probably because its LTP regression test was failing, which is also unusual because…

> More commonly, no one notices and these bugs never get fixed in downstream kernels that aren't staying up to-date with LTS

Actually a lot of RHEL subsystems are updated wholesale by including all upstream patches (not just those that go into LTS kernels), and this way all such fixes are automatically included.

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

#74

Post by bonzini »

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…

The RHEL8 kernel has a few tens of thousands of commits on top of 4.18. That's a bit more than Arch. :)

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

#75

Post by phh »

stonogo wrote: post #64
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 :)

Yes, that's why all the servers in the datacenter are running Android, which has a stellar security record. This sort of myopia is yet another excellent reason for Red Hat to take their kernel process in-house.

LTS' security record is definitely not to be proven. The example we're currently commenting on this thread is only one occurence. It is highly re-occuring.

RHEL fixes only CVEs. Linus Torvalds consider there is no such thing as a security bug, that actually every bug is a security bug. So RHEL's kernel can't be secure.

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

#76

Post by awill »

hnra wrote: post #68
awill wrote: post #33

Earlier quoted context omitted.

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…

I would recommend keeping an lts kernel around when running arch. It’s not much harder than pacman-S linux-lts.

That probably helps, though many of my issues have been other problems, like xorg, the nvidia driver, grub (or now systemd-boot)

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

#77

Post by gregkh »

phh wrote: post #41
iforgotpassword wrote: post #30

Earlier quoted context omitted.

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 mod…

That "partially-ABI stable" is the same exact thing that Red Hat and SUSE and Debian have been doing for 20+ years now. Nothing major and exciting there, but see the presentations at the Linux Plumbers conferences for details on the tools being used if people are curious (hint this time everyone is working together on the same set of tools...)

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

#78

Post by gregkh »

baggy_trough wrote: post #17
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…

What is the difference between a "longterm kernel" and a "regular stable kernel"?

"regular stable kernel" lives only about 3-4 months, just long enough for the next release from Linus to feel "good enough".

"longterm kernel" lives for 2+ years. I pick one each year (usually the last one released in a year) for that.

See the releases page on kernel.org for details on what the longterm kernels are, and for how long they are being maintained and by whom.

Post reply on HN