Bug 12524 - Update request: kernel-rt-3.12.9-0.rt13.1.mga4
: Update request: kernel-rt-3.12.9-0.rt13.1.mga4
Product: Mageia
Classification: Unclassified
Component: Security
: 4
: All Linux
: Normal Severity: critical
: ---
Assigned To: QA Team
: Sec team
: MGA4-32-OK advisory MGA4-64-OK
: validated_update
  Show dependency treegraph
Reported: 2014-02-02 15:22 CET by Thomas Backlund
Modified: 2014-02-13 09:12 CET (History)
3 users (show)

See Also:
Source RPM: kernel-rt-3.12.9-0.rt13.1.mga4
Status comment:

dkms install log (37.07 KB, text/x-log)
2014-02-11 16:26 CET, Samuel Verschelde

Description Thomas Backlund 2014-02-02 15:22:39 CET
Now this is mostly for squashing the recently announced critical:

x86, x32: Correct invalid use of user timespec in the kernel (CVE-2014-0038)

I will write a better advisory tomorrow, but so you can start testing:





Steps to Reproduce:
Comment 1 Samuel Verschelde 2014-02-05 17:54:26 CET
i586 virtualbox, installs and boots fine to X. Nothing tested beyond.
Comment 2 claire robinson 2014-02-06 13:59:24 CET
When testing these alternative kernels (-linus, -rt, -tmb, -vserver) it is necessary to use the dkms driver packages, dkms-nvidia* and dkms-fglrx etc. rather than the pre-built kmod packages such as nvidia-current-kernel-desktop-latest.

Pre-built kmod packages only support the specific kernel they are built for, which forms part of the package name.

Dkms packages actually build the driver on the next boot for whichever kernel you are using. It means the first boot after installing the new kernel will take longer than expected. Allow it to complete, normally a minute or couple of minutes, depending on your hardware. You can see it building if you remove "splash quiet" options from the kernel command line or press escape as it boots so you can see the text. It shows and a series of dots ". . . . ."
Comment 3 Thomas Backlund 2014-02-06 19:29:22 CET
  This kernel update provides an update to 3.12.9 and fixes the following
  critical security issue:

  Pageexec reported a bug in the Linux kernel's recvmmsg syscall when called
  from code using the x32 ABI. An unprivileged local user could exploit this
  flaw to cause a denial of service (system crash) or gain administrator
  privileges (CVE-2014-0038)

  The -rt patch has been updated to -rt11.

  For other changes, see the referenced changelog:

