Activity log for bug #296302

Date Who What changed Old value New value Message
2008-11-10 13:11:18 Peter Wainwright bug added bug
2008-11-10 19:37:19 Peter Wainwright description My nightly tripwire check has been failing since I reinstalled some kernel modules at the beginning of November 2008. strace -eopen,access,lstat,lstat64 tripwire -m c lstat("/lib/modules/2.6.24-21-generic/ubuntu/wireless/wimax-i2400m/drivers/net/wimax/i2400m/i2400m.ko", {st_mode=S_IFREG|0644, st_size=59448, ...}) = 0 open("/lib/modules/2.6.24-21-generic/ubuntu/wireless/wimax-i2400m/drivers/net/wimax/i2400m/i2400m.ko", O_RDONLY) = 3 lstat("/lib/modules/2.6.24-21-generic/ubuntu/wireless/wimax-i2400m/drivers/net/wimax/wimax.ko", {st_mode=S_IFREG|0644, st_size=23352, ...}) = 0 open("/lib/modules/2.6.24-21-generic/ubuntu/wireless/wimax-i2400m/drivers/net/wimax/wimax.ko", O_RDONLY) = 3 lstat("/lib/modules/2.6.24-21-generic/volatile", {st_mode=S_IFDIR|0755, st_size=300, ...}) = 0 The object: "/lib/modules/2.6.24-21-generic/volatile" is on a different file system...ignoring. --- SIGSEGV (Segmentation fault) @ 0 (0) --- Software interrupt forced exit: Segmentation Fault Process 19513 detached I've checked, and it seems that /lib/modules/2.6.24-21-generic/volatile is a mounted tmpfs filesystem. It seems to cause tripwire to crash. root@ceiriog:prw# cat /proc/mounts | grep volatile tmpfs /lib/modules/2.6.24-21-generic/volatile tmpfs rw,relatime 0 0 (gdb) i s #0 0x00000000004d4b39 in cFCODataSourceIterImpl::CanDescend (this=0x17178f0) at fcodatasourceiterimpl.cpp:148 #1 0x000000000040ac05 in cIntegrityCheck::ProcessDir (this=0x7fff0ee57bc0, dbIter=@0x7fff0ee56780, pIter=0x17178f0) at integritycheck.cpp:299 #2 0x000000000040a23b in cIntegrityCheck::ProcessAddedFCO (this=0x7fff0ee57bc0, dbIter=@0x7fff0ee56ad0, pIter=0x9723a0, bRecurse=true) at integritycheck.cpp:94 #3 0x000000000040ae51 in cIntegrityCheck::ProcessDir (this=0x7fff0ee57bc0, dbIter=@0x7fff0ee56ce0, pIter=0x9723a0) at integritycheck.cpp:360 #4 0x000000000040ab10 in cIntegrityCheck::ProcessChangedFCO (this=0x7fff0ee57bc0, dbIter=@0x7fff0ee56fa0, pIter=0xb177c0, bRecurse=true) at integritycheck.cpp:235 #5 0x000000000040b263 in cIntegrityCheck::ProcessDir (this=0x7fff0ee57bc0, dbIter=@0x7fff0ee573f0, pIter=0xb177c0) at integritycheck.cpp:402 #6 0x000000000040ab10 in cIntegrityCheck::ProcessChangedFCO (this=0x7fff0ee57bc0, dbIter=@0x7fff0ee576f0, pIter=0x7ff750, bRecurse=true) at integritycheck.cpp:235 #7 0x000000000040ba5e in cIntegrityCheck::Execute (this=0x7fff0ee57bc0, flags=0) at integritycheck.cpp:536 #8 0x0000000000428c1d in cTWModeIC::Execute (this=0x7d85c0, pQueue=0x7fff0ee582f0) at twcmdline.cpp:1341 #9 0x000000000041a38c in main (argc=3, argv=0x7fff0ee58598, envp=0x7fff0ee585b8) at tripwiremain.cpp:235 In CanDescend, at the line: return ( (*mCurPos)->GetCaps() & iFCO::CAP_CAN_HAVE_CHILDREN ); gdb reports that (gdb) p *mCurPos $3 = (class iFCO * const&) @0x17dd2a8: 0x80 which is clearly not a valid pointer. However, I can't tell what this iterator thing is supposed to represent and I can't spare the time to debug further without more clues... My nightly tripwire check has been failing since I reinstalled some kernel modules at the beginning of November 2008. I'm running tripwire 2.3.1.2.0-11 on Ubuntu 8.04 with all updates applied. strace -eopen,access,lstat,lstat64 tripwire -m c lstat("/lib/modules/2.6.24-21-generic/ubuntu/wireless/wimax-i2400m/drivers/net/wimax/i2400m/i2400m.ko", {st_mode=S_IFREG|0644, st_size=59448, ...}) = 0 open("/lib/modules/2.6.24-21-generic/ubuntu/wireless/wimax-i2400m/drivers/net/wimax/i2400m/i2400m.ko", O_RDONLY) = 3 lstat("/lib/modules/2.6.24-21-generic/ubuntu/wireless/wimax-i2400m/drivers/net/wimax/wimax.ko", {st_mode=S_IFREG|0644, st_size=23352, ...}) = 0 open("/lib/modules/2.6.24-21-generic/ubuntu/wireless/wimax-i2400m/drivers/net/wimax/wimax.ko", O_RDONLY) = 3 lstat("/lib/modules/2.6.24-21-generic/volatile", {st_mode=S_IFDIR|0755, st_size=300, ...}) = 0 The object: "/lib/modules/2.6.24-21-generic/volatile" is on a different file system...ignoring. --- SIGSEGV (Segmentation fault) @ 0 (0) --- Software interrupt forced exit: Segmentation Fault Process 19513 detached I've checked, and it seems that /lib/modules/2.6.24-21-generic/volatile is a mounted tmpfs filesystem. It seems to cause tripwire to crash. root@ceiriog:prw# cat /proc/mounts | grep volatile tmpfs /lib/modules/2.6.24-21-generic/volatile tmpfs rw,relatime 0 0 (gdb) i s #0 0x00000000004d4b39 in cFCODataSourceIterImpl::CanDescend (this=0x17178f0) at fcodatasourceiterimpl.cpp:148 #1 0x000000000040ac05 in cIntegrityCheck::ProcessDir (this=0x7fff0ee57bc0, dbIter=@0x7fff0ee56780, pIter=0x17178f0) at integritycheck.cpp:299 #2 0x000000000040a23b in cIntegrityCheck::ProcessAddedFCO (this=0x7fff0ee57bc0, dbIter=@0x7fff0ee56ad0, pIter=0x9723a0, bRecurse=true) at integritycheck.cpp:94 #3 0x000000000040ae51 in cIntegrityCheck::ProcessDir (this=0x7fff0ee57bc0, dbIter=@0x7fff0ee56ce0, pIter=0x9723a0) at integritycheck.cpp:360 #4 0x000000000040ab10 in cIntegrityCheck::ProcessChangedFCO (this=0x7fff0ee57bc0, dbIter=@0x7fff0ee56fa0, pIter=0xb177c0, bRecurse=true) at integritycheck.cpp:235 #5 0x000000000040b263 in cIntegrityCheck::ProcessDir (this=0x7fff0ee57bc0, dbIter=@0x7fff0ee573f0, pIter=0xb177c0) at integritycheck.cpp:402 #6 0x000000000040ab10 in cIntegrityCheck::ProcessChangedFCO (this=0x7fff0ee57bc0, dbIter=@0x7fff0ee576f0, pIter=0x7ff750, bRecurse=true) at integritycheck.cpp:235 #7 0x000000000040ba5e in cIntegrityCheck::Execute (this=0x7fff0ee57bc0, flags=0) at integritycheck.cpp:536 #8 0x0000000000428c1d in cTWModeIC::Execute (this=0x7d85c0, pQueue=0x7fff0ee582f0) at twcmdline.cpp:1341 #9 0x000000000041a38c in main (argc=3, argv=0x7fff0ee58598, envp=0x7fff0ee585b8) at tripwiremain.cpp:235 In CanDescend, at the line: return ( (*mCurPos)->GetCaps() & iFCO::CAP_CAN_HAVE_CHILDREN ); gdb reports that (gdb) p *mCurPos $3 = (class iFCO * const&) @0x17dd2a8: 0x80 which is clearly not a valid pointer. However, I can't tell what this iterator thing is supposed to represent and I can't spare the time to debug further without more clues...