Linux Kernel Developers Were Not Amused By Faulty Patches Sent By University of Minnesota Researchers
Researches at the American University of Minnesota submitted a series of faulty patches to the Linux kernel last year and published a research paper about their effort. They tried to send more faulty patches to the Linux Kernel Mailing List earlier this month. Greg Kroah-Hartman, Trond Myklebust and other seasoned kernel developers were not amused.
written by 林慧 (Wai Lin) 2021-04-22 - last edited 2021-04-22. © CC BY
drivers/infiniband/sw/rdmavt/qp.c in Linux 5.11.15 with code from a malicious patch submitted by researches at the American University of Minnesota. The kernel developers bought that one hook, line and sinker.
The Linux kernel is a huge software project with nearly thirty million lines of code and hundreds of patches floating around on the Linux Kernel Mailing List (LKML) at any given time. Some patches are included, some are flat out rejected, and some go through eight or more revisions before they are accepted.
Ph. D. student Qiushi Wu and assistant professor Kangjie Lu at the American University of Minnesota wanted to learn just how easy it is to get intentionally faulty patches past the Linux kernel maintainers and into the mainline Linux kernel. They came up with a "vulnerability-introducing method", used it to send patches introducing bugs and security holes and then they published a research paper on it titled "Open Source Insecurity: Stealthily Introducing Vulnerabilities via Hypocrite Commits" (OpenSourceInsecurity.pdf, 443 KiB) on February 10th, 2021.
The "Vulnerability-introducing method" by Ph.D student Qiushi Wu and assistant professor Kangjie Lu at the American University of Minnesota.
The researches at the American University of Minnesota were not content with wasting the Linux kernel community's time by experimenting on them for the purpose of writing just one research paper. They just had to try again with a useless patch titled [PATCH] SUNRPC: Add a check for gss_release_msg on April 6th, 2021. That patch reads:
diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
index 5f42aa5fc612..eb52eebb3923 100644
--- a/net/sunrpc/auth_gss/auth_gss.c
+++ b/net/sunrpc/auth_gss/auth_gss.c
@@ -848,7 +848,8 @@ gss_pipe_destroy_msg(struct rpc_pipe_msg *msg)
warn_gssd();
gss_release_msg(gss_msg);
}
- gss_release_msg(gss_msg);
+ if (gss_msg)
+ gss_release_msg(gss_msg);
}
static void gss_pipe_dentry_destroy(struct dentry *dir,
--
The patch was sent by Aditya Pakki <pakki001@umn.edu and purpose of the patch was described as:
"The patch adds a check to avoid a potential double free."
Kernel developer Trond Myklebust, from cloud storage provider HammerSpace, saw right through it.
"NACK. There's no double free there."
April 8th, 2021
And kernel developer Guenter Roeck didn't fall for it:
"I know I am adding to the noise here, but it has to be said:
gss_msg is assigned with
struct gss_upcall_msg *gss_msg = container_of(msg, struct gss_upcall_msg, msg);
and thus never NULL."
April 21st, 2021
What followed is almost amusing. Olga Kornievskaia <aglo@umich.edu> (probably the same person) promptly replied with a bogus claim there is a double free and another useless patch:
"I disagree that there is no double free, the wording of the commit describes the problem in the error case is that we call gss_release_msg() and then we call it again but the 1st one released the gss_msg. However, I think the fix should probably be instead:
if (msg->errno == -ETIMEDOUT)
warn_gssd();
- gss_release_msg(gss_msg);
+ return gss_release_msg(gss_msg);
}
Trond Myklebust wasn't buying it and neither was Greg Kroah-Hartman who wrote that:
"If you look at the code, this is impossible to have happen.
Please stop submitting known-invalid patches. Your professor is playing around with the review process in order to achieve a paper in some strange and bizarre way.
This is not ok, it is wasting our time, and we will have to report this, AGAIN, to your university..."
April 20th, 2021
A brief discussion around it followed and Greg Kroah-Hartman and the kernel developers decided that it would be best to revert all patches submitted from them the University of Minnesota and essentially ban them from participating in Linux kernel development:
"Because of this, all submissions from this group must be reverted from the kernel tree and will need to be re-reviewed again to determine if they actually are a valid fix. Until that work is complete, remove this change to ensure that no problems are being introduced into the codebase.
(..)
I'll take this through my tree, so no need for any maintainer to worry about this, but they should be aware that future submissions from anyone with a umn.edu address should be by default-rejected unless otherwise determined to actually be a valid fix (i.e. they provide proof and you can verify it, but really, why waste your time doing that extra work?)"
April 21nd, 2021
The research was, in one way, useful even though it was mostly a complete waste of everyone's time. Some in the The Linux kernel community pointed out that they really do need do a better job at reviewing small and seemingly trivial patches. The University of Minnesota managed to sneak more than 200 different patches, mostly one or two-liners, into the mainline Linux kernel. That's a lot.
"We do need to do a better job of reviewing patches, even "trivial" ones, and if that means that we might need to be a bit more skeptical dealing with newbies who are trying to get started, that's a price we will need to pay. Speaking for myself, I've always tried to be highly skeptical about patches and give them a thorough review. And I don't need to assume malice from nation-state intelligence agencies; we're all human, and we all make mistakes."
April 21nd, 2021
A better patch review process would probably be a good idea. An e-mail address like pakki001@umn.edu should raise some red flags, regardless of what it is used for, and it will now that the kernel developers are aware of the "research" done at the University of Minnesota. But it is, as Theodore Ts'o pointed out, easy to make all kinds of other e-mail addresses..
"UMN researchers could just start using fake e-mail addresses, or start using personal gmail or yahoo or hotmail addresses. (Hopefully at that point the ethics review boards at UMN will be clueful enough to realize that maybe, just maybe, UMN researchers have stepped over a line.)"
April 21nd, 2021
We do hope the Linux kernel community learns from this because we would not be shocked if other "researches" from other Universities get strange ideas about potential research they could do when they read the "Open Source Insecurity: Stealthily Introducing Vulnerabilities via Hypocrite Commits" paper. It is also fair to wonder why the middle kingdoms true masters of those "Ph.D students" and "assistant professors" at the University of Minnesota made them enter this field and do this research to begin with.
Enable comment auto-refresher