Linux gets fix for code-execution flaw (Ars Technica)

Subsets of PaX were definitely submitted to LKML over time, e.g. patches constifying individual structs made purely of function pointers (before a GCC plugin replaced those individual hunks). Some patches went in, others weren't picked by maintainers.

Nowadays, spender, PaXTeam and ephox are known to be more inclined to work on improving the features of PaX / grsecurity from a technical POV (as a proof of that: in a post below, spender mentions a new protection in progress), than to deal with the politics of mainline submission.

What to do to meaningfully improve end user security of Linux ? I don't know.
* split PaX / grsecurity into more mergeable chunks ? Definitely, as there's no way mainline is going to integrate a nearly 4 MB patch touching a couple thousand files. But if mainline integration of the most interesting features is not going to occur no matter what, why bother ?

* submit low-hanging fruit from PaX / grsecurity to mainline ? Definitely. Several hunks get in, once in a while. But without the more powerful features, the actual contribution to end user security would be limited.

* expect mainline to start taking security seriously ? Unrealistic. For mainline - and in general, for the vast majority of users, even in known pervasive surveillance times - performance in micro-benchmarks and macro-benchmarks has much higher priority than serious security, and the useful prospect of closing entire classes of exploitations.

* except distros to start taking security seriously ? Unrealistic.
Even if PaX / grsecurity were fully integrated to mainline, most distros wouldn't enable it by default, due to
1) the performance cost of up to several dozen percents (with all protections enabled)
and either
2a) the unusability of unmodified sloppy desktop userspace on an enforcing grsecurity kernel (pax_softmode=0) with most grsecurity features enabled. I recently tried doing that on Mint: in enforcing mode, Cinnamon simply fails to start, with the FLOSS GPU drivers (which are known to be more compatible with grsecurity than nvidia and fglrx). With pax_softmode=1, Cinnamon starts, but I quickly noticed that `paxctl -PeMRXS` modified executables using some Webkit-based stuff get killed by the mprotect protection.
or
2b) the work required to selectively use paxctl to disable individual PaX protections, and periodically revisit those decisions (when some underlying libraries get fixed, it can become possible to re-enable e.g. mprotect hardening - but who's going to spend time noticing that ?).

* use another kernel, one whose makers pretend they take security seriously, e.g. OpenBSD ? As pointed by spender multiple times over the years (e.g. in exp_moosecox.c), OpenBSD defenses against exploitation are usually later to the party than PaX+grsecurity / Linux / even Windows defenses. And OpenBSD "market share" is low, so its actual contribution to end user security is limited - like grsecurity's.

I can't think of who, in the top kernel dev community, would have enough time and reputation to improve mainline Linux security though patiently submitting the bulk of PaX / grsecurity to mainline, one feature at a time...