This bug was fixed in the package linux - 3.13.0-149.199
---------------
linux (3.13.0-149.199) trusty; urgency=medium
* CVE-2018-3639 (powerpc)
- SAUCE: rfi-flush: update H_CPU_* macro names to upstream
- SAUCE: rfi-flush: update plpar_get_cpu_characteristics() signature to
upstream
- powerpc/pseries: Support firmware disable of RFI flush
- powerpc/powernv: Support firmware disable of RFI flush
- powerpc/64s: Allow control of RFI flush via debugfs
- powerpc/rfi-flush: Move the logic to avoid a redo into the debugfs code
- powerpc/rfi-flush: Always enable fallback flush on pseries
- powerpc/rfi-flush: Differentiate enabled and patched flush types
- powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags
- powerpc: Add security feature flags for Spectre/Meltdown
- powerpc/pseries: Set or clear security feature flags
- powerpc/powernv: Set or clear security feature flags
- powerpc/powernv: Use the security flags in pnv_setup_rfi_flush()
- powerpc/pseries: Use the security flags in pseries_setup_rfi_flush()
- powerpc/pseries: Fix clearing of security feature flags
- powerpc: Move default security feature flags
- powerpc/pseries: Restore default security feature flags on setup
- powerpc/64s: Add support for a store forwarding barrier at kernel
entry/exit
- SAUCE: powerpc/64s: Move the data access exception out-of-line
* CVE-2018-3639 (x86)
- arch: Introduce post-init read-only memory
- SAUCE: Add X86_FEATURE_ARCH_CAPABILITIES
- SAUCE: x86: Add alternative_msr_write
- x86/nospec: Simplify alternative_msr_write()
- x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
- x86/bugs: Concentrate bug detection into a separate function
- x86/bugs: Concentrate bug reporting into a separate function
- x86/msr: Add definitions for new speculation control MSRs
- x86/bugs: Read SPEC_CTRL MSR during boot and re-use reserved bits
- x86/bugs, KVM: Support the combination of guest and host IBRS
- x86/bugs: Expose /sys/../spec_store_bypass
- x86/cpufeatures: Add X86_FEATURE_RDS
- x86/bugs: Provide boot parameters for the spec_store_bypass_disable
mitigation
- x86/bugs/intel: Set proper CPU features and setup RDS
- x86/bugs: Whitelist allowed SPEC_CTRL MSR values
- x86/bugs/AMD: Add support to disable RDS on Fam[15,16,17]h if requested
- x86/KVM/VMX: Expose SPEC_CTRL Bit(2) to the guest
- x86/speculation: Create spec-ctrl.h to avoid include hell
- prctl: Add speculation control prctls
- x86/process: Allow runtime control of Speculative Store Bypass
- x86/speculation: Add prctl for Speculative Store Bypass mitigation
- nospec: Allow getting/setting on non-current task
- proc: Provide details on speculation flaw mitigations
- seccomp: Enable speculation flaw mitigations
- SAUCE: x86/bugs: Honour SPEC_CTRL default
- x86/bugs: Make boot modes __ro_after_init
- prctl: Add force disable speculation
- seccomp: Use PR_SPEC_FORCE_DISABLE
- seccomp: Add filter flag to opt-out of SSB mitigation
- seccomp: Move speculation migitation control to arch code
- x86/speculation: Make "seccomp" the default mode for Speculative Store
Bypass
- x86/bugs: Rename _RDS to _SSBD
- proc: Use underscores for SSBD in 'status'
- Documentation/spec_ctrl: Do some minor cleanups
- x86/bugs: Fix __ssb_select_mitigation() return type
- x86/bugs: Make cpu_show_common() static
linux (3.13.0-148.197) trusty; urgency=medium
* linux: 3.13.0-148.197 -proposed tracker (LP: #1769077)
* CVE-2017-18208
- mm/madvise.c: fix madvise() infinite loop under special circumstances
* CVE-2018-8822
- staging: ncpfs: memory corruption in ncp_read_kernel()
* CVE-2017-18221
- mlock: fix mlock count can not decrease in race condition
* CVE-2017-12134
- xen: fix bio vec merging
* CVE-2017-18203
- dm: fix race between dm_get_from_kobject() and __dm_destroy()
* CVE-2017-17449
- netlink: Add netns check on taps
* CVE-2017-13220
- Bluetooth: hidp_connection_add() unsafe use of l2cap_pi()
* CVE-2017-18204
- ocfs2: should wait dio before inode lock in ocfs2_setattr()
* CVE-2017-13305
- KEYS: encrypted: fix buffer overread in valid_master_desc()
* CVE-2017-18079
- Input: i8042 - fix crash at boot time
* "ip a" command on a guest VM shows UNKNOWN status (LP: #1761534)
- virtio-net: Fix operstate for virtio when no VIRTIO_NET_F_STATUS
* ibrs/ibpb fixes result in excessive kernel logging (LP: #1755627)
- SAUCE: remove ibrs_dump sysctl interface
-- Stefan Bader <stefan.ba...@canonical.com> Mon, 14 May 2018 16:58:50
+0200
** Changed in: linux (Ubuntu Xenial)
Status: Fix Committed => Fix Released
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-16995
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-17862
** CVE added: https://cve.mitre.org/cgi-
bin/cvename.cgi?name=2018-1000004
--
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/1755627
Title:
ibrs/ibpb fixes result in excessive kernel logging
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Trusty:
Fix Released
Status in linux source package in Xenial:
Fix Released
Status in linux source package in Artful:
Fix Released
Bug description:
Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
results in kernel logs similar to the following:
% sysctl -a &>/dev/null; dmesg -T | tail -8
[Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
The output varies with the number of CPUs.
After digging a bit, it turns out this is triggered upon every read of
`kernel.ibrs_dump`:
% for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo;
sleep 1; done
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic
4.4.98 per /proc/version_signature
Normally this would not be the biggest concern but we have tooling
that gathers instance info on a schedule, including sysctl output,
thus resulting in the kernel ring buffer being full of nothing but
said output in most cases and hindering live troubleshooting as a
result.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+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
