I assume individual members from UMN may still contribute without a UMN address. They just won't be given any special consideration (implicit or explicit) as belonging to a particular organization.
But looking into this and clearly documenting it is part of what UMN needs to do.
The question then, is what to do about this much larger scale problem, not to simply assert the premise is wrong.
This, but not derisively. Note that the university's IRB granted an exception for this behavior, and neither UMN nor the department responded with consideration for the concerns raised by the kernel team until after they banned the whole domain.
UMN is ultimately responsible for the actions of the people under their organization. This include oversight and dealing with the actions of those people when they have crossed lines.
Umm, there's etiquette in academia too you know... even FOSS etiquette in academia.
A fellow researcher intentionally pushing bad data into a colleague's study as some kind of penetration test on the colleague's scientific methodology would be justifiably seen as betrayal, and a possibly bad faith betrayal at that since research grants are a finite resource.
The researchers in the story appear to have failed to extrapolate that sort of collegial courtesy to the open source community maintaining Linux.
It's not really surprising a bunch of academic-types were too far removed from open source etiquette - that removal is pretty much the source of the drama (this entire thing would've been avoided if a few key people were informed ahead of time).
My other take away is that it seems social engineering still is the most powerful type. From this to the Twitter fiasco - it's worth trying to make your workflow resilient against social engineering indeed - by the authors own admission, the process leans a bit too much towards pre-established trust and credibility. Unfortunately that trust isn't immutable, nor is it everlasting so it's a spot that can be exploited.