No, this whole drama proves that Linux has a rubber stamping process in place, which is not quite the same as review.
This seems to be the patch that directly triggered Greg's rage:
Subject: [PATCH] SUNRPC: Add a check for gss_release_msg
Date: Tue, 6 Apr 2021 19:16:56 -0500
Message-ID: <20210407001658.2208535-1-pakki001@umn.edu> (raw)
In gss_pipe_destroy_msg(), in case of error in msg, gss_release_msg
deletes gss_msg. The patch adds a check to avoid a potential double
free.
Signed-off-by: Aditya Pakki <pakki001@umn.edu>
---
net/sunrpc/auth_gss/auth_gss.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
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);
}
It's pointless because gss_msg is a refcounted object and you can't double-free it by calling gss_release_msg - that's how they explained the problem on the mailing list.
If a reviewer misses that then he will miss everything. And if the actual maintainer of the code in question misses it, then what's wrong with a student missing it when he saw such suspiciously looking code in the output of a static analyzer?