[Ksplice][Ubuntu-12.10-Updates] New updates available via Ksplice (USN-1699-1)

[Vegard Nossum]

Synopsis: USN-1699-1 can now be patched using Ksplice
CVEs: CVE-2012-4461 CVE-2012-4530

Systems running Ubuntu 12.10 Quantal can now use Ksplice to patch
against the latest Ubuntu Security Notice, USN-1699-1.

INSTALLING THE UPDATES

We recommend that all users of Ksplice Uptrack on Ubuntu 12.10 Quantal
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

* CVE-2012-4461: Kernel panic KVM XSAVE support.

On machines without XSAVE instruction support a malicious guest can cause
a host kernel panic via the SET_SREGS ioctl.


* Kernel panic in 802.11 frame parsing.

The generic 802.11 wireless driver does not correctly handle truncated
non-management frames leading to an out-of-bounds read and kernel
panic. This issue may be triggered by a remote attacker.


* Kernel panic in 802.11 EAPOL parsing.

The generic 802.11 wireless driver does not correctly handle truncated
EAP-over-LAN frames leading to an out-of-bounds read and kernel panic.
This issue may be triggered by a remote attacker.


* Use-after-free in target core TMR failure handling.

A double free for a command structure when handling a TMR failure could
result in a use-after-free condition and a kernel crash.


* ext4 filesystem corruption with journal_async_commit mount option.

Mounting an ext4 filesystem with the journal_async_commit mount option
enables journal checksumming and under certain circumstances this can
lead to data corruption.


* Use-after-free in Atheros Wireless driver.

A use-after-free condition can be triggered when the Atheros driver tears
down a wireless session leading to a kernel panic.


* Data corruption and kernel panics caused by cryptd.

A race condition in the cryptd subsystem could lead to data corruption
or kernel panics.


* Use-after-free in virtio device unregistration.

Members of a virtio device were accessed after registration resulting in
a use-after-free and a possible kernel crash.


* Memory corruption in WiFi station wakeup handling.

Missing locking could result in the corruption of internal lists leading
to a kernel crash.


* Resource leak in WiFi status management.

Incorrect resource freeing could result in a memory leak and hangs in
userspace WiFi applications such as wpa_supplicant and hostapd.


* Kernel crash in DRM memory type subsystem.

Incorrect memory allocation routines could result in a kernel crash when
allocating memory on systems with high memory.


* Kernel crash in shared memory inode eviction.

Incorrect locking in shared memory filesystems could result in a kernel
BUG_ON() and subsequent kernel crash.


* NULL pointer dereference in mtd subsystem.

An incorrect check for a NULL pointer could allow a later NULL
pointer deference in the mtd subsystem.


* Resource leak in XFS buffer I/O error handling.

Invalid reference counting when ending a failed I/O would result in a
memory leak.


* Deadlock in software RAID subsystem.

Fix a deadlock in the software RAID subsystem caused by attempting
recurse back into the request queue.


* Kernel crash in block subsystem.

Accessing a request after it has been freed can cause a crash
in the block driver subsystem.


* Kernel crash during recovery from hardware memory errors.

If a hardware memory error occurs, wrong assumptions about the type of
memory being offlined could trigger an internal sanity check and stop
the kernel.


* NULL pointer dereference in group scheduler.

When automatic process group scheduling is disabled
(sysctl kernel.sched_autogroup_enabled=0), the scheduler will crash
because it is no longer able to move threads from one runqueue to
another.


* Kernel panic in IPv4 ARP and IPv6 Neighbor Discovery.

An invalid assumption in the IP stack can lead to a kernel panic when
failing to send an IPv4 ARP or IPv6 Neighbor Discovery packet.


* Kernel panic when sending RDS ping responses.

Incorrect locking in the RDS implementation can cause a kernel panic
when responding to RDS ping packets. A remote attacker could potentially
use this flaw to cause a remote denial of service.


* Kernel crash in GFS2 cluster filesystem.

A race condition in the GFS2 cluster filesystem where data buffers were
not locked during buffer list manipulation could make the kernel crash.


* Use-after-free in L2TP Ethernet session.

The kernel L2TP driver does not correctly handle failing to initialise
a L2TPv3 Ethernet session leading to a use-after-free and kernel panic.


* Remote information leak in netfilter TCP connection tracking.

An attacker on a shared routing queue with the victim can gain information
about the victim's TCP connections by sending malformed TCP packets.


* Kernel crash in TCP repair mode during transmission.

Triggering TCP socket repair whilst there was data queued for writing
could result in a kernel crash.


* Kernel crash in GFS2 filesystem on mmap().

Invalid locking in GFS2 could result in kernel crash when modifying the
access time of a file under mmap().


* Use-after-free in NFC subsystem.

Fix an error condition where a already-freed command could be reused in
the NFC subsystem.


* Deadlock in ISDN gigaset.

Fix a potential deadlock with the delayed work function in the ISDN
gigaset driver.


* Buffer overflow in QuickNet Internet LineJack input handling.

The QuickNet Internet LineJack driver didn't properly check input from
userspace, which has made it possible to pass it strings which are not
properly NULL terminated, leading to a buffer overflow.


* CVE-2012-4530: Kernel information leak in binfmt execution.

Execution of a carefully crafted sequence of scripts could allow an
unprivileged user to leak kernel stack information to userspace.


* NULL pointer dereference on futex wakeup.

Incorrect synchronization during a futex wakeup sequence can trigger a
NULL pointer dereference by trying to wake up a locked futex.


* Deadlock in block device journalling layer JBD.

Under certain circumstances, waiting for a transaction to be committed
to the journal could deadlock because of holding an extra lock that
should have been dropped.


* Deadlock in JFFS2 filesystem.

Inconsistent lock ordering could lead to deadlocks in the JFFS2
filesystem.

SUPPORT

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