[El-errata] New updates available via Ksplice (ELSA-2014-3096)

[Errata Announcements for Oracle Linux]

Synopsis: ELSA-2014-3096 can now be patched using Ksplice
CVEs: CVE-2014-1739 CVE-2014-3181 CVE-2014-4014 CVE-2014-4171

Users with Oracle Linux Premier Support can now use Ksplice to patch
against the latest Oracle Security Advisory, ELSA-2014-3096.

INSTALLING THE UPDATES

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

* Cluster deadlock during journal commit in OCFS2 filesystem.

Under certain circumstances, incorrect lock ordering could cause a
deadlock if one thread handles a buffer write at the same time as the
journal commit thread attempts to flush the buffer. If this happens,
the whole cluster will hang.


* I/O errors and spurious warning in BladeEngine 2 iSCSI driver.

Due to a missing mailbox availability check in the BladeEngine 2
iSCSI driver, the driver could in certain high-pressure situations
attempt to request a non-existant mailbox and trigger a spurious
warning and potential I/O errors.


* Device hang during cleanup in BladeEngine 2 iSCSI driver.

With certain firmware configurations, an incorrect cleanup sequence
could lead to the whole device entering a hung state.


* Invalid memory free when setting management address in BladeEngine 2 iSCSI driver.

Incorrect error handling when changing the management IP address in the
BladeEngine 2 iSCSI driver could lead to freeing an invalid pointer. In
certain situations, this could lead to memory corruption and kernel crashes.


* Use-after-free in netfilter xtables when copying counters to userspace.

A logic error in the netfilter ebtables, arp tables and IPv4/IPv6 tables
may lead to a use-after-free if there is an error when copying counters to
userspace as this will result in freeing the tables when they have already
been exposed to userspace. Any subsequent packet processing will lead to a
use-after-free and a kernel panic.


* Soft lockup in huge page code when releasing huge TLB pool.

A missing call to the scheduler when releasing a huge TLB pool could lead
to a soft lockup. A local, privileged user could use this flaw to cause a
denial-of-service.


* Deadlock in USB serial driver when unloading the module.

Incorrect locking between module removal and sysfs callbacks in the USB
serial driver could lead to a deadlock. A local, privileged user could use
this flaw to cause a denial-of-service.


* Divide-by-zero in TCP cubic congestion algorithm when computing delayed ack.

A logic error in the TCP cubic congestion algorithm could lead to a
divide-by-zero and kernel panic. A remote attacker could potentially use
this flaw to cause a denial-of-service.


* NULL pointer dereference in IPv6 netlink validation callback.

A missing check for NULL in the IPv6 netlink validation callback leads to a
NULL pointer dereference. A local, privileged user could use this flaw to
cause a kernel panic and denial-of-service.


* Memory corruption when accessing a huge TLB of a copy-on-write page.

A missing flush of the huge translation lookaside buffer for a page copied
after a write could lead to a memory corruption as it can lead a parent
process to access the child copied version of the page rather than the
original page. A local, unprivileged user could use this flaw to cause a
memory corruption or potentially elevate privileges.


* NULL pointer dereference in the filesystem stack when checking ACL.

A missing check for NULL when checking if a filesystem ACL can be
represented using traditional UNIX permissions could lead to a kernel
panic. A remote attacker controlling a NFS server or a local unprivileged
user could use this flaw to cause a denial-of-service.


* CVE-2014-1739: Information leak in the media stack when enumerating media devices.

The ioctl() to enumerate media devices can copy 200 bytes of kernel stack
to userspace. A local user with write access to /dev/mediaX could use this
flaw to gather information about the running kernel.


* Kernel panic in NFSv4 client allocation.

The kernel NFSv4 server does not initialise certain data structures when
allocating a new client. This can trigger a kernel panic when
initialising a new client fails.


* Kernel crash in timer callback when destroying NFSv4 client.

In certain cases, the kernel would free NFSv4 client data when there
were still pending callbacks for that client. This could lead to a
use-after-free error and memory corruption and possibly crashing the
kernel. A remote attacker (NFS client) could use this to cause denial
of service.


* Kernel BUG() in NFS daemon when setting ACL with no entries.

A logic error in the NFS daemon code could trigger a kernel BUG() when
setting ACL with no entries.


* Use-after-free in NFSv4 daemon kernel implementation when releasing a state ID.

