[Ksplice-Fedora-19-updates] New updates available via Ksplice (3.12.7-200.fc19)

[Oracle Ksplice]

Synopsis: 3.12.7-200.fc19 can now be patched using Ksplice

Systems running Fedora 19 can now use Ksplice to patch against the
latest Fedora kernel update, 3.12.7-200.fc19.

INSTALLING THE UPDATES

We recommend that all users of Ksplice Uptrack on Fedora 19 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

* Logic error in selinux when checking permissions on recv socket.

Due to a flaw in selinux permission checking, a logic error could lead to
forbidden data coming in.


* Denial-of-service in XFS quota management.

Turning off group quota on a mounted XFS filesystem with user quota enabled
will lead xfs_quota to hang.


* Data loss using ext4 with journaling.

Incorrect handling of errors from the journal layer could result in
deadlock between ext4 and jbd2, eventually resulting in data loss.


* Use-after-free in ext4 when creating new block.

Incorrect locking in ext4 could lead to a use-after-free and to kernel
crash when creating new block on ext4 filesystem.


* Denial-of-service in ext4 extent validation.

Incorrect handling of overlapping extents could result in failing kernel
assertion and crashing the system. A local, privileged user, could use a
carefully crafted filesystem to cause a denial-of-service.


* Denial-of-service in ext4 filesystem unmounting.

A race condition in ext4 could result in a use-after-free and kernel
crash. A local, privileged user could use this flaw to cause a
denial-of-service, or potentially escalate privileges.


* Denial-of-service in ext4 when partition is full.

Incorrect locking in ext4 could lead to a use-after-free. An attacker could
use this to cause denial-of-service.


* Disk corruption on ext4 filesystems due to physical block address corruption.

Incorrect calculation of physical block addresses could result in corruption
of the on-disk filesystem.


* Use-after-free in Intel graphic card driver when releasing file descriptor.

Incorrect locking in the Intel graphic card driver could lead to a
use-after-free and panic.


* Use-after-free in Intel graphic card driver under high memory pressure.

Heavy memory pressure could lead to a use-after-free and to a panic in the
Intel graphic card driver.


* Use-after-free in Intel graphic card driver when releasing the frame buffer.

A flaw in Intel graphic card driver release code could lead to a
use-after-free and a kernel panic.


* NULL pointer dereference when creating a new cgroup.

A flaw in the error handling path could cause a NULL dereference and a
panic. A local, privileged user could use this to cause a denial-of-service
or potentially escalate privileges.


* Memory leak in CIFS symlink management code.

Incorrect reference counting in the CIFS code leads to a memory leak. A
local, unprivileged user could use this flaw to cause a denial-of-service.


* Out of bound memory access in Radio tap.

A lack of input validation in the Radio tap iterator code could lead to out
of bound memory access. A local, privileged user, could use this to cause a
denial-of-service, or potentially escalate privileges.


* Denial-of-service in ext2 when writing quota.

A flaw in ext2 quota management could lead to use uninitialized memory. A
local, privileged user could use this to cause a denial-of-service.


* NULL pointer dereference in Huge TLB subsystem.

A missing check in the Huge TLB subsystem could lead to a NULL pointer dereference
and panic. An attacker could use this flaw to cause a denial-of-service.


* Denial-of-service in Transparent Hugepage subsystem when calling munlock().

A flaw in the Transparent Huge Page subsystem could lead to a kernel panic
when unmapping/unlocking Transparent Huge pages. An attacker could use this
flaw to cause a denial-of-service.


* Denial-of-service in memory management when unlocking pages.

Incorrect locking in the memory management subsystem could lead to a
deadlock. An attacker could use this to cause a denial-of-service.


* Use-after-free in memory management subsystem when remapping files.

A flaw in the memory management subsystem could lead to a use-after-free
and panic. An attacker could use this to cause a denial-of-service.


* NULL pointer dereference in memory management on memory failures.

Incorrect reference counting in the memory management subsystem could lead
to a panic. An attacker could use this to cause a denial-of-service.


* Denial-of-service in GFS2 filesystem when mounting.

Incorrect locking in the GFS2 filesystem could lead to a deadlock when
mounting more than once a partition. A local, privileged user, could use
this flaw to cause a denial-of-service.


* Use-after-free in GFS2 filesystem when writing to the log.

A race condition in the GFS2 filesystem could result in a use-after-free
and kernel crash. A local, privileged user could use this flaw to cause a
denial-of-service, or potentially escalate privileges.


* Memory leak in GFS2 filesystem for files with short lifespan.

A race condition in the GFS2 filesystem could lead to a memory leak for
files with a very short lifespan. A local, unprivileged user could use this
flaw to cause a denial-of-service.


* Missing check in selinux for outbound IPSec packets.

A missing check in selinux allowed any outbound IPSec packets to pass
through. This flaw could lead a local, unprivileged user to send
unauthorized traffic.


* Missing check in selinux for IPSec TCP SYN-ACK packets.

Due to a flaw in the selinux code, IPSec TCP SYN-ACK packets could pass-
through without permission checking. An attacker could use this to send or
receive unauthorized traffic.


* Denial-of-service in ext4 created with bigalloc.

A logic error in ext4 filesystem with bigalloc feature could cause
unexpected journaling errors, potentially leaving the filesystem in a read
only state. A local, unprivileged user could use this to cause a
denial-of-service.


* Denial-of-service in KVM with nested VMs.

A missing check in the KVM MMU code could lead to a kernel crash. A local,
privileged user could use this flaw to cause a denial-of-service.

SUPPORT

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