Now this is mostly for squashing the recently announced critical:
x86, x32: Correct invalid use of user timespec in the kernel (CVE-2014-0038)
but it also updates to 3.10.28 to squash a few more less critical secururity issues and other bugfixes like some laptop overheating reported by some with the 3.10.24 kernel.
I will write a better advisory tomorrow, but so you can start testing:
Steps to Reproduce:
When testing these alternative kernels (-linus, -rt, -tmb) 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 ". . . . ."
This one isn't booting to X for me currently. I'll investigate later.
P4 nvidia-current ivtv
Note that the advisory for this kernel-linus update is longer than others as we usually wait for CVE fixes to land in upstream released -stable.
This kernel update provides an update to the 3.10 longterm branch,
currently 3.10.28 and fixes the following security issues:
The ath9k_htc_set_bssid_mask function in
drivers/net/wireless/ath/ath9k/htc_drv_main.c in the Linux kernel through
3.12 uses a BSSID masking approach to determine the set of MAC addresses
on which a Wi-Fi device is listening, which allows remote attackers to
discover the original MAC address after spoofing by sending a series of
packets to MAC addresses with certain bit manipulations. (CVE-2013-4579)
Array index error in the kvm_vm_ioctl_create_vcpu function in
virt/kvm/kvm_main.c in the KVM subsystem in the Linux kernel through
3.12.5 allows local users to gain privileges via a large id value
The apic_get_tmcct function in arch/x86/kvm/lapic.c in the KVM subsystem
in the Linux kernel through 3.12.5 allows guest OS users to cause a denial
of service (divide-by-zero error and host OS crash) via crafted
modifications of the TMICT value. (CVE-2013-6367)
The KVM subsystem in the Linux kernel through 3.12.5 allows local users to
gain privileges or cause a denial of service (system crash) via a VAPIC
synchronization operation involving a page-end address. (CVE-2013-6368)
The recalculate_apic_map function in arch/x86/kvm/lapic.c in the KVM
subsystem in the Linux kernel through 3.12.5 allows guest OS users to
cause a denial of service (host OS crash) via a crafted ICR write
operation in x2apic mode. (CVE-2013-6376)
Multiple buffer underflows in the XFS implementation in the Linux kernel
through 3.12.1 allow local users to cause a denial of service (memory
corruption) or possibly have unspecified other impact by leveraging the
CAP_SYS_ADMIN capability for a (1) XFS_IOC_ATTRLIST_BY_HANDLE or (2)
XFS_IOC_ATTRLIST_BY_HANDLE_32 ioctl call with a crafted length value,
related to the xfs_attrlist_by_handle function in fs/xfs/xfs_ioctl.c
and the xfs_compat_attrlist_by_handle function in fs/xfs/xfs_ioctl32.c.
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
Faults during task-switch due to unhandled FPU-exceptions allow to
kill processes at random on all affected kernels, resulting in local
DOS in the end. One some architectures, privilege escalation under
non-common circumstances is possible. (CVE-2014-1438)
The hamradio yam_ioctl() code fails to initialise the cmd field of the
struct yamdrv_ioctl_cfg leading to a 4-byte info leak. (CVE-2014-1446)
Linux kernel built with the NetFilter Connection Tracking(NF_CONNTRACK)
support for IRC protocol(NF_NAT_IRC), is vulnerable to an information
leakage flaw. It could occur when communicating over direct
client-to-client IRC connection(/dcc) via a NAT-ed network. Kernel
attempts to mangle IRC TCP packet's content, wherein an uninitialised
'buffer' object is copied to a socket buffer and sent over to the other
end of a connection. (CVE-2014-1690)
For other changes, see the referenced changelogs:
Confirmed the issue with this one.
I booted back into kernel-desktop586 and removed this kernel, leaving linus 3.24 installed from updates.
I then removed dkms-nvidia-current to work around some leftovers from other kernels ( bug 10771 ) and rebooted, then reinstalled it again and rebooted into the current linus, 3.24.
So it was a clean environment to test again.
After installing the update candidate with it's devel from their respective -latest packages, nvidia was built so rebooted finally into the new kernel.
It reaches multi-user target and 'graphical interface' with no X and hasn't loaded either nvidia or nouveau modules.
Xorg.0.log shows failed to load nvidia driver and unloaded it. It ends with No screens found.
The journal shows..
kernel: nvidia: no symbol version for module_layout
3.10.24 rather than 3.24. Forgot the 10.
Hm, that should not happend.
do you have kernel-linus-source installed ?
what is the output of:
ls -l /lib/modules/3.10.28-1.mga3/
Ahh that might explain it. I have kernel-source but not kernel-linus-source.
I'll try it again.
Author: Thomas Backlund <tmb@...>
Date: Fri Feb 7 19:37:59 2014 +0200
- nuke create_link_source(), as we haven't supported building against
an unprepared source for ages, and currently can also create wrong
symlinks when kernel-source is installed before for example
kernel-linus as found out during QA for mga#12518 and debugging
the issue on irc
I reproduced the kernel-linus thing, and it only happends if kernel-source is installed before kernel-linus and they both have exactly the same version & release
I dont want to delay the kernels for it as they carry the fix for CVE-2014-0038, and almost no enduser will hit it, considering how old the drakx code is
next kernel update (whenever it happends) will have a fixed kernel-source to avoid it and drakx is fixed too in cauldron as seeen is comment 8
I guess I'll queue the same drakx fix for mga3 & mga4
mga3-64 boots normally and builds nvidia modules.
Will OK by evening (US East coast) if no other testers.
oking, still needs advisory upload.
Advisory uploaded. Validating.
Could sysadmin please push to 3 updates
MGA3-64-OK MGA3-32-OK =>
advisory MGA3-64-OK MGA3-32-OK