A lack of clean-up of a lock owner attached to a state ID when releasing
the state ID could lead to use-after-free and kernel panic in the NFSv4
daemon implementation.


* Use-after-free in libceph when sending pages over TCP.

RADOS block devices do not handle properly sending pages with page_count 0
over TCP which will result in incorrectly free-ing the page while still in
use leading to a memory corruption and kernel panic. A local, privileged
user could use this flaw to cause a denial-of-service.


* Use-after-free in memory management subsystem when releasing a VMA.

Incorrect ordering of de-allocation routines when releasing a VMA could
lead to a use-after-free and kernel panic. A local, unprivileged user could
use this flaw to cause a denial-of-service.


* CVE-2014-4014: Privilege escalation in user namespace.

Incorrect use of the inode_capable() function to check permissions in a
user namespace allows unprivileged users to change the GID bit of files for
which they are not the group owner. A local, unprivileged user could use
this flaw to escalate privileges.


* NULL pointer dereference in Target Core Mod when reading from sysfs.

A missing check to verify that the backend device has been configured leads
to a NULL pointer dereference when writing to sysfs file
alua_access_state. A local, privileged user could use this to cause a
denial-of-service.


* Use-after-free in UDP stack in the fast transmit path.

Incorrect locking in the UDP stack when using the lockless transmit path
can lead to a race-condition causing a use-after-free and kernel panic. An
attacker could use this flaw to cause a denial-of-service.


* Kernel crash after freeing anonymous pages in memory management subsystem.

The functions responsible for freeing anonymous pages could sleep inside
an RCU critical section. This triggers the premature expiration of a RCU
grace period, possibly causing use-after-free errors or other unspecified
race conditions. A malicious user could potentially use this to cause a
kernel crash and denial of service.


* Potential data corruption with memory-mapped files on Ext4 filesystem.

When memory-mapping parts of a file, modifications made to memory beyond
the file size should not be written back to the file. In certain
circumstances, the ext4 driver would incorrectly write back these
modifications, potentially causing data corruption in applications that
rely on the specific behaviour.


* Denial-of-service in EXT4 block allocation.

Incorrect validation of request sizes could result in hitting a kernel
assertion and crashing the system.  A local, privileged user could use
this flaw to crash the system with a carefully crafted filesystem image.


* Information leak in mcp ram disk.

A failure to clear out mcp ramdisk pages could allow sensitive
information to be leaked via reads from a ramdisk_mcp.


* Use-after-free in BTRFS extent writing.

A double-free in BTRFS extent writing could result in a use-after-free
under specific conditions, resulting in memory corruption.


* NULL pointer dereference in BTRFS device removal.

A missing loop escape could result in a NULL pointer dereference when
removing a device from a BTRFS filesystem under specific conditions.


* Use-after-free in Micro PCIe SSDs block driver when unloading the module.

Wrong order when calling de-allocations routines at module exit could cause
a use-after-free and kernel panic. A local, privileged user could this flaw
to cause a denial-of-service.


* Invalid pointer dereference in NFS filesystem after allocating a file layout.

Missing check for NULL after allocating memory for a file layout in the NFS
filesystem could lead to an invalid pointer dereference and kernel panic
under memory pressure.


* Memory leak in NFS filesystem when releasing a lock stateid.

A flaw in the NFS filesystem code when releasing a lock stateid results in
the lock owner not being freed, resulting in a memory leak. A local,
unprivileged user could use this flaw to exhaust the memory on the system
and cause a denial-of-service.


* Kernel BUG in reiserfs when NFS changes file attributes.

Incorrect locking in the reiserfs code could lead to a race condition when
NFS changes a file attribute concurrently with the file being released,
leading to a kernel BUG and denial-of-service. A local, unprivileged user
could use this flaw to cause a denial-of-service.


* Kernel panic in IP virtual server netfilter.

The kernel does not correctly handle the case of a non-linear ICMP
packet being received in response to an IPIP packet, leading to an
out-of-bounds read and kernel panic.


* Information leak in netfilter ULOG module.

The netfilter ULOG module does not sanitize kernel memory when saving
packets, leading to the contents of kernel memory to be leaked to
userspace.


* Kernel crash in virtio scsi workqueue.

A bug in the virtio scsi code allowed uninitialized work queue
items being processed.  This could lead to an invalid memory
reference and kernel crash.


* NULL pointer dereference when probing non-FTDI devices.

