> The bad news is, override_creds isn't going to fix this, because current->fs > isn't part of the creds. It's still going to be null (h/t jhutz) > The less bad news is, I think this will only affect closing a deleted file. > Other operations should not trigger cache I/O after a flush. (exit_files, > which occurs before exit_fs, called flush and fput, but fput these days > doesn't do the work immediately, it punts it to task_work). So if we punt > the unlink of a sillyrenamed file to a kthread, we should be able to avoid > this problem. > > But we may have other issues. > If crowdstrike is validating dentry_open against current->fs->root, it might > deny cache I/O done on behalf of a chroot'd (or namespaced) process. We > can't solve that without punting ALL cache I/O to a kthread.
[Resending, as originally this sent with uuencoded, which the mail list archives don't handle well. Hopefully it's OK this time.] I think the key thing to prevent this crash is just to avoid triggering an LSM hook during process context. If you see other issues with falcon but are following all the upstream Linux kernel driver guidance, please contact me (or CrowdStrike more generally) and we'll be happy to work with you.
smime.p7s
Description: S/MIME cryptographic signature
