Checking `lkm'... You have 6 process hidden for readdir command
This message comes from the chkproc binary.
Code:
]$ grep -a readdir /usr/local/sbin/chkproc
/proc/%dPID %5d: not in readdir output
You have % 5d process hidden for readdir command
Chkproc checks "ps" output with process dirs in /proc.
Some processes are shortlived and die before chkproc can check 'em.
Then chkproc shows an error.
If you want to doublecheck, you could rerun Chkrootkit with the "lkm" test, or run "check_ps". If there's a secondary indication (from running a filesystem integrity scanner for instance) that indicates tampering, then you could be looking at a Linux Kernel Module (LKM). Isolating the box from the network by dropping to runlevel 1 and then checking syscall diversion (kern_check: see Samhain site) could be one option, but hard powering off the box, booting a kernel from a rescue cdr/floppy and then checking the filesystem (in read-only mode) is better. Granted, you loose checking active processes, but if there's malicious activity chances to find it are "better" on a dead system because then system calls can't be redirected.
After reading about what the problem might be, I tried to query the /bin/ls file using rpm tool.
For some reason it was telling me my db was not accessible and the file didn't not belong to a package. I rebooted the system in rescue mode and force installed the coreutilits package.
With all due respect, but reinstall until it works, that's "MICROS~1" behaviour.
Besides that, if there's a system compromise you most likely do not want to delete "evidence": kill the system, then check.
"Just tried it on my 2.6.0, didn't find a thing."
Wrt errors there's always two distinctly different issues to focus on: troubleshooting Chkrootkit and its binaries, and determining system status. If you don't know what to contribute an error to, please be cautious. It's "better" to have to check and know system status is OK than to ignore it.
