[Ksplice-Fedora-20-updates] New updates available via Ksplice (FEDORA-2015-6579)

[Oracle Ksplice]

Synopsis: FEDORA-2015-6579 can now be patched using Ksplice

Systems running Fedora 20 can now use Ksplice to patch against the
latest Fedora kernel update, FEDORA-2015-6579.

INSTALLING THE UPDATES

We recommend that all users of Ksplice Uptrack on Fedora 20 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 information leak in PCI Advanced Error Reporting.

Incorrect printing for TLP headers in the PCI Advanced Error Reporting
driver could result in printing the address of a kernel pointer and
stack bytes to userspace.


* NULL pointer dereference in multiqueue block core tag allocation.

Under I/O pressure, a NULL pointer dereference could be triggered when
there were no free tags in the multiqueue block core tag pool.


* Out-of-bounds memory access in multiqueue block core segment merging.

An incorrect array index could result in accessing beyond the bounds of
an array when merging requests.  This could result in a crash or other,
undefined behaviour.


* Denial-of-service in DRM framebuffer reference counting.

Incorrect handling of reference counting for the DRM framebuffer could
allow a local user with access to the DRM device to trigger a
denial-of-service.


* Denial-of-service in Radeon Translation Table Manager unbinding.

A missing NULL pointer check could result in a NULL pointer dereference
when unbinding a Translation Table Manager object.  A local user with
access to the DRM device could use this flaw to trigger a
denial-of-service.


* Use-after-free in kernel NFS server during lock state hashtable race.

A race condition when inserting a lock owner into the state owner hash
table could result in a use-after-free and subsequent kernel crash.


* Kernel crash in physical to virtual reverse mapping lookup.

Incorrect error handling when adjusting a virtual memory area could
result in integer underflow and a crash in the address reverse mapping
code.


* Kernel crash in isolated page freeing.

When freeing a previously isolated page, missing mappings could result
in an invalid pointer dereference, triggering a kernel crash.


* Kernel crash in SCSI devices during unplug.

Incorrect handling of unoperational links could result in accessing a
device when it should not be possible to do so.  This could result in an
invalid pointer dereference and kernel crash.


* Use-after-free in Industrial I/O core error handling.

Incorrect error handling in the Industrial I/O device registration
function could result in a double-free and kernel crash.


* NULL pointer dereference in Analog Devices IMU SPI driver.

Missing reference counting could result in a NULL pointer dereference in
the Analog Devices IMU SPI driver during removal if the trigger was
changed.


* Use-after-free in CIFS page writing during intermittent network connectivity.

Incorrect error handling during loss of network connection could result
in a use-after-free when writing pages on a CIFS filesystem.


* Memory leak in Realtek Wifi Access Point mode.

Failure to unmap DMA buffers would result in a memory leak.  After
running the device in AP mode for a period of time it would become
impossible to transmit frames.


* Kernel panic in ServerEngines iSCSI BladeEngine 2 initialization failure.

An incorrect call to remove the device in the error handling path could
result in a kernel crash when a BladeEngine 2 device failed to
initialize.


* OCFS2 file corruption for files opened with O_APPEND.

The OCFS2 filesystem was incorrectly synchronizing files opened with
O_APPEND.  This could result in data corruption under specific
conditions.


* Data corruption in ext4 hole punching with indirect mappings.

Under specific conditions, ext4 filesystems could experience data loss
when using FALLOC_FL_PUNCH_HOLE on files.


* XFS filesystem corruption during truncation.

Failure to write zeroed blocks to disk during truncation on an XFS
filesystem could result in failure to zero those blocks during a crash.
This could leave sensitive information on the disk.

SUPPORT

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