[Copy-Fail] Debunking owLSM CVE-2026-31431 Mitigation: 90 upvotes and no security

Posted by LeChatP@reddit | linux | View on Reddit | 21 comments

Since the reddit post by owLSM owners regarding Copy-Fail was published, I saw almost 90 upvotes on it and none of these upvoters actually checked under the hood of this "solution".

I want to completely debunk this solution here.

First, I argued about why this is wrong in comments there, I don't think it is necessary to duplicate arguments here. I got few upvotes. So I mainly think that people were skeptical about my comment, maybe my explanations are, I don't know, too complex maybe?

Paths to bypass the owLSM mitigation

So today, I decided to make a demo that completely bypass their "mitigation", just for fun, it is not so difficult, and proved by several people in comments section. All those comments still got few upvotes.

I was first think about something using run0, that is not using setuid at all, but only DBus communication, but it is not so widely applicable on minimal cloud images. Then I thought to rewrite pam_unix.so at location where pam_sm_authenticate call with a return 0; in order to avoid completely the password check. But in order to not be triggered by owLSM, it needs to use SSH with root login allowed, and minimal images generally disables it.

So last thought : motd feature, this is still implemented in ubuntu cloud minimal and executed by root. So I thought, all I need is to rewrite /etc/update-motd.d/00-header file to insert a local bind-shell and then connect to it with a simple client.

All of these solutions are trivial when you are performing pentest, I believe there are many other ways to obtain ruid=0 without using SUID.

Finally, nothing such complex is necessary

And guess what? I found an awesome github account that uses an elegant way to perform the exploit here named Crihexe who decided to make the most tiny exploit. And this exploit, is way more elegant than the Copy-fail first PoC.

The exploit is rewriting the credentials of the current process to set directly ruid=0, so all it needs to do is execve /bin/sh at the end and you're root, leaving the LSM completely blind.

Since people are still skeptical, I decided to install owLSM and test it against Crihexe's exploit. Fortunately, the project already ships with all the tools needed to test it inside a VM. Only a few modifications were needed to get owLSM working... and done!

I forked the repo here, enable owLSM ; which is btw unsafe and insecure as what I saw during my installation process ; Anyway, I tried the exploit... and it just works even with owLSM policy enabled. I did it in livestream! So here is the clip to show you that the mitigation just does not work

Discussion

We all make mistakes. That's OK. But unfortunately, owLSM owner decided to make some advertisement on this big mistake. This is problematic because it damages the credibility of the project.

Also saw that the project is AI vibe-coded as long Cursor is contributor of the project. So my guess is that owLSM owners asked their AI if their idea were working, and the AI said naively yes. Thus, making them in the wrong direction from the start.

Conclusion

None of my conclusions are satisfying myself. I wanted to make this publication because it was important for me to explain to all those upvoters that what they thought was security was actually flawed. Just be careful next time.