[ Just upgraded my server to bullseye, and aide started to fail, now noticed this report, after also hitting the error via lsattr. ]
On Mon, 2021-04-05 at 17:35:54 -0400, Theodore Ts'o wrote: > On Mon, Apr 05, 2021 at 12:46:48AM +0200, Chris Hofstaedtler wrote: > > AFAICT, for /dev/dri/card0 the ioctl ends up in the kernel's > > drm_ioctl [2], which will blindly call copy_to_user assuming the > > output size is the same as the input size (8 bytes). This is wrong > > for FS_IOC_GETFLAGS, at least for normal files. > > > > Maybe the best thing is to put the lstat check back in? > > Or maybe lsattr should expect that the kernel might actually use the > > 8 bytes? I have checked various fs ioctl functions, and they all > > seem to return 4 bytes, except for orangefs [3] ... > > What's going on is that apparently there is an overlap between the > ioctl code FS_IOC_GETFLAGS (aka EXT2_IOC_GETFLAGS) and some ioctl code > used by device driver responding to /dev/dri/card0, in drm_ioctl. I > had the vague thought that at some point, we might be able to set and > get file system flags on device files, which is why I removed the > lstat check. I wasn't counting on the fact that there would be ioctl > code collisions --- which in retrospect, was hopelessly optimistic on > my part. So, while I was trying to debug this in aide on my server, after having added few aide ignore entries for specific devices, at some point while within gdb, I suddenly lost the ssh connection as the server suddenly rebooted, for which I was very puzzled, and paranoid! What you mention above, of colliding IOCTL codes would actually explain the cause of the reboot, if it ends up hitting an IOCTL setting some wrong state somewhere. I also noticed this being an issue with at least /dev/kfd, but I'm not very eager to try this again there to determine what other devices this might affect, if this can result in sending random commands to random devices on the live server. :/ > So yeah, we need to put the lstat check back in. > Fortunately, the fortify compile option detectsd the stack smash, so > it's not critical that we get this fixed ASAP, but we ultimately do > need to put the lstat check back in. I'd appreciate if this could be done sooner rather than later, and it seems to me it probably deserves a higher severity. (I've for now disabled aide to avoid any crashes or strange behavior.) Thanks, Guillem
