The remote Scientific Linux host is missing one or more security
This update fixes the following security issue :
- A flaw was found in the way the Xen hypervisor AMD IOMMU
driver handled interrupt remapping entries. By default,
a single interrupt remapping table is used, and old
interrupt remapping entries are not cleared, potentially
allowing a privileged guest user in a guest that has a
passed- through, bus-mastering capable PCI device to
inject interrupt entries into others guests, including
the privileged management domain (Dom0), leading to a
denial of service. (CVE-2013-0153, Moderate)
This update also fixes the following bugs :
- When a process is opening a file over NFSv4, sometimes
an OPEN call can succeed while the following GETATTR
operation fails with an NFS4ERR_DELAY error. The NFSv4
code did not handle such a situation correctly and
allowed an NFSv4 client to attempt to use the buffer
that should contain the GETATTR information. However,
the buffer did not contain the valid GETATTR
information, which caused the client to return a
'-ENOTDIR' error. Consequently, the process failed to
open the requested file. This update backports a patch
that adds a test condition verifying validity of the
GETATTR information. If the GETATTR information is
invalid, it is obtained later and the process opens the
requested file as expected.
- Previously, the xdr routines in NFS version 2 and 3
conditionally updated the res->count variable. Read
retry attempts after a short NFS read() call could fail
to update the res->count variable, resulting in
truncated read data being returned. With this update,
the res->count variable is updated unconditionally so
this bug can no longer occur.
- When handling requests from Intelligent Platform
Management Interface (IPMI) clients, the IPMI driver
previously used two different locks for an IPMI request.
If two IPMI clients sent their requests at the same
time, each request could receive one of the locks and
then wait for the second lock to become available. This
resulted in a deadlock situation and the system became
unresponsive. The problem could occur more likely in
environments with many IPMI clients. This update
modifies the IPMI driver to handle the received messages
using tasklets so the driver now uses a safe locking
technique when handling IPMI requests and the mentioned
deadlock can no longer occur.
- Incorrect locking around the cl_state_owners list could
cause the NFSv4 state reclaimer thread to enter an
infinite loop while holding the Big Kernel Lock (BLK).
As a consequence, the NFSv4 client became unresponsive.
With this update, safe list iteration is used, which
prevents the NFSv4 client from hanging in this scenario.
The system must be rebooted for this update to take effect.
See also :
Update the affected packages.
Risk factor :
Medium / CVSS Base Score : 4.7