Comment 4 Bill Wilkinson 2014-02-09 03:39:50 CET
Kernel did not boot--no further disk activity after initial (vmlinuz?--it disappears quickly) image command.  Screen blanks and no further activity.
Comment 5 Samuel Verschelde 2014-02-09 13:38:00 CET
(In reply to Bill Wilkinson from comment #4)
> Kernel did not boot--no further disk activity after initial (vmlinuz?--it
> disappears quickly) image command.  Screen blanks and no further activity.

Does the one from core/release boot?
Comment 6 Bill Wilkinson 2014-02-09 15:27:20 CET

The release kernel boots to the login screen, but does not completely start KDE. I haven't tried with other desktops.
Comment 7 Thomas Backlund 2014-02-09 23:45:19 CET
Seems there were some issues with upstream -rt11, wich should be fixed in -rt13,
so rpms for test are now:



Comment 8 Samuel Verschelde 2014-02-11 16:25:33 CET
After installing the devel package, I tried some brutal testing approach regarding dkms:

# rpm -qa | grep dkms | xargs urpme
# urpmq dkms- -Y | xargs urpmi > dkms.log 2>&1

It installs all the dkms packages we have. Most of them are ok but I get error messages. If they're not related to kernel-rt (nvidia-current is), I guess I'll have to open bug reports against those dkms packages, but I'd like a confirmation.

Full log attached.

If someone wants to do the same, I detected the failed builds with:
$ cat dkms.log | grep "for more information"

List of the failed builds:

--- dkms-em8300
cc1: erreur fatale: /lib/modules/3.12.9-0.rt13.1.mga4/build/include/linux/version.h : No such file or directory

--- dkms-zd1211
/var/lib/dkms/zd1211/ erreur fatale: linux/config.h : No such file or directory

--- dkms-lzma
/var/lib/dkms/lzma/4.43-34.mga4/build/uncomp.c:64:4: erreur: implicit declaration of function âkfreeâ [-Werror=implicit-function-declaration]

--- dkms-syntek
/var/lib/dkms/syntek/3.0.0-4.mga4/build/stk11xx-v4l.c: In function âv4l_stk11xx_register_video_deviceâ:
/var/lib/dkms/syntek/3.0.0-4.mga4/build/stk11xx-v4l.c:1503:11: erreur: âstruct video_deviceâ has no member named âparentâ

--- dkms-fsam7400
/var/lib/dkms/fsam7400/0.5.2-3.mga4/build/fsam7400.c: In function âcommon_proc_initâ:
/var/lib/dkms/fsam7400/0.5.2-3.mga4/build/fsam7400.c:331:4: erreur: implicit declaration of function âcreate_proc_entryâ [-Werror=implicit-function-declaration]

--- dkms-lirc-extra
/var/lib/dkms/lirc-extra/0.9.0-10.1.mga4/build/drivers/lirc_wpc8769l/lirc_wpc8769l.c: In function âirq_handlerâ:
/var/lib/dkms/lirc-extra/0.9.0-10.1.mga4/build/drivers/lirc_wpc8769l/lirc_wpc8769l.c:364:3: erreur: implicit declaration of function âgeneric_find_next_le_bitâ [-Werror=implicit-function-declaration]

--- dkms-libafs
config.status: error: cannot find input file: `Makefile.in'

--- dkms-ipt_NETFLOW
make[1]: *** No rule to make target '/var/lib/dkms/ipt_NETFLOW/1.8-4.mga4/build/Makefile'.

--- dkms-nvidia-current
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! ***
Comment 9 Samuel Verschelde 2014-02-11 16:26:21 CET
Created attachment 4976 [details]
dkms install log
Comment 10 Samuel Verschelde 2014-02-11 17:09:47 CET
FYI with the same version kernel-vserver, the same builds fail, except:
- dkms-libafs
- dkms-nvidia-current

There's one more, dkms-acpi_call, but I think it failed too with kernel-rt (I didn't follow exactly my own procedure, I installed it there before all the others)
Comment 11 Thomas Backlund 2014-02-11 17:15:21 CET
Well, all of those dkms errors are specific to the dkms package in question, most of them simply are not updated / fixed to work with 3.12 series kernels.

the issue between -rt kernel and nvidia-current is a nvidia-current we used to have a special patch in nvidia-current that I seem to have dropped between upgrades/downgrades mess :/

I will restore it when I push nvidia-331.38 to updates_testing as we can switch back to that driver now when the real cause for the nvidia app hang has been found.

So theese dkms issues does not prevent the validation of this kernel as it's not at fault, the broken dkms-* ones need to be fixed or dropped.

for -vserver kernel, we usually dont let dkms problems block validation, as it's a special kernel for server installs where you dont really use any dkms packages...

If I can fix it to work for both "normal" and vserver kernels I do, but if I have to choose, its more important that the "normal" kernels works...
Comment 12 Samuel Verschelde 2014-02-11 17:17:42 CET
Thanks Thomas. Testing mga4 i586 complete.
Comment 13 Rémi Verschelde 2014-02-11 17:18:36 CET
(In reply to Samuel VERSCHELDE from comment #10)
> There's one more, dkms-acpi_call, but I think it failed too with kernel-rt
> (I didn't follow exactly my own procedure, I installed it there before all
> the others)

dkms-acpi_call probably does not build on any kernel, AFAIU it has been deprecated by bbswitch. I still have to clean it up though, it was a Requires of bumblebee when Simple imported it.
Comment 14 Samuel Verschelde 2014-02-12 11:26:44 CET
Advisory uploaded.
Comment 15 Samuel Verschelde 2014-02-12 21:02:57 CET
Installing it on my real computer, apart from the nvidia module not building, it booted fine.
I don't know why, my KDE session wasn't restored: kmail, firefox and konsole were not started. I rebooted into the desktop kernel with "reboot" so that KDE doesn't save that new empty session, and after reboot I get all my apps restored as usual.

I'll try kernel-rt from release and see if it's the same.
Comment 16 Samuel Verschelde 2014-02-12 22:02:38 CET
The weird behaviour with KDE session not restoring opened apps is there with kernel-tmb too and kernel-rt from release, so not a regression. Might occur when the nvidia driver isn't running, maybe.

One question not directly related to this update: what could cause the nouveau driver to load on kernel-tmb-desktop instead of nvidia, whereas kernel-desktop loads nvidia... dkms-nvidia built the module for both of them. Is that something you'd like to dig, tmb?

Regarding kernel-rt, testing mga4 64 complete.

Update validated, advisory already uploaded.

Please push to 4/core/updates
Comment 17 Thomas Backlund 2014-02-12 23:54:34 CET
Update pushed:
Comment 18 claire robinson 2014-02-13 08:14:14 CET
It's possible the dkms nvidia actually failed to build. This is what we discovered earlier and occurs if there are kernel-source packages installed prior to installing the new kernel. The symlinks in /lib/modules/<kernel> are set incorrectly. If that's the case then it's an old drakx patch which has now been removed and the fix will be included in the next kernel updates.

Also, after defaulting to nouveau IINM it's necessary to manually change it back to nvidia with XFdrake. Configure the card and OK back to menu and it should offer to use/install the proprietary nvidia driver again.

dkms can also become messed up when kernels are removed, the dkms builds are not cleanly removed before kernel removal, which can cause issues if re-installing the same kernel again.

A workaround for that is to remove the dkms package and reinstall it (bug 10771)
Comment 19 Samuel Verschelde 2014-02-13 09:12:55 CET
The driver didn't fail to build (with kernel-tmb-desktop), the module is available but can't be loaded because nouveau is already in place, that's what I don't understand since with kernel-desktop nvidia is loaded instead of nouveau.

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