This bug was fixed in the package linux - 3.13.0-151.201
---------------
linux (3.13.0-151.201) trusty; urgency=medium
* linux: 3.13.0-151.201 -proposed tracker (LP: #1774190)
* CVE-2018-3639 (x86)
- SAUCE: Set generic SSBD feature for Intel cpus
- KVM: vmx: fix MPX detection
- KVM: x86: Fix MSR_IA32_BNDCFGS in msrs_to_save
- x86/cpu: Add CLZERO detection
* Trusty cannot load microcode for family 17h AMD processors (LP: #1774082)
- x86/microcode/AMD: Add support for fam17h microcode loading
linux (3.13.0-150.200) trusty; urgency=medium
* linux: 3.13.0-150.200 -proposed tracker (LP: #1772970)
* CVE-2018-3639 (x86)
- x86/cpu: Make alternative_msr_write work for 32-bit code
- x86/cpu/AMD: Fix erratum 1076 (CPB bit)
- x86/bugs: Fix the parameters alignment and missing void
- KVM: SVM: Move spec control call after restore of GS
- x86/speculation: Use synthetic bits for IBRS/IBPB/STIBP
- x86/cpufeatures: Disentangle MSR_SPEC_CTRL enumeration from IBRS
- x86/cpufeatures: Disentangle SSBD enumeration
- x86/cpufeatures: Add FEATURE_ZEN
- x86/speculation: Handle HT correctly on AMD
- x86/bugs, KVM: Extend speculation control for VIRT_SPEC_CTRL
- x86/speculation: Add virtualized speculative store bypass disable support
- SAUCE: x86/cpu: Rename x86_amd_ssbd_enable
- x86/speculation: Rework speculative_store_bypass_update()
- x86/bugs: Unify x86_spec_ctrl_{set_guest,restore_host}
- x86/bugs: Expose x86_spec_ctrl_base directly
- x86/bugs: Remove x86_spec_ctrl_set()
- x86/bugs: Rework spec_ctrl base and mask logic
- x86/speculation, KVM: Implement support for VIRT_SPEC_CTRL/LS_CFG
- KVM: x86: introduce num_emulated_msrs
- KVM: SVM: Implement VIRT_SPEC_CTRL support for SSBD
- x86/bugs: Rename SSBD_NO to SSB_NO
- KVM: VMX: Expose SSBD properly to guests.
* CVE-2018-7492
- rds: Fix NULL pointer dereference in __rds_rdma_map
* CVE-2017-0627
- media: uvcvideo: Prevent heap overflow when accessing mapped controls
* CVE-2018-8781
- drm: udl: Properly check framebuffer mmap offsets
* CVE-2018-1068
- netfilter: ebtables: CONFIG_COMPAT: don't trust userland offsets
-- Stefan Bader <stefan.ba...@canonical.com> Wed, 30 May 2018 16:02:01
+0200
** Changed in: linux (Ubuntu Trusty)
Status: Fix Committed => Fix Released
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-0627
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-1068
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-3639
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-7492
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-8781
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1774082
Title:
Trusty cannot load microcode for family 17h AMD processors
Status in linux package in Ubuntu:
Invalid
Status in linux source package in Trusty:
Fix Released
Bug description:
[Impact]
AMD has recently updated the microcode in the linux-firmware tree for
family 17h processors to address Spectre variant 2. The Trusty 3.13
kernel cannot load the microcode because it is missing a backport of
upstream patch f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf which leaves
AMD machines vulnerable.
[Test Case (option 1)]
Test must be done on a 17h family processor:
1) Take note of the microcode version before applying updated
microcode:
$ sudo cat /sys/devices/system/cpu/cpu0/microcode/version
0x8001227
2) Get updated amd64-microcode package from the Ubuntu Security Team.
Install it and reboot machine.
3) Verify that the microcode version has changed.
[Test Case (option 2)]
Alternate test case (useful in the situation that the test system is
already running the latest microcode revision due to a BIOS update):
1) Fetch the latest 17h family microcode revision from here (you may
want to verify the signature):
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-
firmware.git/tree/amd-ucode/microcode_amd_fam17h.bin
2) Move it into /lib/firmware/amd-ucode/
3) Force a microcode reload:
$ echo 1 | sudo tee /sys/devices/system/cpu/microcode/reload
4) Verify that the following error message is *not* in your syslog:
May 30 04:22:55 lodygin kernel: [ 388.290105] microcode: patch size mismatch
May 30 04:22:55 lodygin kernel: [ 388.290149] microcode: Patch-ID
0x08001227: size mismatch.
[Regression Potential]
The regression potential to the kernel revolves around the fact that
the IBRS/IBPB implementation in the 3.13 kernel may not have been put
through its paces yet due to a lack of available microcode updates.
There could be a latent bug present that is uncovered.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774082/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
