RHSA-2010:0291: Moderate: gfs-kmod security, bug fix and enhancement update

First published: Tue Mar 30 2010(Updated: )

The gfs-kmod packages contain modules that provide the ability to mount and<br>use GFS file systems.<br>A flaw was found in the gfs_lock() implementation. The GFS locking code<br>could skip the lock operation for files that have the S_ISGID bit<br>(set-group-ID on execution) in their mode set. A local, unprivileged user<br>on a system that has a GFS file system mounted could use this flaw to cause<br>a kernel panic. (CVE-2010-0727)<br>These updated gfs-kmod packages are in sync with the latest kernel<br>(2.6.18-194.el5). The modules in earlier gfs-kmod packages failed to load<br>because they did not match the running kernel. It was possible to<br>force-load the modules. With this update, however, users no longer need to.<br>These updated gfs-kmod packages also fix the following bugs:<br><li> when SELinux was in permissive mode, a race condition during file</li> creation could have caused one or more cluster nodes to be fenced and lock<br>the remaining nodes out of the GFS file system. This race condition no<br>longer occurs with this update. (BZ#471258)<br><li> when ACLs (Access Control Lists) are enabled on a GFS file system, if a</li> transaction that has started to do a write request does not have enough<br>spare blocks for the operation it causes a kernel panic. This update<br>ensures that there are enough blocks for the write request before starting<br>the operation. (BZ#513885)<br><li> requesting a "flock" on a file in GFS in either read-only or read-write</li> mode would sometimes cause a "Resource temporarily unavailable" state error<br>(error 11 for EWOULDBLOCK) to occur. In these cases, a flock could not be<br>obtained on the file in question. This has been fixed with this update so<br>that flocks can successfully be obtained on GFS files without this error<br>occurring. (BZ#515717)<br><li> the GFS withdraw function is a data integrity feature of GFS file systems</li> in a cluster. If the GFS kernel module detects an inconsistency in a GFS<br>file system following an I/O operation, the file system becomes unavailable<br>to the cluster. The GFS withdraw function is less severe than a kernel<br>panic, which would cause another node to fence the node. With this update,<br>you can override the GFS withdraw function by mounting the file system with<br>the "-o errors=panic" option specified. When this option is specified, any<br>errors that would normally cause the system to withdraw cause the system to<br>panic instead. This stops the node's cluster communications, which causes<br>the node to be fenced. (BZ#517145)<br>Finally, these updated gfs-kmod packages provide the following enhancement:<br><li> the GFS kernel modules have been updated to use the new generic freeze</li> and unfreeze ioctl interface that is also supported by the following file<br>systems: ext3, ext4, GFS2, JFS and ReiserFS. With this update, GFS supports<br>freeze/unfreeze through the VFS-level FIFREEZE/FITHAW ioctl interface.<br>(BZ#487610)<br>Users are advised to upgrade to these latest gfs-kmod packages, updated for<br>use with the 2.6.18-194.el5 kernel, which contain backported patches to<br>correct these issues, fix these bugs, and add this enhancement.

Never miss a vulnerability like this again

Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.

Read MoreStart Free Trial

• agent/description
• agent/event
• agent/first-publish-date
• agent/last-modified-date
• agent/references
• agent/remedy
• agent/severity
• agent/softwarecombine
• agent/tags
• agent/title
• agent/type
• agent/weakness
• collector/redhat-errata
• anchor-id/RHSA-2010:0291
• package-manager/redhat