They also suggest an alternative to storing the function pointer, store the bit flags that decide which function to call. That restricts the call targets to only the legitimate ones intended.
The interesting thing is obviously not that you can get code to run at high privilege level by modifying a system component. I mean, duh, as it were.
The interesting thing is that the attackers (almost) got downstream Linux distros to suck down and deploy that malicious component for them. And that's not down to an oddball glibc feature, it happened because they got some human beings to trust a malicious actor. GNU glibc can't patch that!
[1] Incorrectly, as you point out.
The article mentions this, and also points to mprotect which you can use to protect the pointer.
Why people jump to criticize without reading first? BTW, you can ask an LLM to check your critique, before posting, if you don't want to read the text.
1. It impiles some function pointers to be writable temporarily, not all of them.
2. It doesn't hide writable pointers from a cursory glance not familiar with IFUNC.