Kangjie Lu

There appears to be a disconnect. Their FAQ says otherwise. > We did not introduce or intend to introduce any bug or vulnerability in the Linux kernel. All the bug-introducing patches stayed only in the email exchanges, without being adopted or merged into any Linux branch, which was explicitly confirmed by maintainers. Therefore, the bug-introducing patches in the email did not even become a Git commit in any Linux branch. None of the Linux users would be affected. The following shows the specific procedure of the experiment. [1] https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf [1]

No bugs were introduced and they didn't intend to introduce any bugs. infact, they have resolved over 1000+ bugs in the linux kernel. >> https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf "We did not introduce or intend to introduce any bug or vulnerability in the Linux kernel. All the bug-introducing patches stayed only in the email exchanges, without being adopted or merged into any Linux branch, which was explicitly confirmed by maintainers. Therefore, the bug-introducing patches in the email did not even become a Git commit in any Linux branch. None of the Linux users would be affected. The following shows the specific procedure of the experiment"

In a follow-up [1], the author suggests: OSS projects would be suggested to update the code of conduct, something like “By submitting the patch, I agree to not intend to introduce bugs” How can one be so short-sighted?... [1] https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf

https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf posted some clarifications around this, worth a read

I don't think there have been any recent comments from anyone at U.Mn. So, back when the original research (happened last year) the following clarification was offered by Qiushi Wu and Kangjie Lu which atleast paints their research in somewhat better light: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf That said the current incident seems to have gone beyond the limits of that one and is a new incident. I just thought it would be fair to include their "side"

> We just want you to know that we would never intentionally hurt the Linux kernel community and never introduce security vulnerabilities. Our work was conducted with the best of intentions and is all about finding and fixing security vulnerabilities. Either this is a bald-faced lie or they didn't think through the implications of their research, neither of which bode well for their trustworthiness in future. However, if it's the latter, then they possibly deserve additional leeway. On the other hand, I wonder whether this letter would have eventuated without the ban - if not, then they've likely been forced to write it, in which case any remorse is either selfish (i.e. they've been professionally reprimanded and feel bad about getting caught, or making such an egregious error in judgement), or hollow. > I agree, but let's give them a little extra benefit of the doubt. I thought as I was reading it that it seemed stilted and forced, then I wondered if the author(s) don't speak / write English as a primary language. https://www-users.cs.umn.edu/~kjlu/ It looks like you might be right about this, but I think that reading it as stilted and forced is still accurate.

They did not secretly introduce exploitable bugs: Once any maintainer of the community responds to the email,indicating “looks good”,we immediately point out the introduced bug and request them to not go ahead to apply the patch. At the same time, we point out the correct fixing of the bug and provide our proper patch. In all the three cases, maintainers explicitly acknowledged and confirmed to not move forward with the incorrect patches. This way, we ensure that the incorrect patches will not be adopted or committed into the Git tree of Linux. https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf > If it quacks like a duck and waddles like a duck, then it is a duck. A lot of horrible things have happened on the Internet by following that philosophy. I think it's imperative to learn the rigorous facts and different interpretations of them, or we will continue to great harm and be easily manipulated.

Yes, I am saying that, and I don't know what "proof" you want? He isn't cited in the paper, he didn't work on the research. But here you go if you want to read more about the research. You'll notice that the messages/ patches are all attributed to those cited in the paper. https://www-users.cs.umn.edu/~kjlu/papers/full-disclosure.pdf And yes, you are being misled. That's why Greg needs to publicly retract his accusation and apologize. That's why it's so frustrating that LWN did not clearly explain that Greg was flat out wrong.

At least according to the researcher’s letter[1], the UMN IRB did look at the study after the fact and determined approval wasn’t needed. > The IRB of UMN reviewed the study and determined that this is not human research (a formal IRB exempt letter was obtained). [1] https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf

The guy is still putting the blame on the Kernel project for not having a "don't submit bugs" clause.[1] And insists it was not human research. [1] How can this type of people be professors? [1] https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf

So the professor in center of this event, Kangjie Lu[0] is also program comitee at IEEE S&P 2021.[1] I'm by no means an security expert nor a kernel contributor but considering he's program comitee, is these kind of practices a common place in Security/Privacy researchers? Does idea/practises like this get a pass on conference publishing regularly? [0] https://www-users.cs.umn.edu/~kjlu/ [1] https://www.ieee-security.org/TC/SP2022/cfpapers.html

There does appear to be a static analysis tool. https://www-users.cs.umn.edu/~kjlu/papers/eecatch.pdf?fbclid=IwAR0isr1… Still, given that he is 4+ years into a PhD (after a Masters), and has published on this topic before, his first deflection is "We are not experts in the linux kernel" seems disingenuous - kinda like "Hey guys, I'm not malicious, just not good at my job."

He's not an adjunct. https://www-users.cs.umn.edu/~kjlu/ Adjuncts don't have Ph.D students.

>>>On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits Qiushi Wu, and Kangjie Lu. To appear in Proceedings of the 42nd IEEE Symposium on Security and Privacy (Oakland'21). Virtual conference, May 2021. from Lu's list of publications at https://www-users.cs.umn.edu/~kjlu/ Seems like a conference presentation at IEEE at minimum?

Interesting tidbit from the prof's CV where he lists the paper, interpret from it what you will[1]: > On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits > Qiushi Wu, and Kangjie Lu. > To appear in Proceedings of the 42nd IEEE Symposium on Security and Privacy (Oakland'21). Virtual conference, May 2021. > Note: The experiment did not introduce any bug or bug-introducing commit into OSS. It demonstrated weaknesses in the patching process in a safe way. No user was affected, and IRB exempt was issued. The experiment actually fixed three real bugs. Please see the clarifications[2]. 1: https://www-users.cs.umn.edu/~kjlu/ 2: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf

