"Mad COW" kernels + other fixes SRPM: kernel-linus-4.4.26-1.mga5.src.rpm i586: kernel-linus-4.4.26-1.mga5-1-1.mga5.i586.rpm kernel-linus-devel-4.4.26-1.mga5-1-1.mga5.i586.rpm kernel-linus-devel-latest-4.4.26-1.mga5.i586.rpm kernel-linus-doc-4.4.26-1.mga5.noarch.rpm kernel-linus-latest-4.4.26-1.mga5.i586.rpm kernel-linus-source-4.4.26-1.mga5-1-1.mga5.noarch.rpm kernel-linus-source-latest-4.4.26-1.mga5.noarch.rpm x86_64: kernel-linus-4.4.26-1.mga5-1-1.mga5.x86_64.rpm kernel-linus-devel-4.4.26-1.mga5-1-1.mga5.x86_64.rpm kernel-linus-devel-latest-4.4.26-1.mga5.x86_64.rpm kernel-linus-doc-4.4.26-1.mga5.noarch.rpm kernel-linus-latest-4.4.26-1.mga5.x86_64.rpm kernel-linus-source-4.4.26-1.mga5-1-1.mga5.noarch.rpm kernel-linus-source-latest-4.4.26-1.mga5.noarch.rpm Advisory: This update is based on the upstream 4.4.26 kernel and fixes atleast theese security issues: An issue with ASN.1 DER decoder was reported that could lead to memory corruptions, possible privilege escalation, or complete local denial of service via x509 certificate DER files (CVE-2016-0758). sound/core/timer.c in the Linux kernel through 4.6 does not initialize certain r1 data structures, which allows local users to obtain sensitive information from kernel stack memory via crafted use of the ALSA timer interface, related to the (1) snd_timer_user_ccallback and (2) snd_timer_user_tinterrupt functions (CVE-2016-4578). A race condition was found in the way the Linux kernel's memory subsystem handled the copy-on-write (COW) breakage of private read-only memory mappings. An unprivileged local user could use this flaw to gain write access to otherwise read-only memory mappings and thus increase their privileges on the system. This could be abused by an attacker to modify existing setuid files with instructions to elevate privileges. An exploit using this technique has been found in the wild (CVE-2016-5195). The tipc_nl_compat_link_dump function in net/tipc/netlink_compat.c in the Linux kernel through 4.6.3 does not properly copy a certain string, which allows local users to obtain sensitive information from kernel stack memory by reading a Netlink message (CVE-2016-5243). The rds_inc_info_copy function in net/rds/recv.c in the Linux kernel through 4.6.3 does not initialize a certain structure member, which allows remote attackers to obtain sensitive information from kernel stack memory by reading an RDS message (CVE-2016-5244). Memory leak in the airspy_probe function in drivers/media/usb/airspy/airspy.c in the airspy USB driver in the Linux kernel before 4.7 allows local users to cause a denial of service (memory consumption) via a crafted USB device that emulates many VFL_TYPE_SDR or VFL_TYPE_SUBDEV devices and performs many connect and disconnect operations (CVE-2016-5400). A flaw was found in the implementation of the Linux kernel handling of networking challenge ack where an attacker is able to determine the shared counter. This may allow an attacker to inject or take over a TCP connection between a server and client without having to be a traditional Man In the Middle (MITM) style attack (CVE-2016-5696). Race condition in the ioctl_send_fib function in drivers/scsi/aacraid/ commctrl.c in the Linux kernel through 4.7 allows local users to cause a denial of service (out-of-bounds access or system crash) by changing a certain size value, aka a "double fetch" vulnerability (CVE-2016-6480). Marco Grassi discovered a use-after-free condition could occur in the TCP retransmit queue handling code in the Linux kernel. A local attacker could use this to cause a denial of service (system crash) or possibly execute arbitrary code. (CVE-2016-6828) Vladimir Bene discovered an unbounded recursion in the VLAN and TEB Generic Receive Offload (GRO) processing implementations in the Linux kernel, A remote attacker could use this to cause a stack corruption, leading to a denial of service (system crash). (CVE-2016-7039) This update also changes the following: - enables STRICT_DEVMEM as a security hardening - disables FW_LOADER_USER_HELPER_FALLBACK again (un-intentionally enabled in 4.4 series upgrade) that slows down boot or even makes wireless connection fail with drivers with multiple possible firmwares (mga#19390). For other fixes in this update, see the referenced changelogs. References: https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.17 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.18 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.19 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.20 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.21 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.22 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.23 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.24 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.25 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.26
Priority: Normal => High
Testing Mageia 5 x64 real hardware with AMD/ATI/Radeon graphics I installed this kernel directly from Updates Testing (alongside the equivalent Desktop 4.4.26 kernel used up to that point): kernel-desktop-4.4.26-1.mga5-1-1.mga5 kernel-desktop-latest-4.4.26-1.mga5 kernel-linus-4.4.26-1.mga5-1-1.mga5 kernel-linus-latest-4.4.26-1.mga5 kernel-userspace-headers-4.4.26-1.mga5 Grub must have been re-built during that process. After re-boot, selecting the default main menu top Mageia entry did *not* apparently boot into the Linus kernel, but still the Desktop one. Re-booting to the "advanced options" Grub2 sub-menu (excluding superfluous bits): Mageia with Linux Desktop Mageia with Linux Desktop 4.4.26-desktop-1.mga5 Mageia with Linux 4.4.26-1.mga5 But why was the latest installed kernel not the top of the list, the default to boot? I deduce that the last entry above is the Linus kernel; and why (perhaps) the Desktop one remains the default: because bare 'vmlinuz' points to it: $ ls -l /boot [trimmed] -rw-r--r-- 1 root root 11553586 Hyd 24 09:57 initrd-4.4.26-1.mga5.img -rw-r--r-- 1 root root 11555028 Hyd 21 19:58 initrd-4.4.26-desktop-1.mga5.img lrwxrwxrwx 1 root root 32 Hyd 21 20:08 initrd-desktop.img -> initrd-4.4.26-desktop-1.mga5.img lrwxrwxrwx 1 root root 32 Hyd 21 20:08 initrd.img -> initrd-4.4.26-desktop-1.mga5.img lrwxrwxrwx 1 root root 24 Hyd 24 10:07 initrd-linus.img -> initrd-4.4.26-1.mga5.img lrwxrwxrwx 1 root root 29 Hyd 21 20:08 vmlinuz -> vmlinuz-4.4.26-desktop-1.mga5 -rw-r--r-- 1 root root 4465424 Hyd 20 21:28 vmlinuz-4.4.26-1.mga5 -rw-r--r-- 1 root root 4464416 Hyd 20 11:35 vmlinuz-4.4.26-desktop-1.mga5 lrwxrwxrwx 1 root root 29 Hyd 21 20:08 vmlinuz-desktop -> vmlinuz-4.4.26-desktop-1.mga5 lrwxrwxrwx 1 root root 21 Hyd 24 10:07 vmlinuz-linus -> vmlinuz-4.4.26-1.mga5 and specifically selecting it, booted normally: $ uname -r 4.4.26-1.mga5 and I suppose that I am actually using it. Sound on my box seems better with the 4.4.26 kernel; that was an issue for some people with earlier recent ones. I will regard this kernel as OK unless something negative happens.
CC: (none) => lewyssmith
(In reply to Lewis Smith from comment #1) > But why was the latest installed kernel not the top of the list, the default > to boot? I deduce that the last entry above is the Linus kernel; and why > (perhaps) the Desktop one remains the default: because bare 'vmlinuz' points > to it: Yep. It was decided "ages ago (actually already in mdv days)" that "contrib" kernels should not override the "core ("main")" kernel links. Those who want to run "contrib" kernels by default can change default kernel entry to use the matching symlinks.
Tested on an x86-64 vbox installation of Mageia 5 x86-64 . The kernel boots fine and loads Xfce, but the viewport's resolution is very small and does not get resized. Seems like there's a problem with the VirtualBox's guest additions.
CC: (none) => shlomif
X86_64 version tested on real hardware, Athlon X2 7750 processor, 8GB RAM, nvidia graphics using 340 driver. Installed directly from the testing repositories. Packages included x86_64 versions of kernel, kernel-development, and "latest" of each of those. With Legacy grub, kernel entry is appended to the end of the list. Booting from that, all goes smoothly. Common apps work, including VirtualBox 5.1.8. and Firefox. No regressions noted.
CC: (none) => andrewsfarm
(In reply to Thomas Andrews from comment #4) > X86_64 version tested on real hardware, Athlon X2 7750 processor, 8GB RAM, > nvidia graphics using 340 driver. > > Installed directly from the testing repositories. Packages included x86_64 > versions of kernel, kernel-development, and "latest" of each of those. > > Not sure if this is a bug or normal behavior, but when I selected the above kernel and kernel-development packages, neither of the "latest" packages was flagged as a requirement. I had to select them manually. I had thought this might be normal behavior for this special kernel, until I went to install the tmb kernel packages and they DID flag the "latest" packages as requirements.
X86_64 version tested on real hardware, Intel i3 processor, Intel graphics, 4GB RAM. Same results as reported in comment 4 and comment 5.
Installed on x86_64 real hardware with nvidia graphics, Intel i7, 16 GB RAM. Rebooting now; shall let it run a while.
CC: (none) => tarazed25
I have my doubts about this installation. The linus kernel could not be identified from the screen options at reboot; all have "desktop" in the title. Selected the third entry: Mageia with Linux Desktop 4.4.26 None of the files in /boot have the datestamp for today. ?? # ls -l vmlinuz* | grep -v 2015 lrwxrwxrwx 1 root root 29 Oct 20 23:33 vmlinuz -> vmlinuz-4.4.26-desktop-1.mga5 -rw-r--r-- 1 root root 4433392 Jan 20 2016 vmlinuz-4.1.15-desktop-2.mga5 -rw-r--r-- 1 root root 4466352 Jun 10 13:19 vmlinuz-4.4.13-desktop-1.mga5 -rw-r--r-- 1 root root 4467184 Jul 26 10:29 vmlinuz-4.4.16-desktop-1.mga5 -rw-r--r-- 1 root root 4469232 Sep 24 21:26 vmlinuz-4.4.22-desktop-1.mga5 -rw-r--r-- 1 root root 4464416 Oct 20 10:35 vmlinuz-4.4.26-desktop-1.mga5 -rw-r--r-- 1 root root 4462240 May 3 21:45 vmlinuz-4.4.9-desktop-1.mga5 lrwxrwxrwx 1 root root 29 Oct 20 23:33 vmlinuz-desktop -> vmlinuz-4.4.26-desktop-1.mga5
(In reply to Len Lawrence from comment #8) > I have my doubts about this installation. The linus kernel could not be > identified from the screen options at reboot; all have "desktop" in the > title. That happened to me some months ago. IIRC on that occasion, re-installing the relevant kernel package fixed the problem. I suspect that for some reason, the kernel install script sometimes stops before it has completed. With this kernel on mga5-64 I had no such problem, The Advance Options in the Grub2 menu included "Mageia with linux-4.4.26-1" and I have $ ls -ll /boot | grep linus lrwxrwxrwx 1 root root 24 Oct 29 16:12 initrd-linus.img -> initrd-4.4.26-1.mga5.img lrwxrwxrwx 1 root root 21 Oct 29 16:12 vmlinuz-linus -> vmlinuz-4.4.26-1.mga5 $ uname -r 4.4.26-1.mga5
CC: (none) => jim
Thanks James. I thought that would have to be the next step. Leaving it until the tmb kernel has had a good workout.
On mag-32 installed - kernel-linus-4.4.26-1.mga5-1-1.mga5.i586 Selected "Mageia, with linux linus" from Grub2 Advanced Options menu $ uname -r 4.4.26-1.mga5 No regressions noted. OK for me on mga5-32
In VirtualBox, M5, KDE, 32-bit Package(s) under test: kernel-linus-latest install kernel-linus-latest from updates_testing [root@localhost wilcal]# uname -a Linux localhost.localdomain 4.4.26-1.mga5 #1 SMP Thu Oct 20 19:24:54 UTC 2016 i686 i686 i686 GNU/Linux [root@localhost wilcal]# urpmi kernel-linus-latest Package kernel-linus-latest-4.4.26-1.mga5.i586 is already installed System boots to a working desktop. Common apps work. Screen dimensions can be set to 1920x1080.
CC: (none) => wilcal.int
In VirtualBox, M5, KDE, 64-bit Package(s) under test: kernel-linus-latest install kernel-linus-latest from updates_testing [root@localhost wilcal]# uname -a Linux localhost.localdomain 4.4.26-desktop-1.mga5 #1 SMP Thu Oct 20 09:30:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [root@localhost wilcal]# urpmi kernel-linus-latest Package kernel-linus-latest-4.4.26-1.mga5.x86_64 is already installed System boots to a working desktop. Common apps work. Screen dimensions can be set to 1920x1080.
M5-64 real h/w Radeon video I used this for a couple of sessions with no problems (after Comment 1). After installing also the 'tmb' kernel, this one appeared in the Grub Advanced options sub- menu as 'linus'. This is OK for me.
Tried re-installing this on x86_64 hardware and this time it worked. And, notably, it also installed virtualbox stuff. It looks like the installation scripts or something are/is flaky. Sometimes they work, sometimes not. That is a bit worrying. The first time this was installed there did not seem to be much going on - see comment #9. The grub2 menu listed it as "Mageia with Linux 4.4.26" and uname gives 4.4.26-1.mga5 which looks like a positive identification. /boot contains the link vmlinuz-linus -> vmlinuz-4.4.26-1.mga5 Virtualbox 5.1.8 is working fine.
Having trouble with nvidia now whichever kernel I choose. nvidia is MIA and this is a typical report after running drakx11 to reinstall it: DKMS: install Completed. /sbin/ldconfig: /lib64/libguile-2.0.so.22.8.1-gdb.scm is not an ELF file - it has the wrong magic bytes at the start. ldconfig: /lib64/libguile-2.0.so.22.8.1-gdb.scm is not an ELF file - it has the wrong magic bytes at the start. removing installed rpms (dkms-nvidia-current-352.79-3.mga5.nonfree.x86_64.rpm x11-driver-video-nvidia-current-352.79-3.mga5.nonfree.x86_64.rpm nvidia-current-doc-html-352.79-3.mga5.nonfree.x86_64.rpm) from /var/cache/urpmi/rpms Not much point in rebooting when the installed rpms are removed already.
Investigating this further. The libguile .scm file is a script, written in Scheme and which provides GDB support for Guile. It looks like something has picked out the script by mistake instead of libguile which also resides in the lib64 directory. From the man pages for guile - GNU Guile is an interpreter for the Scheme programming language. If this is a bug I have no idea what to report it against, drakx11, dkms, ldconfig, .... One other thing, whichever kernel is being used, libafs fails to build at boot time. Reverted to the stock kernel again and that time it booted to the desktop with nvidia in place. Baffled.
Managed to reach the desktop with nvidia loaded. There was a "Failed to start openafs" during the boot. Could not get bluetooth to work - made sure that it was switched off on the host system. Apart from that everything looks OK.
this update works fine. Testing complete for MGA5, 32-bit & 64-bit Validating the update. Could someone from the sysadmin team push to updates. Thanks
Keywords: (none) => validated_updateWhiteboard: (none) => MGA5-32-OK MGA5-64-OKCC: (none) => sysadmin-bugs
Hi, please upload the advisory
CC: (none) => mageia
(In reply to Nicolas Lécureuil from comment #20) > please upload the advisory Done.
Whiteboard: MGA5-32-OK MGA5-64-OK => MGA5-32-OK MGA5-64-OK advisory
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGAA-2016-0134.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
BEWARE I did the advisory as an 'update' rather than 'security', so it is wrongly titled/classified and lacks the CVEs. I shall correct these immediately.