Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

For Linux kernel vulnerabilities, there is no heads-up to distributions

openwall.com

Post reply on HN
Print view View original

241–250 of 578 posts

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#241

Post by john_strinlai »

ori_b wrote: post #240
Joker_vD wrote: post #233

Earlier quoted context omitted.

One of the reasons this unavoidable deadline was invented, is that the alternative is that one company (or all of them) can simply decide to ignore the vuln report, and then the vulnerability will stay forever undisclosed and forever out there in the wild. And prisoner's dilemma suggests that most companies would chose "do nothing" in this scenario: they don't have to do anything, and if the vuln stays undisclosed, i…

I'm confused. Can you explain how this applies to the current situation, where no vuln reports were submitted to the groups responsible for distributing patches?

>where no vuln reports were submitted to the groups responsible for distributing patches?

the vulnerability report was submitted to the kernel security team and appropriate kernel maintainers. those are the people responsible for patching the kernel, which they did 30 days ago.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#242

Post by TacticalCoder »

Skywalker13 wrote: post #214

I have checked all the servers (bookworm, bullseye) that I manage, and none of them have the algif_aead module loaded. Seems not fatal to all non-patched systems.

> I have checked all the servers (bookworm, bullseye) that I manage, and none of them have the algif_aead module loaded.

But only Trixie (and testing/Sid) are patched (as I type this).

On Bookworm (and Bullseye), you want to add the module to list of blocked modules. It's a one-line change.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#243

Post by selectively »

bigbadfeline wrote: post #198
selectively wrote: post #68

Earlier quoted context omitted.

Researchers are under no obligation to engage in coordinated disclosure and are free to sell 0day for profit. Just fyi. Be glad it was disclosed at all. Be glad a patch was available prior to release.

> Researchers are under no obligation to engage in coordinated disclosure and are free to sell 0day for profit. Just fyi. Be glad it was disclosed at all. I'm so glad these so called "researchers" aren't totally evil, I'm so grateful they're only half evil, give them a lollipop. Whatever, the way they disclosed it isn't much different from no disclosure at all - the exploit would have been identified in the wild and…

There are two options:

1. Status quo. Researchers are free to disclose to a vendor, free to sell vulns to legitimate companies, free to do full disclosure if they want. This situation benefits security. Researchers are able to pay their bills while also doing meaningful research into OSS projects that are unable to fund the kind of security audit they need. Harm reduction, of sorts.

2. Everyone is a bad actor. No one is going to do this work for free/for a bounty. Horrible flaws will be found and shared with ransomware gangs and the like. 0day will sell for a percentage of the ransom winnings. Researchers will live like kings, everyone else will suffer.

Which do you prefer?

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#244

Post by akdev1l »

aaronmdjones wrote: post #231
akdev1l wrote: post #147

Earlier quoted context omitted.