Some clarifications since they are unclear in the original report. - Aditya Pakki (the author who sent the new round of seemingly bogus patches) is not involved in the S&P 2021 research. This means Aditya is likely to have nothing to do with the prior round of patching attempts that led to the S&P 2021 paper. - According to the authors' clarification [1], the S&P 2021 paper did not introduce any bugs into Linux kernel. The three attempts did not even become Git commits. Greg has all reasons to be unhappy since they were unknowingly experimented on and used as lab rats. However, the round of patches that triggered his anger *are very likely* to have nothing to do with the three intentionally incorrect patch attempts leading to the paper. Many people on HN do not seem to know this. [1] https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf

The prof overseeing the paper clarified that they initially did not seek IRB approval, and then received an IRB exemption [0]. I'd want to ask the IRB why they approved that, for starters. Maybe because they'd already done the research and hoped it would blow over, vs. the controversy of rejecting it when they'd already done the work? 0: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf

According to their website[0]: > IRB exempt was issued [0]: https://www-users.cs.umn.edu/~kjlu/

This is not what happened according to them: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf > (4). Once any maintainer of the community responds to the email, indicating “looks good”, we immediately point out the introduced bug and request them to not go ahead to apply the patch. At the same time, we point out the correct fixing of the bug and provide our proper patch. In all the three cases, maintainers explicitly acknowledged and confirmed to not move forward with the incorrect patches. This way, we ensure that the incorrect patches will not be adopted or committed into the Git tree of Linux.

> I don't have data to back this up, but I've been around a while and I can tell you papers are rejected from conferences for ethics violations. IEEE seems to have no problem with this paper though. >>> On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits Qiushi Wu, and Kangjie Lu. To appear in Proceedings of the 42nd IEEE Symposium on Security and Privacy (Oakland'21). Virtual conference, May 2021. from https://www-users.cs.umn.edu/~kjlu/

background for those unfamiliar with this: https://news.itsfoss.com/hypocrite-commits/ and Kangjie Lu's response: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf

They apparently made a tool to find vulnerabilities that could later lead to bugs is a different patch was introduced. And for some insane reason, they decided to test if these kinds of bugs would be caught by inventing some and just submitting the patches, without informing anyone beforehand. https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf

From the researchers: > In the past several years, we devote most of our time to improving the Linux kernel, and we have found and fixed more than one thousand kernel bugs; the extensive bug finding and fixing experience also allowed us to observe issues with the patching process and motivated us to improve it. Thus, we consider ourselves security researchers as well as OSS contributors. We respect OSS volunteers and honor their efforts. https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf It feels to me you have jumped to an untenable conclusion without even considering their point of view.

Clarification from their work that was posted on the professor's website: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf

It didn't. Rather, it didn't until after it had been conduct. https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf

> The IRB of University of Minnesota reviewed the procedures of the experiment and determined that this is not human research. I'm not sure how it affects things, but I think it's important to clarify that they did not obtain the IRB-exempt letter in advance of doing the research, but after the ethically questionable actions had already been taken: The IRB of UMN reviewed the study and determined that this is not human research (a formal IRB exempt letter was obtained). Throughout the study, we honestly did not think this is human research, so we did not apply for an IRB approval in the beginning. ... We would like to thank the people who suggested us to talk to IRB after seeing the paper abstract. https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf

I hope USENIX et al ban this student / professor / school / university associated with this work from submitting anything to any of their conferences for 10 years. This was his clarification https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf ...in which they have the nerve to say that this is not considered "human research". It most definitely is, given that their attack vector is the same one many people would be keen on using for submitting legitimate requests for getting involved. If anything, this "research" highlights the notion that coding is but a small proportion of programming and delivery of a product, feature, or bugfix from start-to-finish is a much bigger job than many people like to admit to themselves or others.

My understanding in this case is not that the IRB declined to review the study plan, but that (quoting the study authors) "The IRB of UMN reviewed the study and determined that this is not human research (a formal IRB exempt letter was obtained)." (more information here: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf) Do you think that the IRB was correct to make the determination they did? It does sound like a bit of a grey area

I asked Kangjie Lu to explain the original complain. Here is his reply from Wednesday: —- Thanks for sharing. The statements in the link are wrong. I will make some clarifications. 1. We have never intentionally introduced any bugs in Linux. 2. The project that investigated the issues with OSS patching process was done in November 2020. We did get an IRB letter for the research. The purpose of the research is to improve the security of the OSS patching process. 3. One of my students is working on a different project which has nothing to do with the project mentioned in 2. The student aims to fix problems in Linux instead of introducing problems. If you are interested in the project mentioned in 2, please find more details here: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf I hope these clarify the misunderstandings. Kangjie Lu Assistant Professor Department of Computer Science and Engineering University of Minnesota https://www-users.cs.umn.edu/~kjlu —-

Here's a clarification from the Researchers over at UMN[1]. They claim that none of the Bogus patches were merged to the Stable code line : >Once any maintainer of the community responds to the email,indicating “looks good”,we immediately point out the introduced bug and request them to not go ahead to apply the patch. At the same time, we point out the correct fixing of the bug and provide our proper patch. In all the three cases, maintainers explicitly acknowledged and confirmed to not move forward with the incorrect patches. This way, we ensure that the incorrect patches will not be adopted or committed into the Git tree of Linux. I haven't been able to find out what the 3 patches which the reference are, but the discussions on Greg's UMN Revert patch [2] does indicate that some of the fixes have indeed been merged to Stable and are actually Bogus. [1] : https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf [2] : https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoun…