Description of problem: SRPMS: kernel-rt-3.12.18-0.rt25.1.mga4.src.rpm i586: kernel-rt-3.12.18-0.rt25.1.mga4-1-1.mga4.i586.rpm kernel-rt-devel-3.12.18-0.rt25.1.mga4-1-1.mga4.i586.rpm kernel-rt-devel-latest-3.12.18-0.rt25.1.mga4.i586.rpm kernel-rt-doc-3.12.18-0.rt25.1.mga4.noarch.rpm kernel-rt-latest-3.12.18-0.rt25.1.mga4.i586.rpm kernel-rt-source-3.12.18-0.rt25.1.mga4-1-1.mga4.noarch.rpm kernel-rt-source-latest-3.12.18-0.rt25.1.mga4.noarch.rpm x86_64: kernel-rt-3.12.18-0.rt25.1.mga4-1-1.mga4.x86_64.rpm kernel-rt-devel-3.12.18-0.rt25.1.mga4-1-1.mga4.x86_64.rpm kernel-rt-devel-latest-3.12.18-0.rt25.1.mga4.x86_64.rpm kernel-rt-doc-3.12.18-0.rt25.1.mga4.noarch.rpm kernel-rt-latest-3.12.18-0.rt25.1.mga4.x86_64.rpm kernel-rt-source-3.12.18-0.rt25.1.mga4-1-1.mga4.noarch.rpm kernel-rt-source-latest-3.12.18-0.rt25.1.mga4.noarch.rpm Reproducible: Steps to Reproduce:
Advisory: Updated kernel-rt provides upstream 3.12.18 kernel and fixes the following security issues: 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. (CVE-2014-0049) 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. (CVE-2014-0077) 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. (CVE-2014-2851) 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: References: https://bugs.mageia.org/show_bug.cgi?id=12994 https://bugs.mageia.org/show_bug.cgi?id=13080 https://bugs.mageia.org/show_bug.cgi?id=13255 https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.12.18 https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.12.17 https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.12.16 https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.12.15 https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.12.14
On real hardware, M4, KDE, 32-bit Package(s) under test: kernel-rt 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 Test platform: 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 250GB Seagate Kingwin KF-91-BK SATA Mobile Rack Kingwin KF-91-T-BK SATA Mobile Rack Tray Sony CD/DVD-RW DWQ120AB2
CC: (none) => wilcal.int
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.
CC: (none) => lewyssmith
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 > kernel. 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 After adding kernel-tmb-desktop-devel-3.12.18-1.mga4-1-1.mga4.x86_64.rpm the kernel loaded OK in the end and basically works. BUT Problem. 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 https://bugs.mageia.org/show_bug.cgi?id=12524#c18 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?
Nope, it's the nvidia-current driver that does not like the -rt kernel form make.log: 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
Whiteboard: (none) => mga4-32-ok mga4-64-ok
Validating. Advisory uploaded. Could sysadmin please push to 4 updates Thanks
Keywords: (none) => validated_updateWhiteboard: mga4-32-ok mga4-64-ok => advisory mga4-32-ok mga4-64-okCC: (none) => sysadmin-bugs
Update pushed: http://advisories.mageia.org/MGASA-2014-0208.html
Status: NEW => RESOLVEDResolution: (none) => FIXED