Page 1 of 1

Backporting security fixes

Posted: 2018/04/29 22:48:46
by homerwsmith
We have a few Centos 5.11 machines in operation, and I would like to know how to find out exactly which CVE security notices have been backported to kernel 2.6.18-419.el5 which is the last kernel available for CentOS 5, even though kernel 422 was
published by Red Hat because of at least two security fixes.

Thanks in advance,

Homer W. Smith
CEO Lightlink Internet

Re: Backporting security fixes

Posted: 2018/04/30 01:28:40
by TrevorH
I have moved your post to the CentOS Social forum as it's about CentOS 5 and those forums are now closed for new posts.

As you probably know, CentOS 5 went EOL at the end of March 2017 and there will be no more fixes released for it.

You can look at the output from rpm -q --changelog kernel- | less to see the fixes that were included in that last kernel and that should show you the last CVEs that were fixed. All subsequent fixes to RHEL 5 have been to the EUS subscription-only version and the source code for that is not released or available for CentOS to rebuild. We have no more knowledge of what is included in those post-March 2017 modifications than you do.

Re: Backporting security fixes

Posted: 2018/05/01 06:49:12
by homerwsmith
Thanks for answering.

So let me expand the question to Centos 7.

Say I update to kernel 200 the day it is available.

Then more security patches are added to the kernel by redhat who generates kernel 201. If those
patches are 'backported' to kernel 200, since I already have it installed, it won't update that kernel, so I won't
get those patches. Is that right?

Presumably Centos would make the new kernel available as 201 though so next update I would get it.

So I don't really understand the usefulness of backporting, as if I have already downloaded a package,
and something gets backported into it, I won't get it until someone ups the number version of the package.

I am sorry to be so dense, but I would love some enlightenment.

Thanks Homer

Re: Backporting security fixes

Posted: 2018/05/01 11:03:06
by jlehtone
You have some misunderstanding about "backporting".

Lets have package foo. foo-3 is released. You install it.

Some more work occurs on foo and foo-3.1 is released. You update to it. At the same time the developers invent a lot of new goodies and branch development. They create foo-4.pre, but don't release it.

Yet more work is put to both branches and then both foo-3.2 and foo-4 are released. You do update to foo-3.2. You don't wan't to install foo-4, for it is drastically different.

Since foo-4 is already out, no more work goes into foo-3.*. There is no reason to divide the resources. Eventually a foo-4.1 appears.

After foo-4.1 a security issue is detected, fixed, and a new version with fix is released as foo-4.2. The same code and issue does exists in foo-3.2 too.

Now we look at what did change between foo-4.1 and foo-4.2 in order to fix the issue. We apply those changes into foo-3.2 to create foo-3.2.1. We have now backported the fix from foo-4 to foo-3. You update to foo-3.2.1.

Re: Backporting security fixes

Posted: 2018/05/01 11:19:40
by TrevorH
Or more succinctly, kernel 201 replaces kernel 200 and requires a reboot to implement. Each one is rebuilt by CentOS and replaces the previous one.