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.
