Kernel-hack-drill and exploiting CVE-2024-50264 in the Linux kernel

>Convinced the path forward would be painful, I shelved the bug.

As opposed to fixing the bug? Either the incentives are broken for security researchers to fix bugs, contributing fixes to Linux is broken, or both.

A rewrite of these user interactable subsystems in Rust can't come soon enough.

The author is Russian and seems to work for Positive Technologies, which is on the sanctions list.

Security researchers rarely fix bugs. They don't see it as their job, and it requires a very different skill set than finding or exploiting them anyway.

Interesting side effect of the sanctions.

I mean, yes, the incentives are in fact such that sitting on a potentially exploitable bug is better for a security researcher than patching it early.

Like, if you have a root priv escalation, that can potentially get you a bug bounty from various hosted AI sandboxes, CI sandboxes, an android app sandbox escape, and probably a few more.

If you have a probably-not-exploitable kernel crash, you get a CVE at best, and possibly not even that.

What do you propose we do, should google assume all kernel bugs are potential exploits and give Linus $100k per commit, making him the richest man on earth?

This is misplaced in this case.

The author mentioned CVE-2021-26708, which is very similar to this bug, and in fact the author both exploited it and authored the upstream fix in the kernel.

> and it requires a very different skill set than finding or exploiting them anyway

I disagree with that. Exploiting bugs is really hard, and if you can exploit them, you absolutely know enough about the kernel in order to patch it.

Sure, architecting a kernel, making code maintainable, that's a software engineering skill. But fixing a use-after-free? That's easier than exploiting it, of course they can fix it.

>As opposed to fixing the bug?

God forbid someone does something for fun...

There’s the technical challenge, and then there’s the process challenge.

Is it really a side effect though? I think the entire point of these sanctions (or their implementation by Linux Foundation more specifically) is to prevent developers working for Russian companies from contributing to Linux. It isn't a side effect, it's the intended effect, wouldn't you say so?

Sending an email with a simple patch is not a challenge.

But he has an @linux.com email address though.

What the hell is linux.com? .com is for commercial.

Thanks for submitting the fix here!

"fixing bugs" gets lets street creds than "hacking into things"

I thought the idea is to prevent Russian hackers from introducing exploits. Not prevent Russian hackers from fixing exploits.

"Linux.com is brought to you by The Linux Foundation, the organization of choice for the world’s top developers and companies to build ecosystems that accelerate open technology development and commercial adoption. Please see www.linuxfoundation.org for more information on The Linux Foundation, its mission and its members. "

https://www.linux.com/about/

You might want to read the thread you are responding to instead of posting knee-jerk reactions.

No, the point is to stop Amercian technology companies from providing technology to Russian entities.

From the perspective of sanction laws, accepting patches (or arguably even replying to emails) from sanctioned entities is effectively providing technology to them because you are telling them that the patch solves the issue (i.e., you are providing them technical expertise) and are making it easier for them to use the patch in the future (i.e., no need to rebase and shipping software that they have indicated that they will find particularly useful).

The Linux Foundation provided some guidance about this earlier this year[1]. Basically, it is incredibly easy to inadvertently violate sanctions if you are involved in an open source project.

[1]: https://www.linuxfoundation.org/blog/navigating-global-regul...