Post B5vPUOnwv5UXt36nK4 by AndresFreundTec@mastodon.social
(DIR) More posts by AndresFreundTec@mastodon.social
(DIR) Post #B5sRfB5tqtrGz4tOkK by mgorny@social.treehouse.systems
1 likes, 0 repeats
Greg Kroah-Hartman: "If you look there are thousands of unfixed CVEs in the older LTS kernels right now, and if distros or users that rely on those older branches wish to see those resolved, they need to provide working backports to us to apply, as our first attempt did not work (which is why they are unfixed in those branches.)"Really asking for a "Pray tell us", given that nobody actually bothered disclosing the problem to downstreams and that the commit message was hiding it.Either way, apparently the great #LLM-backed patch backporting process that #NVidia is so proud of doesn't really work. Upstream doesn't really care about #LTS branches, and they should be considered insecure by default.https://lore.kernel.org/stable/2026050114-supernova-angler-2de1@gregkh/#Gentoo #Linux #CopyFail #security
(DIR) Post #B5teaiEogqDWtNDxlA by thesamesam@social.treehouse.systems
1 likes, 0 repeats
@pinskia @mgorny I've felt for a while that the GCC approach is quite reasonable because it's not so old that people forget big changes in a release. And remember, in GCC (and in basically every project but the kernel), the backports are either done by the person who made the change, or at least they are asked.In the kernel, it is basically automated git cherry-pick. If it applies cleanly, in it goes. Doesn't mean it does the right thing. If not, good luck.
(DIR) Post #B5vPUOQuIl3mjaKOPI by thesamesam@social.treehouse.systems
0 likes, 0 repeats
@mgorny Compare Solar Designer's attempt to find a compromise at https://www.openwall.com/lists/oss-security/2026/05/01/2 with the response at https://www.openwall.com/lists/oss-security/2026/05/01/3I don't think I can keep commenting on this, because it's driving me mad. I've already tried to be very restrained in what I say.
(DIR) Post #B5vPUOnwv5UXt36nK4 by AndresFreundTec@mastodon.social
1 likes, 0 repeats
@thesamesam @mgorny The "you must update to the latest releaseto get all fixes needed to keep a system secure of all currently-knownissues" bit really makes my head explode.How does GKH expect folks upgrade all their prod systems every ~6 days (the rough average release pace of -stable kernels), with sometimes as much as four releases in a week.That's unrealistic CYA language, and GKH has to know that.
(DIR) Post #B5vtMPUJUbn4JY1xvE by tomasv@fosstodon.org
0 likes, 0 repeats
@AndresFreundTec @thesamesam @mgorny IMHO the cadence of the releases is not the main problem here - in a way, that's not entirely up to the kernel folks, it depends on what issues get discovered/reported, if there's an agreement on when it gets public, etc. Having more frequent releases with as many fixes as possible is probably the better option, but it also means it's somewhat futile - you can't rely on the kernel alone, you need other defenses too (even if you can upgrade that often).
(DIR) Post #B5vtMPri5cVPU6yeOG by AndresFreundTec@mastodon.social
0 likes, 0 repeats
@tomasv @thesamesam @mgorny I think it's ok to have very frequent releases. There are some problems around how much testing that realistically allows, and that does seem to show up in the frequency of needing fixup -stable releases.IMO the problem is having very frequent releases without providing *any* usable information about who needs to update how urgently, by saying that everyone needs to update immediately.If you continually make unrealistic requests, nobody listens to you.
(DIR) Post #B5vtMQ0DZzJLuUxReS by tomasv@fosstodon.org
0 likes, 0 repeats
@AndresFreundTec @thesamesam @mgorny I think the bigger issue is the strange definition of what "LTS" means, and what people assume it to mean. Because from the descriptions I found, LTS means "actively maintained and provided with security updates" but it seems it means "some security updates, maybe". Which is not great, I guess?FWIW I understand the number of fixed issues is likely overwhelming. But then maybe not having LTS kernels would be better ...
(DIR) Post #B5vtMQ8j4M7IKswEue by tomasv@fosstodon.org
0 likes, 0 repeats
@AndresFreundTec @thesamesam @mgorny True, but I'm afraid it's not practical. Someone needs to make those assessments, it's hard to determine the impact, and it's likely very time consuming. Even before the current onslaught of reports. I'd imagine this is why NIST recently gave up on enriching the CVEs.
(DIR) Post #B5vtMQWpcjOnXeDUUC by thesamesam@social.treehouse.systems
0 likes, 0 repeats
@tomasv @AndresFreundTec @mgorny This doesn't apply if the reporter has provided what seems to be a genuinely serious vulnerability or if they've provided a PoC, though. I'm not asking for in-depth analysis of every vague possible bug that people report.
(DIR) Post #B5vtMQn8e6RWMDqVu4 by vbabka@mastodon.social
0 likes, 0 repeats
@thesamesam @tomasv @AndresFreundTec @mgorny is it known if the reporter provided the info that it's that serious, or even the exploit? From various tidbits I thought they didn't.
(DIR) Post #B5vtMQy7zFEWuIzI24 by thesamesam@social.treehouse.systems
0 likes, 0 repeats
@vbabka @tomasv @AndresFreundTec @mgorny Their report from the tool in their disclosure said LPE and such, so I think so, but I'm not sure they've actually confirmed what they gave to the kernel security team. I'll look around and update if I find some confirmation.
(DIR) Post #B5vtMRBFCTj1Yz7lTc by thesamesam@social.treehouse.systems
0 likes, 0 repeats
@vbabka @tomasv @AndresFreundTec @mgorny Asked now on oss-security: https://www.openwall.com/lists/oss-security/2026/05/03/13
(DIR) Post #B5vtMRNeSLeMBSvfoe by thesamesam@social.treehouse.systems
1 likes, 0 repeats
@vbabka @tomasv @AndresFreundTec @mgorny ... yes, @grsecurity pointed out the CEO has stated they included a full exploit. Beyond words.