Major Linux vulnerability - Copy Fail

[Cyclotron]

The only source for this seems sentinelone.

Don't quibble.  Oracle is known for a huge list of CVEs, and I specifically wrote "things like".  Perhaps I should have referenced CVE-2025-41236, CVE-2025-41237, and CVE-2025-41238 instead.

Relying on container isolation, or any one other security tool, is what is silly.  Linux/POSIX privilege separation is a perfectly valid tool, and should not be overlooked.  For example, if WordPress, SMF, etc. internally used multiple POSIX user accounts and groups with privilege separation (so that files created by the scripts are non-executable/non-interpretable, only serveable as content as-is), we'd eliminate 99.9% of all forum and website exploits.  (Attacks would shift to supply side, though, so the overall reduction in attacks would be much less.)

Linux kernel privilege escalations are rare.  I would recommend everyone take a look at e.g. CERT-EU critical vulnerabilities list for 2026, 2025, 2024, and earlier, instead of relying on vague "gut feelings" and "beliefs".

Indeed!

And exactly the right stance. Use every tool at every level to secure a platform and application services. Every lock can be picked/defeated, but it takes time. Proper security should push lazy attackers toward easier targets, and persistent attackers should be discovered because of the effort and time required. Layers of security and telemetry with someone at the wheel have long been the best gameplay. Today, AI is making it easier for both sides to spot patterns, but this only mildly changes the game. 

What has worked continues to work. There's no "easy" solution if you want to keep your data secure.

[Marco]

Doesn't mean you should ignore attack surface (lines of code reachable running at host kernel/root/ring -X privilege), level of protection effort (hyperscaler exposure, bug bounties) and value to hackers (local vs. remote).

User, container, gvisor, VM don't differ by small amounts, the chaining advantage can be fairly minimal. A million dollar vs 100k difference on the black market, for different parts of a chain. Defense in depth, but know the most valuable and trustworthy links. User privileges ain't.

[madires]

