One way to detect when this has occurred is to use fstatfs() [0]: it will tell you whether an fd truly belongs to a procfs, or whether it belongs to some other kind of filesystem. Of course, you still have the issue of one part of a procfs being bind-mounted onto another part of a procfs (or onto a different procfs). For that, one mitigation is to double-check the st_dev of every file down the chain. But it still doesn't guarantee that you haven't been led into a recursive bind-mount: for that you have to use tricks like checking rename() error codes, or some of the fancy new openat2() flags, to test the absence of a mount-point boundary.
Personally, my stance is to just blindly trust whatever /proc tells you, except in really unusual security models. Users can only end up hurting themselves by putting nonsensical things in there. (The same way no one should bother checking that /dev/null isn't a regular file, even though root can easily make it one.)
The Unix philosophy is "everything is a file". But maintaining that abstraction indirectly leads to edge cases like this where devs may be thinking in terms of a FILESYSTEM but some of the files are, in reality, a SYSCALL API/RPC INTERFACE. This makes every new filesystem feature a potential security risk. Is it worth the abstraction? I think so.
One of the solutions listed to discovering this is to investigate /proc/mounts and look for these type of mounts. Couldn't you use the same trick on /proc/mounts itself?
Could you use a unionfs like overlay2 for more advanced pid hiding?
Interesting. What are the legitimate use cases to not treat /proc as readonly, and what are legitimate use cases to mount around and especially bind-mount random filesystems around in /proc?
Like, my first impulse is "Why do we allow this?" And I guess, sure, the answer is "root is allowed to do this, because root is never not allowed". And sure I very much dislike my computer telling me "Nay I cannot do that", hence why I have no windows anymore at home.
But there is some stuff that seemingly doesn't have any legitimate use case on a server. And even if protections from that stuff keep me from fixing some situations, I can still nuke and rebuild it in an hour or so.