If a users forces a non-FTDI device to be probed by the USB
serial FTDI code, it causes a NULL pointer dereference.  This can
lead to a kernel crash.


* Denial-of-service with TKIP on Ralink USB devices.

The rt2x00 driver cannot atomically get a TKIP key, so disable TKIP
support.  Otherwise, it can lead to a kernel BUG().  A malicious user
could exploit this to cause a denial-of-service.


* Multiple denial-of-service problems in bluetooth code.

Multiple race conditions in the bluetooth code could cause deadlocks
in the bluetooth code.


* Invalid memory reference in NFSv4 symlink decoding.

A bug in how the nfsd decoded the data for a symlink operation
could lead to the nfsd code writing to an invalid memory location.


* Kernel panic during hugepage migration.

Due to a race between fork() and hugepage migration, the kernel attempts to
copy hugetlb mappings that are in the process of being migrated. This would
lead to a kernel panic. A malicious user with hugetlb access could use this
to cause denial of service.


* Use-after-free in mbind vma merge.

A bug in the mm code could result in a use-after-free when doing
a vma merge, leading to a kernel crash.


* Multiple journal corruptions in the ext4 filesystem.

Multiple flaws in the ext4 filesystem could lead to incorrect checksums
being computed in the journal under specific conditions. These flaws could
cause the filesystem to be re-mounted read-only or cause data corruption
and denial-of-service.


* CVE-2014-4171: Denial-of-service in shared memory when faulting into a hole while it's punched.

A flaw in the shared memory fault implementation could lead to a kernel
hang if the fault happens to be in a hole which is being punched or
sliced. A local, privileged user could use this flaw to cause a
denial-of-service.


* Memory leak in 8021q stack when re-ordering vlan headers.

When re-ordering vlan headers, a socket buffer wasn't properly released if
creating a copy-on-write socket buffer failed. This could cause a
denial-of-service by exhausting the memory on the system.


* NULL pointer dereference in Broadcom BN2X ethernet driver under memory pressure.

Under memory pressure, an allocation in the Broadcom BN2X could fail and
leads to a NULL pointer dereference as the return value isn't checked. An
attacker could use this flaw to cause a denial-of-service.


* Denial-of-service in TCP stack when pushing during TCP repair.

A flaw in the TCP stack when pushing during a TCP repair could trigger a
divide-by-zero fault. A local, privileged user could use this flaw to cause
a denial-of-service.


* Information leak in the stream control transmission protocol stack.

Some structures exchanged between user space and kernel space in the stream
control transmission protocol stack contain holes which may be left
uninitialized. A local, unprivileged user could use this flaw to obtain
information about the running kernel.


* Out of bounds memory access in the DNS resolver when querying.

A logic error in the DNS resolver could lead to an out of bound read of one
byte, possibly causing a kernel panic. A local, unprivileged user could use
this flaw to cause a denial-of-service.


* Memory leak in the Radeon display driver when retrieving the display modes.

The EDID of a display device could be allocated multiple times under
specific conditions, leading the first one allocated to be unreachable and
leaked. A local, privileged user could use this flaw to exhaust the memory
on the system and cause a denial-of-service.


* NULL pointer dereference in block control group queue draining.

A race between draining and destruction of a block control group queue
could result in a NULL pointer dereference and kernel crash.


* Incorrect SELinux label in cryptographic sockets.

The kernel does not correctly apply an SELinux label to cryptographic
control sockets. This can allow local users to bypass SELinux policies.


* NULL pointer dereference in 802.11 event tracing.

A missing NULL pointer check could result in a NULL pointer dereference
when tracing the 802.11 wireless subsystem.


* Deadlock in clockevent delta modification.

Circular locking when printing a kernel log message during the
modification of a clockevent timer could result in deadlock and a kernel
hang.


* Memory leak in kernel red-black tree implementation.

The kernel red-black tree data structure does not correctly free memory
when a red-black tree is destroyed leading to a kernel memory leak and
subsequent kernel panic.


* Kernel crash in Broadcom BNX2X driver during TCP offload.

Incorrect unmapping of transmitted packets could result in a kernel
crash when a TCP packet was tunneled using TCP segment offloading.


* Denial-of-service in network sendmsg() calls.

Missing validation of msg_namelen on a sendmsg call could result in a
NULL pointer dereference.  A local, unprivileged user could use this
flaw to cause a denial-of-service.


* Invalid memory access in network vectored I/O.

