[Ksplice][Ubuntu-13.04-Updates] New updates available via Ksplice (USN-1919-1)

[Jamie Iles]

Synopsis: USN-1919-1 can now be patched using Ksplice
CVEs: CVE-2013-2852 CVE-2013-3232

Systems running Ubuntu 13.04 Raring can now use Ksplice to patch
against the latest Ubuntu Security Notice, USN-1919-1.

INSTALLING THE UPDATES

We recommend that all users of Ksplice Uptrack on Ubuntu 13.04 Raring
install these updates.

On systems that have "autoinstall = yes" in /etc/uptrack/uptrack.conf,
these updates will be installed automatically and you do not need to
take any action.

Alternatively, you can install these updates by running:

# /usr/sbin/uptrack-upgrade -y


DESCRIPTION

* Kernel crash when unregistering VLAN interfaces.

If a VLAN interface was registered after the AP, on unregistering
the system will crash because because it is not prepared to deal
with AP's being closed before to remove their VLANs.


* XHCI raise a Kernel panic due to unitialised list head.

The list_for_each_entry_safe macro, assumes list heads are
initialized (not NULL), and dereferences their 'next' pointer,
causing a kernel panic if this is not yet initialized.


* Heap buffer overflow when mounting CIFS share.

An off-by-one error when copying UNC paths in Distributed File System referrals
can cause a heap buffer overflow and possibly gain kernel code execution.


* Kernel panic when GPU acceleration is disabled.

When GPU acceleration is disabled, the related data is freed, but a
subsequent cleanup call after this will cause a kernel panic.


* Kernel hang on initialization of Radeon driver.

The current radeon driver initialization routines, when using KMS,
are written so that the IRQ installation routine is called before
initializing the WB buffer and the CP rings. This behavior leads to a
Kernel hang.


* Data loss in ecryptfs file syncing.

The ecryptfs filesystem does not correctly flush the contents of memory mapped
files to disk potentially causing data loss.


* Memory corruption in CephFS object storage client.

Incorrect locking in the Ceph distributed filesystem client can cause memory
corruption and kernel panic when requesting new OSD mappings.


* Use-after-free in Rados block device creation.

The Rados block device, as used by the Ceph distributed filesystem incorrectly
frees when failing to create a client leading to a use-after-free and kernel
panic.


* Kernel panic in Bluetooth L2CAP processing.

The Bluetooth L2CAP driver does not correctly validate the length of received
frames causing the driver to read invalid memory and trigger a kernel panic.


* CVE-2013-2852: Invalid format string usage in Broadcom B43 wireless driver.

Format string vulnerability in the b43_request_firmware function
in the Broadcom B43 wireless driver in the Linux kernel through 3.9.4
allows local users to gain privileges by leveraging root access and
including format string specifiers in an fwpostfix modprobe parameter,
leading to improper construction of an error message.


* Missing permissions checks on /dev/kmsg

Missing permissions checks on /dev/kmsg could allow an unprivileged user
to access the kernel log buffer.


* Race condition on Swap while waiting on discard I/O completion.

When reading the swap cache page it can get into a race condition
leading to a system deadlock.


* CVE-2013-3232: Kernel stack information leak in amateur radio NET/ROM driver.

Missing initialization could allow a local user to leak kernel stack
information when receiving messages from a NET/ROM socket.


* NFS4 daemon not checking open permissions correctly.

A Linux client using CLAIM_FH to implement regular opens can manipulate
files skipping the permissions.


* Denial-of-service in reiserfs with NFS clients.

A race condition that could occur with two NFS clients on a reiserfs
file system could lead to a deadlock.  This could be exploited to cause
a denial of service.


* Denial-of-service with reiserfs xattrs.

When performing a chown on a setuid reiserfs file with xattrs invalid
handling of mode bits could lead to a kernel deadlock.  This could be
used to cause a denial of service.


* Memory corruption when removing a notifier from CLK.

When removing a notifier from the list, the entry is not
being removed keeping an invalid reference that affects
subsequent registrations.


* Kernel crash on IPv6 cork release.

When copying cork options on IPV6, the target memory space
for those is not zeroed, which could lead to a Kernel crash
as it could contain garbage when invoking the free routines.


* Kernel crash on ip_tunnel due to garbage data on IPCB.

If the link failure routine is called and IPCB is not
cleared, it will lead to a Kernel crash due to the existence
of garbage data.


* Kernel oops when using MSG_CMSG_COMPAT in socket interfaces.

>From user space is possible to use MSG_CMSG_COMPAT in the 'send'
and 'receive' socket family interfaces. This is not a standard
feature that when used from user space leads to a Kernel oops.


* NULL pointer dereference in SCTP socket destruction.

When a SCTP socket is destroyed, it can contains invalid references
as the routine can be invoked during the socket initialization.


* Kernel panic on team interface due to race condition in port removal.

When retrieving the port from a team interface, it might return a null
reference due to a race condition between the port removal and the
socket buffer transaction path leading to a Kernel Panic.


* NULL pointer dereference in Team port interface.

A race condition between port enabling and lookup could result in a
NULL pointer dereference.


* Information leak in AF_PACKET getname() call.

The getname() syscall does not correctly sanitize memory when called on an
AF_PACKET socket causing the contents of kernel memory to be disclosed to
userspace.


* Memory leak on L2TP PPP header.

When adding a PPP header, it leaks two bytes of uninitialised memory
at the end of the socket buffer data buffer.


* Memory corruption in Bluetooth L2CAP MTU control.

An integer underflow and memory corruption can be triggered by reducing the MTU
of an L2CAP socket and then sending a large L2CAP packet.


* Kernel deadlock when removing a Frame Relay device.

Incorrect locking when removing a Frame Relay DLCI device can cause a deadlock
and kernel panic.


* Kernel panic when removing a Frame Relay device.

Using the DLCI ioctl to remove a Frame Relay device on a socket that is not a
Frame Relay device can cause an invalid memory access and kernel panic.

SUPPORT

Ksplice support is available at ksplice-support_ww at oracle.com.