Security fix on kernel 2.6.18-238.28.1.el5 and later breaks VxFEN configuration when vxfenmode is set to DMP

Article: 100026532
Last Published: 2012-06-26
Ratings: 0 0
Product(s): InfoScale & Storage Foundation

Problem

Recent kernel security fix (752375 - CVE-2011-4127 kernel: possible privilege  escalation via SG_IO ioctl ) for kernels  2.6.18-238.28.1.el5 and above breaks the fencing function for the Veritas Cluster Server product when VxFEN SCSI3 disk based fencing is configured in DMP mode.

Error Message

# vxfenconfig -c
Log Buffer: 0xffffffff88e5c2c0

VXFEN vxfenconfig NOTICE Driver will use SCSI-3 compliant disks.
VXFEN vxfenconfig ERROR V-11-2-1134 Ioctl failed
VXFEN vxfenconfig ERROR V-11-2-1134 Ioctl failed
 

Cause

With recent kernel security fix 752375 ( CVE-2011-4127 kernel: possible privilege  escalation via SG_IO ioctl ) SCSI READ/WRITE BUFFER IOCTL are no longer allowed to disk partitions. When using DMP mode for vxfenmode,  configuration populates the vxfentab file with the coordinator disk dmpnode names which include the partition/slice 3. Due to the kernel security fix, the ioctl to a device partition now fails and vxfen is unable to configure SCSI3 fencing.

Solution

The permanent fix for this problem is included in the following patches and will be included in all later GA patches:

vcs-rhel5_x86_64-VRTSvxfen-5.0MP4RP1P1 -

https://sort.veritas.com/labs/vpcs/vpcs/patchinfo/6237
 

vcs-rhel5_x86_64-VRTSvxfen-5.1SP1RP2P1a -

https://sort.veritas.com/labs/vpcs/vpcs/patchinfo/6171
 

vcs-rhel6_x86_64-VRTSvxfen-5.1SP1RP2P1 -

https://sort.veritas.com/labs/vpcs/vpcs/patchinfo/6169
 

vcs-rhel5_x86_64-VRTSvxfen-60RP1P1 -

https://sort.Veritas.com/patch/detail/6199
 

vcs-rhel6_x86_64-VRTSvxfen-60RP1P1 -

https://sort.Veritas.com/patch/detail/6200

 

It is strongly recommended to apply the permanent fix for this issue, but however, the following two workarounds are also available:

1.) Configure vxfenmode in raw mode.

# cp /etc/vxfen.d/vxfenmode_scsi3_raw /etc/vxfenmode

Note: A reboot will be required after making the change or manually unconfigure fencing and reconfigure fencing.

 

OR

 

2.) Remove the partition/slice from the device specification in /etc/vxfentab to use the whole dmpnode device.

    a. Stop the cluster `/opt/VRTS/bin/hastop -all`

    b. Manually unconfigure fencing on all nodes `/sbin/vxfenconfig -U`.

    c. Modify /etc/vxfentab and remove "s3" from the dmpnode names if using ebn (enclosure based names) scheme. If using osn (operating system names) scheme remove the "s3" from the dmpnode names.

Example:

# cat /etc/vxfentab
#
# /etc/vxfentab:
# DO NOT MODIFY this file as it is generated by the
# VXFEN rc script from the file /etc/vxfendg.
#
/dev/vx/rdmp/emc_clariion0_59s3
/dev/vx/rdmp/emc_clariion0_60s3
/dev/vx/rdmp/emc_clariion0_62s3

- Edit file contents

# cat /etc/vxfentab
#
# /etc/vxfentab:
# DO NOT MODIFY this file as it is generated by the
# VXFEN rc script from the file /etc/vxfendg.
#
/dev/vx/rdmp/emc_clariion0_59
/dev/vx/rdmp/emc_clariion0_60
/dev/vx/rdmp/emc_clariion0_62

   d. Manually configure fencing with command `/sbin/vxfenconfig -c`

Note: This Workaround  is not persistent across reboots.

 


Applies To

RHEL5 kernel  2.6.18-238.28.1.el5 and later

RHEL6  kernel 2.6.32-220.2.1.el6 or later

Storage Foundation HA (High Availability) 5.x and later, specifically if VxFEN SCSI3 fencing is configured in DMP mode. 

References

Etrack : 2704441

Was this content helpful?