Description of problem:
Steps to Reproduce:
Updated kernel-rt provides upstream 3.12.18 kernel and fixes the following
Buffer overflow in the complete_emulated_mmio function in arch/x86/kvm/
x86.c in the Linux kernel before 3.13.6 allows guest OS users to execute
arbitrary code on the host OS by leveraging a loop that triggers an
invalid memory copy affecting certain cancel_work_item data.
The get_rx_bufs function in drivers/vhost/net.c in the vhost-net subsystem
in the Linux kernel package before 2.6.32-431.11.2 on Red Hat Enterprise
Linux (RHEL) 6 does not properly handle vhost_get_vq_desc errors, which
allows guest OS users to cause a denial of service (host OS crash) via
unspecified vectors. (CVE-2014-0055)
The cifs_iovec_write function in fs/cifs/file.c in the Linux kernel through
3.13.5 does not properly handle uncached write operations that copy fewer
than the requested number of bytes, which allows local users to obtain
sensitive information from kernel memory, cause a denial of service
(memory corruption and system crash), or possibly gain privileges via a
writev system call with a crafted pointer. (CVE-2014-0069)
drivers/vhost/net.c in the Linux kernel before 3.13.10, when mergeable
buffers are disabled, does not properly validate packet lengths, which
allows guest OS users to cause a denial of service (memory corruption and
host OS crash) or possibly gain privileges on the host OS via crafted
packets, related to the handle_rx and get_rx_bufs functions.
Integer overflow in the ping_init_sock function in net/ipv4/ping.c in the
Linux kernel through 3.14.1 allows local users to cause a denial of service
(use-after-free and system crash) or possibly gain privileges via a crafted
application that leverages an improperly managed reference counter.
Oter fixes in this update:
- switch hugepages back to madvise to fix performance regression (mga#12994)
- enable Intel P-state driver (mga#13080)
- fix r8169 suspend/resume issue (mga#13255)
- RT patch has been updated to -rt25
For upstream merged fixes, read the referenced changelogs:
On real hardware, M4, KDE, 32-bit
Package(s) under test:
install kernel-rt from updates_testing
[wilcal@localhost ~]$ uname -a
Linux localhost 3.12.18-0.rt25.1.mga4 #1 SMP PREEMPT RT Thu Apr 24 16:27:21 UTC 2014 i686 i686 i686 GNU/Linux
kernel-rt boots to a working desktop and applications work fine
Intel, P4 530J 3.0 GHz, 800MHz FSB, 1MB L2, LGA 775
GigaByte GA-81915G Pro F4 i915G LGA 775 MoBo
Marvel Yukon 88E8001 Gigabit LAN
Intel High Def Audio, Azalia (C-Media 9880) (snd-hda-intel)
Intel Graphics Media Accelerator 900 (Intel 82915G)
Kingston 4GB (2 x 2GB) DDR400 PC-3200
Kingwin KF-91-BK SATA Mobile Rack
Kingwin KF-91-T-BK SATA Mobile Rack Tray
Sony CD/DVD-RW DWQ120AB2
Trying MGA4 64-bit real hardware with ATI/Radeon graphics
Not a success. The first time I tried this it displayed (sort of) "Sorry, cannot configure the graphics. When given a login prompt, log in as root and run drakx11". Having fought my way through that, it dowloaded piles of stuff, ? compiled something, and ended saying "Re-start".
Subsequently, it always goes (twice) to the console error msg. Running drakx11 seems to work, but ends "Re-start" - which leads to the same thing.
So I never got this one to fly.
With these alternate kernels it needs to use the dkms driver packages, which build themselves on first boot with the new kernel. Because they do this it's necessary to install the relevant kernel devel package along with the kernel.
The main kernel (eg. kernel-desktop, kernel-server) have prebuilt (kmod) driver packages for the matching kernel in the matching version available.
(In reply to claire robinson from comment #4)
> With these alternate kernels it needs to use the dkms driver packages, which
> build themselves on first boot with the new kernel. Because they do this
> it's necessary to install the relevant kernel devel package along with the
Could not this be achieved by making the development kernels requirements of the relevant kernels?
Trying MGA4 64-bit real hardware with ATI/Radeon graphics
the kernel loaded OK in the end and basically works.
SWAP is not functioning. Whether this is new to 3.12.18 (after 3.12.13) I know not; with 4Gb RAM, SWAP is never used. I just noticed it for these kernel tests:
- Esc to see the startup console O/P shows up "FAIL to activate swap on /dev/sda7".
- dmesg includes "Adding swap on /dev/sda7"; but not the error msg above.
- No swap entry in mount O/P.
- swapon -s shows /dev/sda7 but Used = 0.
This happens also with kernels desktop and tmb-desktop.
It is clear that swap *is* ultimately active. It seems that one attempt visible on the console genuinely fails, and a later attempt visible via dmesg works. The swapon -s output indicates that swap is active, but not being used (in error I took the Used = 0 as a binary flag!).
So the only problem is "why the initial failure"? (The line is in red).
To be persued.
dkms-nvidia-current build failed on release kernel-rt (bad exit status 10). It tried again after the reboot and failed again.
It also failed when installing the update and after the reboot.
Removed and reinstalled dkms-nvidia-current to rule out bug 10771 but it still fails.
I'm guessing this is probably due to having the kernel-source package installed before the kernel-devel package which we previously found caused this problem
although I didn't have kernel-source from updates_testing installed, only previously the release kernel-source.
Was the fix missed or just unable to fix on an affected system?
it's the nvidia-current driver that does not like the -rt kernel
The kernel you are installing for is a PREEMPT_RT kernel!
The NVIDIA driver does not support real-time kernels. If you
are using a stock distribution kernel, please install
a variant of this kernel that does not have the PREEMPT_RT
patch set applied; if this is a custom kernel, please
install a standard Linux kernel. Then try installing the
NVIDIA kernel module again.
*** Failed PREEMPT_RT sanity check. Bailing out! ***
seems I'll have to revive the old rt patch we had way back if we want this to work
But it's not a blocker for this update, its more of a nvidia-current one, but that will be a separate update
Is it possible to stop it trying to build on rt, if it's not designed to?
It won't affect anybody updating, with it not installing on release or update so I'm happy to validate.
nope, the only thing would be a conflict, but that would enforce a removal of either kernel-rt or kvidia-current, and none of them is really a good option
yeah, it's ok to validate, and I'll look into making it work with later drivers
Validating. Advisory uploaded.
Could sysadmin please push to 4 updates