fanotify will clear ignore marks if a task changes the contents of aninode. The problem is with the races around when userspace finisheschecking a file and when that result is actually attached to the inode.This race was described as such:

Consider the following scenario with hostile processes A and B, andvictim process C:1. Process A opens new file for writing. File check request is generated.2. File check is performed in userspace. Check result is "file has no malware".3. The "permit" response is delivered to kernel space.4. File ignored mark set.5. Process A writes dummy bytes to the file. File ignored flags are cleared.6. Process B opens the same file for reading. File check request is generated.7. File check is performed in userspace. Check result is "file has no malware".8. Process A writes malware bytes to the file. There is no cached response yet.9. The "permit" response is delivered to kernel space and is cached in fanotify.10. File ignored mark set.11. Now any process C will be permitted to open the malware file.There is a race between steps 8 and 10

While fanotify makes no strong guarantees about systems with hostileprocesses there is no reason we cannot harden against this race. We dothat by simply ignoring any ignore marks if the inode has open writers (akai_writecount > 0). (We actually do not ignore ignore marks if theFAN_MARK_SURV_MODIFY flag is set)