Incorrect handling of a zero length I/O vector could result in
dereferencing an invalid pointer.  Under specific conditions this could
result in a kernel crash.


* Deadlock in SCTP protocol stack when transmitting a packet.

Improper use of the macro IP_INC_STATS_BH() to update the network
statistics when transmitting a packet in the SCTP stack in user context
could lead to a deadlock. A local, unprivileged user could use this flaw to
cause a denial-of-service.


* Soft lockup after vcpu hot-remove in Xen PVM/HVM guests.

Due to a premature optimisation, hot-removing a vcpu from a Xen PVM/HVM
guest could in certain cases lead to a soft lockup.


* Memory corruption XFS filesystem resizing.

The kernel XFS filesystem driver uses an incorrect offset when resizing V4
filesystem images leading to memory corruption and a kernel panic.


* Kernel crash when sending message in Oracle VM guest messaging driver.

Due to an incorrect bounds check in the OVM SEND_MESSAGE ioctl, a user
with access to the OVM device file could crash the kernel by calling
ioctl() with an invalid value.


* Memory leak in Oracle VM guest messaging driver.

Due to an incorrect error path, it is possible to leak a small amount of
memory when receiving a message from the Dom0.


* Xen PVH guest crash while creating grant table.

A bug in the PVH grant table setup causes PVH guests to crash
when attempting to map pages for the grant table.


* Kernel oops when running out of Xen grant references

Due to incorrect error checking, it was possible for the kernel to oops
after running out of Xen grant references. A user with the ability to
successfully request new grant refs could potentially trigger this bug
and cause denial of service.


* Memory leak when initialising ports in BladeEngine 2 iSCSI driver.

Incorrect error handling during port initialisation in the BladeEngine 2
iSCSI driver could lead to memory leaks when there is little free memory
available.


* Memory corruption during device probing in BladeEngine 2 iSCSI driver.

Due to incorrect initialisation of the device structures, it was possible
for the BladeEngine 2 iSCSI device driver to write beyond the end of a
buffer, thus potentially corrupting unrelated memory areas. Under certain
circumstances this could lead to kernel crashes.


* Kernel panic during BladeEngine 2 iSCSI adapter initialization.

Due to premature exposure of BladeEngine 2 iSCSI adapter sysfs
files, it was possible to access these files before the adapter had
finished initializing. This would lead to a kernel panic.


* NULL pointer dereference during HP Smart Array SCSI device initialization.

In certain high memory pressure situations, missing error checks during
HP Smart Array SCSI device initialization could lead to a NULL pointer
dereference and subsequently crash the kernel.


* Kernel BUG for 256-block data transfers in HP Smart Array SCSI driver.

256-block data transfers were accidentally interpreted as (illegal)
0-block transfers and could trigger an internal assertion failure.


* Kernel hang in Broadcom Tigon3 ethernet driver.

The Broadcom Tigon3 ethernet driver was calling a function not intended to
run in interrupt context in its interrupt handler. In certain cases, this
could lead to the kernel hanging.


* Use-after-free in tg3 network driver stats.

Invalid locking could result in a use-after-free condition when
accessing device statistics.


* Kernel hang in Broadcom NX2 network driver.

The Broadcom NX2 ethernet driver was calling a function not intended to
run in interrupt context in its interrupt handler. In certain cases, this
could lead to the kernel hanging.


* Kernel crash when receiving network event in Broadcom CNIC driver.

The functions responsible for receiving network events could sleep inside
an RCU critical section. This triggers the premature expiration of a RCU
grace period, possibly causing use-after-free errors or other unspecified
race conditions. A remote network node might be able to use this to
trigger a kernel crash and cause denial of service.


* Information leak in Broadcom Everest network driver.

Due to insufficient input checking in the Broadcom Everest network driver
when changing the receive mode, it is possible for a VM to listen to
traffic intended for other VMs, thus creating an information leak.


* Memory leak when removing Broadcom Everest network interface.

When removing a Broadcom Everest network interface, the driver did not
clean up all memory relating to mailbox and bulletin boards. Removing
the driver or the device repeatedly could cause a significant amount of
memory to be leaked.


* Fatal hardware error in Broadcom Everest network driver.

With certain devices, the hardware requires that all receive buffers
are empty before resetting the device. If this is not the case, the
device will likely give a fatal hardware error and stop working.


* Endless stream of errors when unloading Broadcom Everest network device.

