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: SRPMS: kernel-linus-3.12.9-1.mga4.src.rpm i586: kernel-linus-3.12.9-1.mga4-1-1.mga4.i586.rpm kernel-linus-devel-3.12.9-1.mga4-1-1.mga4.i586.rpm kernel-linus-devel-latest-3.12.9-1.mga4.i586.rpm kernel-linus-doc-3.12.9-1.mga4.noarch.rpm kernel-linus-latest-3.12.9-1.mga4.i586.rpm kernel-linus-source-3.12.9-1.mga4-1-1.mga4.noarch.rpm kernel-linus-source-latest-3.12.9-1.mga4.noarch.rpm x86_64: kernel-linus-3.12.9-1.mga4-1-1.mga4.x86_64.rpm kernel-linus-devel-3.12.9-1.mga4-1-1.mga4.x86_64.rpm kernel-linus-devel-latest-3.12.9-1.mga4.x86_64.rpm kernel-linus-doc-3.12.9-1.mga4.noarch.rpm kernel-linus-latest-3.12.9-1.mga4.x86_64.rpm kernel-linus-source-3.12.9-1.mga4-1-1.mga4.noarch.rpm kernel-linus-source-latest-3.12.9-1.mga4.noarch.rpm Reproducible: Steps to Reproduce:
i586 virtualbox, installs and boots fine to X. Nothing tested beyond.
CC: (none) => stormi
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 ". . . . ."
Advisory: 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) For other changes, see the referenced changelog: References: https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.12.9
x86_64 on Hyper-V. Installs and boots to X without issue. All HV modules are listed as enabled and do seem to be working. MGA4-64-OK
CC: (none) => dpremy
Whiteboard: (none) => MGA4-64-OK
<shlomif> MrsB: OK, kernel-linus seems to be working here - KDE 4 works, desktop effects, VLC (video+audio), wifi , IRC, ssh, etc. <shlomif> I don't expect too many surprises from Linux kernels which, from my experience, even their -pre* releases are very functional and stable. My laptop's specs are (Tested on live hardware): <<<<<<<<<<<<<<< I also have an Acer Aspire 5738DZG laptop with the following specs: Intel Pentium(R) Dual-Core CPU T4300 @ 2.10GHz. (x86-64). ATI Mobility Radeon⢠HD 4570 (r700) 15.6×´ 3D HD LCD Screen. 3 GB Memory 320 GB Hard Disk Drive. âDVD Super Multi DL driveâ Acer Nplify⢠802.11b/g/n. >>>>>>>>>>>>>>>
CC: (none) => shlomif
Whiteboard: MGA4-64-OK => MGA4-64-OK MGA4-32-OK
Validating update. Advisory uploaded, could a sysadmin push the update to core/updates for Mageia 4? Thanks!
Keywords: (none) => validated_updateWhiteboard: MGA4-64-OK MGA4-32-OK => MGA4-64-OK MGA4-32-OK advisoryCC: (none) => remi, sysadmin-bugs
Update pushed: http://advisories.mageia.org/MGASA-2014-0061.html
Status: NEW => RESOLVEDResolution: (none) => FIXED