Without read permissions you cannot execute the binary, that would not make any sense. To execute the binary it needs to be read from disk and loaded into memory. In fact if you have read permissions but not executable permissions on a specific binary then you can still execute it by calling the linker directly /bin/ld.so.1 /path/to/binary (the linker will read and load the binary and then jump to the entry point wit…

> Without read permissions you cannot execute the binary This is not correct, as when the binary is setuid-someone-else, you are not the one executing it; they are. $ cat hello.c #include int main(void) { (void) puts("Hello, world!"); return 0; } $ clang-21 -Weverything hello.c -o hello $ sudo chown root:root hello $ sudo chmod 4711 hello $ ls -l hello -rws--x--x 1 root root 16056 Apr 30 22:22 hello $ ./hello Hello,…

interesting but in that case no point in keeping the x bit either and suid binaries should just be 4700 ?

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#245

Post by ori_b »

john_strinlai wrote: post #241
ori_b wrote: post #240

Earlier quoted context omitted.

I'm confused. Can you explain how this applies to the current situation, where no vuln reports were submitted to the groups responsible for distributing patches?

> where no vuln reports were submitted to the groups responsible for distributing patches? the vulnerability report was submitted to the kernel security team and appropriate kernel maintainers. those are the people responsible for patching the kernel, which they did 30 days ago.

I see, may the people who are responsible for the infrastructure you depend on be less concerned about shifting blame than you are.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#246

Post by selectively »

lrvick wrote: post #179
kelnos wrote: post #109

Earlier quoted context omitted.

I'm pretty sure they have a legal obligation in most jurisdictions not to sell 0days for profit. And they absolutely have a moral obligation to do things in a way to minimize damage and impact to other people's systems. (I'm not saying "responsible disclosure" is the correct way to do that, but hoarding vulnerabilities and exploits and selling them to the highest bidder certainly isn't.) This is how society needs to…

Let me make you aware of zerodium. A broker anyone can sell vulns to, that sells to unspecified buyers you do not need to know about.

(The buyers are the NSA, the IDF, Cellebrite, NSO and its successor corporation and that kind of thing. Depends on what you are offering)

You'll learn who the buyers are if you routinely have the really good stuff to sell! If you are offering iOS zero click on a semi-regular basis, the buyer is going to want to try to deal with you directly and preferably offer you a more regular form of employment, if you are interested. Some national governments may offer certain benefits to you, depending on your situation.

All depends on what you have to offer. If you were able to offer this https://arstechnica.com/security/2025/09/microsofts-entra-id... or something of that magnitude, a lot of problems in your life would just go away. The buyers would all be Five Eyes and the intelligence gain of having that kind of access even briefly is priceless.

In a more Western-centric context, imagine if you had a flaw like that, same 'no logs are generated' and 'every single customer account is accessible' but the impacted vendor was Alibaba Cloud. The researcher would get to name their price. That's the real world, that's the world we share. We shouldn't be blind to that.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#247

Post by baggy_trough »

staticassertion wrote: post #213
baggy_trough wrote: post #205

Earlier quoted context omitted.

That doesn't really seem to map onto the situation since Greg himself released a 6.12 with the patch earlier today.

I don't know what you mean at all. I'm just repeating known kernel policy here. What does 6.12 have to do with anything?

What is your interpretation of why Greg KH released a version of 6.12 with this fix in it today, other than to help distributions avoid this vulnerability?

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#248

Post by aaronmdjones »

akdev1l wrote: post #244
aaronmdjones wrote: post #231

Earlier quoted context omitted.

> Without read permissions you cannot execute the binary This is not correct, as when the binary is setuid-someone-else, you are not the one executing it; they are. $ cat hello.c #include int main(void) { (void) puts("Hello, world!"); return 0; } $ clang-21 -Weverything hello.c -o hello $ sudo chown root:root hello $ sudo chmod 4711 hello $ ls -l hello -rws--x--x 1 root root 16056 Apr 30 22:22 hello $ ./hello Hello,…

interesting but in that case no point in keeping the x bit either and suid binaries should just be 4700 ?

If they don't have world-execute permission, an access(2) check for executability would return negative, leading to things like shells not tab-completing it. The kernel would also deny attempting to execute it, as it is not executable for your fsuid.

  $ sudo chmod 4700 hello
  $ ./hello
  bash: ./hello: Permission denied
You need execute access in order to launch it, but in order for it to run, the user it is running as (not you) needs read access; you don't.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#249

Post by john_strinlai »

ori_b wrote: post #245
john_strinlai wrote: post #241

Earlier quoted context omitted.

> where no vuln reports were submitted to the groups responsible for distributing patches? the vulnerability report was submitted to the kernel security team and appropriate kernel maintainers. those are the people responsible for patching the kernel, which they did 30 days ago.

I see, may the people who are responsible for the infrastructure you depend on be less concerned about shifting blame than you are.

imagine you use a dependency in your code. like left-pad. and some vulnerability is found in left-pad.

is the reporter of that vulnerability responsible for finding and submitting a vulnerability report to every single piece of software that uses left-pad? all ~millions of them?

or do they submit the report to left-pad, get them to fix it at the source, and trust that the people relying on left-pad will update their software like they should when they see a security-relevant update is available?

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#250

Post by selectively »

lrvick wrote: post #175
selectively wrote: post #68

Earlier quoted context omitted.

Researchers are under no obligation to engage in coordinated disclosure and are free to sell 0day for profit. Just fyi. Be glad it was disclosed at all. Be glad a patch was available prior to release.

Unfortunately this is correct. As a security researcher I set millions in profit on fire for reporting vulns to projects that offer no bounties vs selling to highest bidder. I keep doing it because it is the right thing to do, but I would not blame someone that needs to feed their family making a different choice. We must get public funds to reward ethical disclosure of big impact vulns like this.

Harder and harder to get good policy like what you describe when tech-adjacent people loudly argue for criminal penalties for anything other than coordinated disclosure :(
Post reply on HN