Because the Broadcom Everest network driver did not correctly clean up
pending delayed work, unloading a device due to an injected error would
cause a new error, perpetuating the error condition and rendering the
device useless.


* Kernel crash after EEH recovery in Broadcom Everest network driver.

Due to a missing memory barrier, EEH recovery could cause the CPU
to process stale data from the network device. This could lead to
various kernel crashes or NULL pointer dereferences.


* NULL pointer dereference in Broadcom NetXtreme II driver.

Due to missing error handling in the Broadcom NetXtreme II FCoE offload
driver during adapter binding and unbinding, the kernel could in some
cases dereference a NULL pointer and crash.


* Memory leak in Broadcom NetXtreme II driver.

In certain error situations, the Broadcom NetXtreme II driver did not
clean up all the allocated memory, leading to a memory leak. If the
device or driver is repeatedly loaded and unloaded, this could over
time exhaust all the machine's free memory.


* Kernel crash in Broadcom NetXtreme II driver.

In certain error situations, the Broadcom NetXtreme II driver could
access uninitialised data when attempting to clean up. This could lead
to a kernel panic or crash.


* CVE-2014-3181: Memory corruption in Apple Magic Mouse USB driver.

The Apple Magic Mouse USB driver does not correctly validate event data
allowing a malicious USB device to trigger kernel memory corruption and
potentially gain elevated privileges.


* Kernel BUG during Emulex BladeEngine 2 network device shutdown.

The Emulex BladeEngine 2 network device driver does not correctly
disable and free its hardware interrupt lines on shutdown. This can
trigger an internal assertion failure and a kernel BUG during device
shutdown.


* Buffer overrun using Large Receive Offload in Mellanox VNIC driver.

When using Large Receive Offload (LRO) with a Mellanox VNIC device,
the kernel would calculate the wrong offset when receiving packets.
The resulting pointer could point outside the buffer reserved for
the packet and cause the kernel to attempt to dereference invalid
memory. This could lead to a kernel crash.


* Second cluster deadlock during journal commit in OCFS2 filesystem.

Under certain circumstances, incorrect lock ordering could cause a
deadlock if one thread handles a buffer write at the same time as the
journal commit thread attempts to flush the buffer. If this happens,
the whole cluster will hang.


* NULL pointer dereference during zero page writeback in OCFS2 filesystem.

Due to a missing NULL pointer check, starting a new ordered transaction
on an OCFS2 filesystem mounted in data writeback mode could cause the
kernel to dereference the NULL pointer and panic.


* Deadlock during port logins in Qlogic QLA2XXXX Fibre Channel driver.

Incorrect synchronisation between the SCSI error handler and Qlogic
QLA2XXXX Fibre Channel port logins could in certain situations cause
a deadlock and a kernel hang.


* NULL pointer dereference in Qlogic QLA2XXXX Fibre Channel driver.

Due to missing initialization when creating request/response queues,
the shadow index register pointers would be 0. This could cause a
kernel crash.


* Stack corruption in Qlogic QLA2XXXX Fibre Channel driver.

Due to an on-stack buffer being too small, certain configurations could
lead to the kernel overwriting other, unrelated parts of the stack. This
could lead to stack corruption and kernel crashes.


* Kernel crash during Qlogic QLA2XXXX Fibre Channel firmware loading.

Due to incorrect error handling, a failure to load a firmware segment
would not propagate the error and crash the kernel when it subsequently
tries to access an invalid segment pointer.


* Information leak in QLogic Data Center Bridging (DCB).

A lack of structure initialization in the QLogic DCB driver discloses 2
bytes of kernel stack to userspace. This could be used by an attacker to
gather information about the running kernel and help in a potential attack.


* Random timeouts in Qlogic QLCNIC SR-IOV network device.

Due to lack of proper initialization in the mailbox command structure
of the Qlogic QLCNIC SR-IOV network device driver, some fields included
random garbage that could cause commands sent to the device to time out
at random.


* Kernel crash during open() in Qlogic QLCNIC network device.

Due to incorrect initialization order in the Qlogic QLCNIC driver, it would
be possible for userspace to get a handle on a partially initialized device,
potentially causing kernel crashes.


* Memory corruption in Qlogic QLCNIC network device when reporting statistics.

Due to incorrect initialization of the ethtool statistics buffer, it
was possible for a request for Qlogic QLCNIC network device statistics
to write beyond the end of the buffer, thus corrupting kernel memory
and potentially crashing the kernel.


