Bug 13267 - Update request: kernel-rt-3.12.18-0.rt25.1.mga4
: Update request: kernel-rt-3.12.18-0.rt25.1.mga4
Product: Mageia
Classification: Unclassified
Component: Security
: 4
: All Linux
: Normal Severity: normal
: ---
Assigned To: QA Team
: Sec team
: advisory mga4-32-ok mga4-64-ok
: validated_update
  Show dependency treegraph
Reported: 2014-04-24 20:18 CEST by Thomas Backlund
Modified: 2014-05-09 00:04 CEST (History)
3 users (show)

See Also:
Source RPM: kernel-rt-3.12.18-0.rt25.1.mga4.src.rpm


Description Thomas Backlund 2014-04-24 20:18:44 CEST
Description of problem:





Steps to Reproduce:
Comment 1 Thomas Backlund 2014-04-24 20:43:37 CEST
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. 

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:

Comment 2 William Kenney 2014-04-27 19:31:54 CEST
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

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
Comment 3 Lewis Smith 2014-04-29 18:58:50 CEST
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.
Comment 4 claire robinson 2014-04-29 19:12:21 CEST
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.
Comment 5 Lewis Smith 2014-04-30 21:49:07 CEST
(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?
Comment 6 Lewis Smith 2014-05-01 20:11:22 CEST
Trying MGA4 64-bit real hardware with ATI/Radeon graphics
After adding
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.
Comment 7 Lewis Smith 2014-05-02 18:18:29 CEST
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.
Comment 8 claire robinson 2014-05-07 19:10:22 CEST
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?
Comment 9 Thomas Backlund 2014-05-07 19:28:59 CEST
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
Comment 10 claire robinson 2014-05-07 19:32:00 CEST
Is it possible to stop it trying to build on rt, if it's not designed to?
Comment 11 claire robinson 2014-05-07 19:33:52 CEST
It won't affect anybody updating, with it not installing on release or update so I'm happy to validate.
Comment 12 Thomas Backlund 2014-05-07 19:35:59 CEST
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
Comment 13 claire robinson 2014-05-08 17:46:12 CEST
Validating. Advisory uploaded.

Could sysadmin please push to 4 updates

Comment 14 Thomas Backlund 2014-05-09 00:04:15 CEST
Update pushed:

Note You need to log in before you can comment on or make changes to this bug.