security update in Fedora 24 for binutils and kernel

Status: stable 3 years ago

The 4.5.2 stable update contains a number of important fixes across the tree. This build should also boot on some of the i686 systems that would not boot before.

Reboot Required

After installing this update it is required that you reboot your system to ensure the changes supplied by this update are applied properly.

How to install

sudo dnf upgrade --advisory=FEDORA-2016-7f37d42add

Comments 22

This update has been submitted for testing by jforbes.

kevin edited this update.

New build(s):

  • binutils-2.26-18.fc24

kevin edited this update.

kernel-PAE-4.5.2-300.fc24.i386 (From testing) does not boot at all for me on i386 bare metal. All I am seeing is a "black screen".

karma: -1

This update has been pushed to testing.

This i686 issue should be fixed in the 301 build, sorry about that. 300 only contained half a fix.

Moved from 4.5.1-300.fc24.x86_64 to this w/o issue. dmesg and journalctl -b look clean enough and all's well. I've not tried anything in the BZ reports tho.

FWIW, I did dnf install *.rpm and that downloaded zlib-devel-1.2.8-10.fc24.x86_64 from the fedora repos; it was not in the set downloaded by bodhi. (zlib-devel is needed by binutils-devel). I only mention this in case it's a sign that zlib-devel should have been a product of this build and/or pulled down by bodhi.

karma: +1 critpath: +1

FYI: kernel-PAE-4.5.2-301.fc24.i686 boots for me but later on fails with i915-problems.

critpath: -1 #1302071: +1

tested x86_64 on bare metal and VM, and i686 and PAE in a VM, all boot OK.

karma: +1 critpath: +1 #1302071: +1

Wasn't this update primarily to address i686 issues on bare metal?

This update has been submitted for stable by bodhi.

Works great! LGTM! =)

karma: +1

corsepiu: No, it wasn't. the i686 issue affects VMs as well as metal, and the CVEs are, well, CVEs.

i686 was DOA anyway, so it's not like we can make it any worse by approving the update.

corsepiu: adam is correct, the 4.5.2 update contains 125+ fixes compared to the last update pushed, some of those being security related. That is the main reason for the update. Trying to get an F24 update that would boot on at least some form of 32bit was enough of a reason for me to lose some additional sleep and do a 301 build, but 4.5.2 would have been submitted either way. Anything broken on 32bit at this point is not a regression, previous F24 kernels would not boot on any 32bit system. Getting this booting on some will at least expose the other issues that need to be addressed.

@jforbes: I understand, RH is not interested in the i686 anymore and "fedora-testing" therefore has defined the i686 as irrelevant. I regret, but to me this read as "RH is not interested in the community", anymore.

@corsepiu: Then perhaps you completely misread my comments. Yes, i686 is not a priority for us, but we are very interested in the community here. The fact that a member of the community spent so much time tracking down the problems with i686 was enough motivation for me to stay up most of the night and get a kernel that would boot on at least some i686 out. Sure, there may be other problems, but we can't even know what those are until there is something out there that works for at least some 32bit testing. That will allow the other issues to be discovered and potentially fixed. No one can even try to fix them if they don't know about them. The fact that you can now see an i915 issue is clearly progress compared to the previous updates.

The 4.5.2 update is a separate issue. Yes, it would have been pushed anyway. It does fix a lot of issues. The idea of adding negative karma for a non regression is a broken system. Having a 32bit kernel that won't boot is not a regression, 4.5.1 doesn't boot on 32bit either. Giving 4.5.2 negative karma because it still doesn't boot on 32bit is like saying "because my issue still is not fixed, I don't want anyone else's to have access to their fixes either". That has nothing to do with 64bit vs 32bit, it is the case with non regression issues in general. If the currently supported package in stable has the issue, it is not a regression, it is just a bug that hasn't been fixed yet. If we only issued updates when every single issue was fixed, there would never be an update... ever.

@jforbes: I reported the i915 issue 2 months ago: https://bugzilla.redhat.com/show_bug.cgi?id=1307033 sad but true: it was ignored.

But you are right insofar, it was overshadowed by other issues (those nickc, hjlu and other addressed) which rendered reproducing it difficult.

Anyway, lets stop this discussion here. bodhi is not the right place to discuss it or RH politics.

This update has been unpushed.

This update has been submitted for testing by lmacken.

x86_64 works for me on a NUC and Macbook Pro.

karma: +1 critpath: +1

This update has been submitted for stable by kevin.

This update has been pushed to stable.

Content Type
Test Gating
Submitted by
Update Type
Update Severity
stable threshold: 3
unstable threshold: -3
submitted 3 years ago
in testing 3 years ago
in stable 3 years ago
modified 3 years ago

Related Bugs 6

00 #1302071 i686 kernel-4.5.0-0.rc1.git0.1.fc24 does not boot on some systems (KVMs, some metal)
00 #1309980 Skylake intel_pstate won't boot
00 #1323956 CVE-2016-3961 xsa174 xen: hugetlbfs use may crash PV Linux guests (XSA-174)
00 #1327219 CVE-2016-3961 xsa174 xen: hugetlbfs use may crash PV Linux guests (XSA-174) [fedora-all]
00 #1328478 CVE-2016-3955 Kernel: usbip: buffer overflow by trusting length of incoming packets
00 #1328479 CVE-2016-3955 Kernel: usbip: buffer overflow by trusting length of incoming packets [fedora-all]

Automated Test Results

Test Cases

00 Test Case kernel regression