Next one: Dirty Frag (https://github.com/V4bel/dirtyfrag)

Temporary measure: block modules esp4, esp6 and rxrpc

[Marco]

I was wondering why rxrpc was even in kernel space, it's for AFS ... why is that even a default load?

[madires]

Most linux distributions enable all kernel features (usually as modules) trying to make everyone happy. BTW, esp4 and esp6 are already patched in 6.6.138, 6.12.87, 6.18.28 and 7.0.5.

[Marco]

But a couple msec extra wait while mounting an AFS filesystem or IPSEC interface is hardly relevant, there is no reason to load these at boot. Don't attribute to malice what you can attribute to negligant levels of laziness I guess.

This seems a good time for distros to start reducing their attack surface. Attack surface rarely gets the attention it deserves.

[golden_labels]

For these wishing to apply temporary mitigations, but being unahppy with running random one-liner scripts, here’s a more readable version. Note that IPSec handling will be broken while these changes are in effect.

Block loading of esp4, esp6, and rxrpc modules in modprobe configuration:

/etc/modprobe.d/yourname.conf:

Code: [Select]

install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false

After that make sure the modules are unloaded:

Code: [Select]

# rmmod esp4 esp6 rxrpc(errors warning they’re not loaded are fine)

[madires]

But a couple msec extra wait while mounting an AFS filesystem or IPSEC interface is hardly relevant, there is no reason to load these at boot. Don't attribute to malice what you can attribute to negligant levels of laziness I guess.

Typically those kernel modules are loaded on demand, not by default when the system starts.

[Marco]

Typically those kernel modules are loaded on demand, not by default when the system starts.

Registered on boot seems a bit ridiculous for AFS too, extreme niche and should hardly ever allow arbitrary mounting by non elevated users even when used.

Ipsec, okay I guess.

[madires]

Update: today's 6.18.29 comes with a fix for rxrpc. Also 7.0.6 and possibly more later on.

[madires]

Next one: ssh-keysign-pwn (CVE-2026-46333)

Fixed in kernels released yesterday.

[golden_labels]

As of May 16th, fixed in all active versions: 7.0.8, as well as LTS 6.18.31, 6.12.89, 6.6.139, 6.1.173, 5.15.207 and 5.10.256.

We should celebrate so many vulnerabilities hunted down in such a short period. But this is a sad month. The responsible disclosure framework disobeyed so many times.

[Karel]

Responsible disclosure is overrated IMHO.
Because it's practically impossible to write bugfree/secure software, we shouldn't use software for important things.
Or, if you do use software for important things, don't blame the publisher of a 0-day exploit.
Demand better software quality and better testing.

[golden_labels]

Very good reasoning. Because it’s practically impossible to never forget to lock all doors, we shouldn’t use houses for important things.
Or, if you use a house for important things, don’t blame your neighbour for notifying the thieves you forgot to close the door while leaving for a longer time, instead of calling you. /s

[Marco]

Responsible disclosure is overrated IMHO.

On the other hand, how nice is it that the fast disclosure only happens for bugs they couldn't leverage for a bug bounty (for Android or some other locked down Linux with a bug bounty).

It's a bit of a protection racket and the exploit hunters a bit of a mafia.

[Cyclotron]

From my understanding, most of the issues are discovered by people trying to make money by doing the research.
The threat of no warnings for releases keeps those dollars available for the researchers. I see at least two paths.
Criticize them, or do the research and make the responsible disclosure yourself. 

The open source way is that if you don't like something, you have everything you need to do it your way.

[Karel]

Sure, shoot the messengers.
To me, the "maffia" includes the decision takers that decided it was a good idea to use software for important data.
For important things, we should go back to paper instead of computers or at least disconnect those computers from
the internet.

[Marco]

The threat of no warnings for releases keeps those dollars available for the researchers.

It's not really an option, since they can simply dump them on the internet with the unspoken blackmail that they will continue doing so until they get bug bounty programs (which in a way is exactly what historically happened), but it would likely be better to simply only have true black hats and employees looking for exploits.

The bug bounty hunt causes more problems than it solves.

SNAFU.

[Cyclotron]

The threat of no warnings for releases keeps those dollars available for the researchers.

It's not really an option, since they can simply dump them on the internet with the unspoken blackmail that they will continue doing so until they get bug bounty programs (which in a way is exactly what historically happened), but it would likely be better to simply only have true black hats and employees looking for exploits.

The bug bounty hunt causes more problems than it solves.

SNAFU.

No argument from me. I am amazed that civilized society has persistently ignored this problem. Governments exploit the market for such bugs and participate directly in discovering and not disclosing them. Knowledge is power, and governments love some power.

If we went back in time, when society (usually wealthy, etc.) funded research for the sake of good and science, we might have better outcomes. Yes, back then, notoriety and acclaim were also sought after, but I don't think profit was the immediate objective. Today, all research I know of is done to generate revenue, and often the outcomes aren't any better. This has driven the biggest decline in trust for science.  Well, you can trust that those researchers and/or scientists are trying to make money.

I don't think the folks who do it are inherently wrong or even set out to profit on these things. I just think they find out that they must feed their families, and governments and companies don't pay for research just to do good for society.  They pay for revenue generation.

[free_electron]

In case the likes of Karel missed it, this is a 17 year old Linux bug.

<sarcasm> nobody read that bit of code int he last 17 years ? you know, the source is available... what are all those linux geeks doing ? sitting on their hands ? or debating between vi and emacs ?</sarcasm>

[golden_labels]

On the other hand, how nice is it that the fast disclosure only happens for bugs they couldn't leverage for a bug bounty (for Android or some other locked down Linux with a bug bounty).

It's a bit of a protection racket and the exploit hunters a bit of a mafia.

The responsible disclosure procedures and bug bounty programs are two separate layers. They overlap in some situations, but are targeted at two very different problems.

The goal of bug bounty programs is to redirect financial motivation. Authors put out their bids in the vulnerabilities market, hoping the seller chooses them instead of a party wishing to use it for an exploit. A corollary is generating additional motivation, leading to a faster discovery of vulnerabilities and a higher chance of that being done by people already set to give the information to the authors.

A critical element of a protection racket scheme is creation of the risk in the first place, by the same people that demand money, and for that very intent. Whereas vulnerabilities market existence is completely independent of bug bounty programs, it predates bug bounty programs by far, and software authors are the active party. So the comparison doesn’t hold.

From my understanding, most of the issues are discovered by people trying to make money by doing the research.

Depends on interpretation of what you just wrote.

Most vulnerabilities going directly to exploits are without a doubt discovered that way. Kind of “by definition” — people are hired, they are the ones creating exploits as a business opportunity, or intending to offer to these. But this is also the set of cases that seem quite irrelevant here, because — from the same “definition” — they’re not going to participate in bug bounties or other disclosures.

For the other group, the situation is too muddy to really tell what is the motivation. Bug bounty programs are not a terrible success.⁽¹⁾ A lot of issues are reported directly to the maintainers or over normal issue trackers, with no financial compensation. High-profile researchers are usually already receiving a wage and the vulnerabilities are discovered as a part of their daily job. Many releases are done for self-promotion; which is why we now see all these branded bugs with their own domains, presentations, media coverage, conferences follow-ups etc.

So certainly not as a clear cut situation.

(this is not in opposition to the rest of your post; I cut it out intentionally)

Sure, shoot the messengers.
To me, the "maffia" includes the decision takers that decided it was a good idea to use software for important data.
For important things, we should go back to paper instead of computers or at least disconnect those computers from
the internet.

Am I the only one enticed to paraphrase Poe’s law, in its troll/ignorance form?

No argument from me. I am amazed that civilized society has persistently ignored this problem. Governments exploit the market for such bugs and participate directly in discovering and not disclosing them. Knowledge is power, and governments love some power.

Is there anything to be amazed by? Members of society are generally in support of hostile and aggressive actions, as long as they see the targets as “evil” or otherwise “undesirable.” And in our view it’s always “objective truth,” so there is no option to show the other person it’s otherwise. Governments are composed of humans following the same pattern, but having more individual power.

If we went back in time, when society (usually wealthy, etc.) funded research for the sake of good and science, we might have better outcomes. Yes, back then, notoriety and acclaim were also sought after, but I don't think profit was the immediate objective. Today, all research I know of is done to generate revenue, and often the outcomes aren't any better. This has driven the biggest decline in trust for science.  Well, you can trust that those researchers and/or scientists are trying to make money.

Nah! That’s romanticizing the past. Fairytales of “it was better back then.” 

And… the biggest decline in trust for science? C’mon, we don’t even yet have popular novels and cinema villainizing science as it was the norm in the past.

<sarcasm> nobody read that bit of code int he last 17 years ? you know, the source is available... what are all those linux geeks doing ? sitting on their hands ? or debating between vi and emacs ?</sarcasm>

Do you know what’s the difference between using a sarcasm and sounding smart, and using a hostile sarcasm and revealing ignorance? Exhibit № 1 is in the quotation box above.


⁽¹⁾ They attract people seeking money, but mostly people seeking easy money. Strictly speaking that means they do see a lot of traffic. But that’s not the kind of valuable traffic we hope for, and certainly not a motivation for quality research.

[free_electron]

<sarcasm> nobody read that bit of code int he last 17 years ? you know, the source is available... what are all those linux geeks doing ? sitting on their hands ? or debating between vi and emacs ?</sarcasm>

Do you know what’s the difference between using a sarcasm and sounding smart, and using a hostile sarcasm and revealing ignorance? Exhibit № 1 is in the quotation box above.

My point is : the linux community is ever harping on about "the source is available" and "it's so much secure cause you know : anyone can inspect the source". Meanwhile a severe bug goes unnoticed for 17 years.
It makes you wonder how many of those people that make the "source is available" statements actually have done any work reading the source ... my bet is 99.99% of linux users have never read a line of source. And of that 0.01 only 0.01% actually understand it. And how many of those actually have the skill to fix it ?

There is almost religious wars between vi and emacs, systemd "evil", what distro to use and what desktop shell.

Just having the source is meaningless if you never read it, and lack the skill to understand it and / or fix it. You may as well not have the source, it does you no good anyway.

got it now ?

[golden_labels]

My point is : the linux community is ever harping on about "the source is available" and "it's so much secure cause you know : anyone can inspect the source". Meanwhile a severe bug goes unnoticed for 17 years.
It makes you wonder how many of those people that make the "source is available" statements actually have done any work reading the source ... my bet is 99.99% of linux users have never read a line of source. And of that 0.01 only 0.01% actually understand it. And how many of those actually have the skill to fix it ?

There is almost religious wars between vi and emacs, systemd "evil", what distro to use and what desktop shell.

Just having the source is meaningless if you never read it, and lack the skill to understand it and / or fix it. You may as well not have the source, it does you no good anyway.

got it now ?

I got it from the very beginning. This is why I responded the way I did.

Given the explanation you have given above, my response was correct. Ridiculing something without understanding it. Or worse: while misrepresenting it.

What’s going to be next? Laughing at the idea of government transparency, because nobody reads every single record and many abuses still fall through? Perhaps you shouldn’t be able to know your own bills, because certainly you never read each line on them and sometimes you’re billed more than you expected to be? Or maybe you shouldn’t be able to read your own court documents, because even lawyers don’t carefully read each single sentence in them and courts happen to make mistakes? Let’s strip you of access to newspapers and periodicals, because you never read them end-to-end and some important information slips through.

Enough of sarcasm from my end? Or do you prefer to continue distorting the meaning of the idea you dislike?

[madires]

Bad day? Needed to vent?

My point is : the linux community is ever harping on about "the source is available" and "it's so much secure cause you know : anyone can inspect the source". Meanwhile a severe bug goes unnoticed for 17 years.

The idea is that open source makes it easier or more probable to find security issues and to fix them. That doesn't mean open source will be automagically more secure, but it helps improving things. I wouldn't be surprised if there are more really old security issues in the linux kernel. However, if found they'll be fixed. And with AI tools the number of security issues reported is increasing.

There is almost religious wars between vi and emacs, systemd "evil", what distro to use and what desktop shell.

And also Windows 7 vs. 10/11, Amiga vs. ST, and for any other computer related topic.

[Nominal Animal]

(My intention in this post is to help by pointing out the source of the dissonance/misunderstanding/disagreement, and not to antagonize anyone.)

my bet is 99.99% of linux users have never read a line of source. And of that 0.01 only 0.01% actually understand it. And how many of those actually have the skill to fix it ?

This shows the fundamental misunderstanding those comfortable with proprietary software development have with open source projects:

The number of users is irrelevant.

In fact, increasing the number of users can be a huge negative cost.  I'll try to explain why below, but fundamentally, the projects do not need more users.

Open source projects are not socialist or communist at all, but market-competitive, almost capitalistic (except for accumulation of capital).  Absolutely everything has a cost, but it isn't money: it is skilled developer time and effort.  Until you understand this, you cannot understand how and why open source projects succeed or fail.

Now, free_electron is quite right in saying that many users repeat the same argument without understanding what it means, but that itself does not mean the sentence is invalid.  It is the same thing as equating bikeshedding flamewars like "vi vs. emacs" or "Debian vs. Fedora" with technical arguments (like why the systemd architectural design is horribly weak).  They are all opinions, but one often based on social or personal reasons, and the other on technical reasons.  Do not judge opinions prima facie; discuss and examine and judge them based on the reasoning behind those opinions instead.

Open source projects live and die by skilled developer effort spent.  You can consider developer skill "voltage", and combined effort spent "amperes", with analogous "power" being the resources available to the project.  End users who do not contribute are a liability, a net negative, not a net positive.  This (and many technical people having not-so-good social skills) is also why many open source projects are not welcoming change requests or bug reports lacking sufficient detail.  As I've said many times before, the key is to contribute first, showing that oneself is willing to spend the necessary time and effort, although some assistance from the higher-voltage/more experienced developers might be needed to get there.  This is how it works.  If you can get away from thinking of end users as a positive resource, and see contributor and developer skill, time, and effort spent as that same resource in open source projects, you can understand things much better.

Now, the Linux kernel has a couple of billion users.  0.01% of 0.01% is one out of hundred million, so if the estimate was correct to even the magnitude (power of ten), that would mean just twenty people understand the Linux kernel.  Based on Linux kernel CREDITS file currently listing over 600 persons, the estimate has to be off by at least one order of magnitude, possibly more.

Furthermore, even a relatively stupid drive-by debugger like myself can fix many types of bugs in the Linux kernel.  I have, and have also helped other members even here to deal with kernel-specific issues.  Even Linus Torvalds has commented that the kernel complexity already exceeds what a single person can fully grasp.  These are the reasons that caused Git to be created two decades ago, after all.  Because of certain iron-clad rules (like absolutely no fixed kernel internal APIs; everything is subject to change), and the modular build facility (based on Kconfig configuration language), nobody needs to understand everything, and it is sufficient to understand the specific subsystem and how it interacts with (depends on, and is depended on by) other subsystems.  That understanding has to be abstract; just memorizing some API is not sufficient.  It is also this kind of modular design that currently allows some driver development in Rust, a completely different programming language than the C used for the Linux kernel otherwise.

As the complexity of the software grows, so does the complexity of the possible bugs.  Historically, C has not supported any kind of compile-time range checking, but this is already changing with GCC.  For example, consider the counted_by variable attribute, which lets you associate a size variable with a pointer, so that the compiler can detect simple buffer overruns (especially off-by-one errors) at compile time without any runtime overhead.  Because of the limitations of C, many bugs in the Linux kernel have been difficult to detect: they require a relatively high skill level and very high conscientiousness to discover — noting that that bug-hunting time is taken out of more fun development time, and is thus not very interesting to most high-skilled developers.  With the recent advancement in LLM tools, the conscientiousness and time needed is much reduced, so more serious bugs are reported.  (Note, however, that the skill required is not reduced.  Even the Linux kernel security mailing list is battling with low-quality LLM-assisted bug reports.)

Finally: All code has bugs.  This is a practical fact arising from the complexity involved in the entire process (from human-written text or instructions, to machine-executable binaries).  Security bugs are the weirdest bunch of them, simply because many people do not understand information security at all, and thus the intersection of capable developers and those understanding information security is pretty small.  There are only a few software developers like DJB that can write non-trivial code with practically zero security issues when first written; but even those require maintenance due to compilers and conventions changing underneath the code.  (The common assumption that pointer → int → pointer conversion chain is lossless was a painful one, when transitioning from 32-bit to 64-bit architectures, for example.)

The fallacy that catches most proprietary developers is the belief in security through obscurity.  Anyone can nowadays use e.g. Ghidra to decompile binaries and investigate key parts of the code, and exploit any approach that relies on obscurity.  Even in microcontrollers, disabling read-back and having bus encryption is not a foolproof method: it just makes the reverse engineering process more expensive, much like patent protections for example.  (A patent by itself is worth nothing, unless you have the resources to defend it in court, and take possible infringers into applicable court.)

To circle back to the topic at hand, major Linux vulnerabilities, the way to estimate the general security of the project is to examine the security bugs themselves, and find out how skilled a developer is needed to discover that bug in the first place.  Statistically, from comparing the number of bugs to the number of lines of code, we already know that the Linux kernel is very much on the low side in bug density; the question that remains is how much time and effort is needed to find a new security bug in the Linux kernel.  Indeed, the Linux kernel, and many other open source projects core to many Linux distros, could use more skilled developer contributions, definitely!  It's just that the number of users is absolutely irrelevant here.