After applying Solaris 10 8/11 (Update 10) / Solaris OS kernel patch 147440-04 or superseding patches (147440-05 or 147440-06 ) on Solaris sparc or 147441-04 on Solaris 10 x86 on a system with swap device under VxVM’s control as an encapsulated device, the system can recursively panic with the following stack trace displayed on the console:
vxio:vxioioctl+0x4c0(, , , , 0x60010803ea8, 0x0)
specfs:spec_ioctl(0x600117a9100, 0x403, 0x2a100959714, 0xffffffff80000000, 0x60010803ea8) - frame recycled
genunix:fop_ioctl+0x20(0x600117a9100, 0x403, 0x2a100959714, 0xffffffff80000000, 0x60010803ea8, 0x0)
genunix:swapify+0x6c(0x60011fd8a00, 0x1)
genunix:swapadd+0x5b8(, , 0x0, 0x60011673700)
genunix:swapctl+0x88c(0x1, 0xffffffff7ffff2e8, 0x2a100959adc)
genunix:uadmin+0x34(, 0x1)
unix:syscall_trap+0xac()
The mentioned Solaris kernel patches introduced a new routine named swapify() which passes a NULL pointer argument to VxVM driver’s vxioioctl() routine. The VxVM driver module assumes that such argument which is used to extract the return value from a device ioctl cannot be NULL, so it results in a panic due to a NULL pointer dereference.
(a) Workaround
Un-encapsulate the swap device using the following steps:
Send a break signal from console.
Boot in failsafe mode:
ok> boot -F failsafe
If the failsafe boot does not mount the root partition on /a:
# mount /dev/dsk/c#d#d#s0 /a
# cd /a/etc
# cp vfstab vfstab
# cp system system
# cp vfstab.prevm vfstab
Comment out the 2 lines in the system file:
*rootdev:/pseudo/vxio@0:0
*set vxio:vol_rootdev_is_volume=1
Boot:
# reboot
(b) Temporary Solaris kernel patch solution
Through the change request, CR 7108029, Oracle backed out the swapify() code in Solaris space Kernel Patch 147440-07 and Solaris x86 Kernel Patch 147441-13. So 147440-07 on sparc and 147441-13 on x86 can be a temporary patch solution. However, please note that the risk with it is that Oracle plans to re-introduce the code change in the future patches which can lead to panic.
(c) Permanent patch solution from Veritas
Veritas has addressed this issue in latest VxVM patches on both Solaris sparc and x86 platforms:
(i) Recommendation for 5.0 release track: VxVM 5.0MP3RP5HF8 & later. Please contact Veritas support to obtain hotfix patches.
(ii) Recommendation for 5.1 release track: VxVM 5.1SP1RP2P3 & later GA patches. Please refer to the Infoscale https://docs.infoscale.com/ website to download the latest GA patches.
Applies To
Any version of VxVM (except the latest patches mentioned in the permanent solution section of this article) running on Solaris 10 sparc with OS kernel patch (147440-04, 147440-05, or 147440-06) or Solaris 10 x86 with OS kernel patch 147441-04 (can be verified with the 'uname -a' command) and swap device under VxVM’s control (can be verified with a 'swap -a' command if any of the devices contain "/dev/vx/[r]dsk/" string) are vulnerable to this panic.
If any of the Solaris sparc kernel patches (147440-04, 147440-05, or 147440-06) or Solaris x86 patch (147441-04) is applied to a system with swap device under Veritas/Veritas Volume Manager’s (VxVM) control, it can cause the system to panic.
ETrack: 2642377