* Multiple memory leaks in RPC over RDMA client support.

Due to incorrect error handling during both RPC over RDMA buffer
creation and destruction, a failure to allocate memory could cause
memory leaks.


* NULL pointer dereference during reconnect in RPC over RDMA client support.

In certain circumstances, an RDMA client disconnect could fail to
initialize a certain pointer, leaving it as a NULL pointer. This
could lead to a NULL pointer dereference later if there were pending
RPC requests from the client. A malicious user could possibly take
advantage of this to cause denial of service.


* NULL pointer dereference in RPC over RDMA client support during GETACL request.

Due to incorrect initialization in the RPC over RDMA client support
driver, a GETACL request could cause a NULL pointer dereference and
crash the kernel. A malicious remote user could potentially take
advantage of this to cause denial of service.


* Kernel crash during DMA in RPC over RDMA client driver.

Missing error handling when mapping DMA memory could in the worst case
cause the kernel to access unmapped or unrelated memory if the memory
mapping failed. This could cause a kernel crash.


* Deadlock during filesystem removal in NVM Express block device driver.

Due to an incorrect ordering of operations when removing a filesystem
on an NVM Express block device, it was possible that the kernel would
attempt to wait for the filesystem's dirty data to be written out,
which would be impossible as the disk had already been removed. This
could lead to a kernel hang.


* Invalid memory read in NVM Express block device I/O submission ioctl.

In certain circumstances where an NVM Express block device was
allocated a different number of interrupt vectors than online CPU
cores, it is possible for the IOCTL_SUBMIT_IO ioctl to read beyond
the end of the queue array. This could lead to a kernel crash.


* Information leak in NVM Express block device ioctl.

Incorrect initialization of data passed back to userspace in the NVM
Express block device driver ioctl could give the userspace process
access to privileged information.


* Memory corruption when deleting NVM Express block device disks.

Because of a race condition in the NVM Express block device driver, it
was possible to open a block device after it had been deleted by the
driver. This could lead to a double free, invalid memory accesses, and
the kernel crashing.


* NULL pointer dereference when closing connection in Emulex BladeEngine 2 driver.

Due to a missing NULL check in the Emulex BladeEngine 2 driver, closing
a connection could attempt to process some events after resources had
already been freed. This would lead to a NULL pointer dereference and
kernel crash.


* Kernel panic during shutdown in Emulex BladeEngine 2 driver.

Due to an incorrect deinitialization sequence in the Emulex
BladeEngine 2 driver, a workqueue was being destroyed after
the adapter resources had already been freed. This could lead
to a kernel panic when rebooting or shutting down the machine.


* Kernel crash during Emulex LightPulse Fibre Channel driver unload.

Due to a race condition in the Emulex LightPulse Fibre Channel driver,
it was possible to queue new work while the driver was being unloaded.
This could lead to an unspecified kernel crash.


* Kernel panic in Emulex LightPulse Fibre Channel driver when aborting SCSI command.

A missing test in the Emulex LightPulse Fibre Channel driver when
aborting an SCSI command could lead to an attempt to abort the same
command again, which is an error. This could lead to a kernel panic.


* SLI data corruption in Emulex LightPulse Fibre Channel driver.

Missing memory barriers in the Service Level Interface (SLI) could lead
to reading stale data from the device, possibly causing data corruption
and unspecified kernel crashes.


* Memory leak during HBA reset in Emulex LightPulse Fibre Channel driver.

When resetting the Host Bus Adapter (HBA) of a Emulex LightPulse Fibre
Channel device, the driver did not clean up outstanding events. This
could lead to a memory leak of these events.


* Use of uninitialized memory during bitmap init in Emulex LightPulse Fibre Channel driver.

Missing initialization during RRQ bitmap allocation in the Emulex
LightPulse Fibre Channel driver could lead to use of uninitialized
memory and potentially cause the kernel to crash.


* Kernel crash when shutting down QLogic NetXen ethernet adapter.

Due to incorrect locking in the QLogic NetXen ethernet driver, it was
possible to call a function that might sleep inside a spinlock critical
section. This could in certain circumstances cause deadlocks and other
unspecified kernel crashes.


* Device hang when shutting down QLogic NetXen ethernet adapter.

Due to an accounting bug when processing transmit completions in the
QLogic NetXen ethernet adapter, it was possible for the device to
hang indefinitely when attempting to shut it down.

SUPPORT

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