>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.

▲

pdw 6 days ago | parent | next [-]

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.

▲

TheDong 6 days ago | parent | next [-]

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.

▲

Den_VR 6 days ago | parent [-]

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

▲

account42 6 days ago | parent [-]

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

▲

brookst 6 days ago | parent [-]

Thanks for submitting the fix here!

	▲	account42 6 days ago \| parent [-]
		You might want to read the thread you are responding to instead of posting knee-jerk reactions.

▲

blueflow 6 days ago | parent | prev [-]

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

▲

TheDong 6 days ago | parent | prev | next [-]

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?

▲

rs_rs_rs_rs_rs 6 days ago | parent | prev | next [-]

>As opposed to fixing the bug?

God forbid someone does something for fun...

▲

ch3 6 days ago | parent | prev [-]

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

▲

darkwater 6 days ago | parent | next [-]

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

▲

koakuma-chan 6 days ago | parent [-]

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

	▲	darkwater 6 days ago \| parent [-]
		"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/

▲

Arch-TK 6 days ago | parent | prev [-]

Interesting side effect of the sanctions.

▲

shmel 6 days ago | parent [-]

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?

▲

Ygg2 6 days ago | parent [-]

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

	▲	cyphar 5 days ago \| parent [-]
		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...