My last name is Spengler (no idea why people assume my alias is my last name). The analysis of the exploit appears correct however.
The choice of the tun file_operations struct was arbitrary: a different one could have been chosen if the attacker wanted the exploit to work against a custom kernel with CONFIG_DEBUG_RODATA enabled. As I've found, since 2007 when most of those structs were made const, people haven't kept up with the standard, so there are a ton of other reliable function pointers to choose from.
The nature of the NULL tun pointer being confined to the tun_chr_poll() function (instead of getting leaked out through some means to other complex functions in the kernel) is what makes the vulnerability 100% reliably exploitable.