Today I have spent way too much time handling the https://copy.fail situation #copyfail

[itsec_agentur@infosec.exchange]

@alexanderkjall indeed

[smlx@fosstodon.org]

@alexanderkjall yeah they sure come across as an amateurish outfit with moves like this

[aj@techhub.social]

@alexanderkjall ditto on spending too much time, & agreed they should have notified distro maintainers

[labanskoller@infosec.exchange]

@alexanderkjall I read that they had waited a month with distributing the PoC and that major distributions were prepared.

[penguin42@mastodon.org.uk]

@alexanderkjall But they say they 'Reported to Linux kernel security team' on 23rd March; shouldn't that have triggered the distros finding out?

[jmm@fosstodon.org]

@LabanSkoller @alexanderkjall if they say so, they are lying. The distros security list wasn't notified and there was no headsup to Debian outside of the list either. And Ubuntu surely neither, otherwise they wouldn't have just pushed a patched kmod package with the module blacklisted...

[alexanderkjall@mastodon.social]

@penguin42 It did not, the process is somewhat described here: https://docs.kernel.org/process/security-bugs.html

[jonasgeiler@fosstodon.org]

@alexanderkjall

An "AI-assisted finding", using a pretty AI-written and designed looking website, m-dash, semicolons, it has it all
Couldn't their AI also tell them how to report it properly???

[raven667@hachyderm.io]

@alexanderkjall Brad Spender (GRSecurity) has been highly critical of the Linux Kernel security bug handling process since forever, and one of those criticisms is that the members of security@kernel.org don't notify the linux-distros security list, or really triage severity in a way that he approves of as a security vendor and practitioner, their "security bugs are just bugs" stance that refuses to give priority to security issues is infuriating to some people who see security bugs as higher priority than any other kind of bug.

[labanskoller@infosec.exchange]

@jmm @alexanderkjall I think I mixed it up with the Linux kernel security team. But shouldn’t *that* team notify the distros?

[alexanderkjall@mastodon.social]

@LabanSkoller @jmm They do not, the process is somewhat described here: https://docs.kernel.org/process/security-bugs.html

[penguin42@mastodon.org.uk]

@alexanderkjall That feels too complicated to leave to leave just to a (potentially 1st time) reporter. I would have hoped that at the very least the LK security team would track with the reporter and remind them of the need to do the other bits regularly. Especially on a nasty one!

[adamw@fosstodon.org]

@jmm @LabanSkoller @alexanderkjall yeah, it's definitely not been handled optimally. on the RH side, Fedora happens to be OK as the fix landed upstream in 6.19.12 and that already went stable, but RHEL (and hence CentOS and probably Alma and Rocky) are affected with no day-0 update - https://access.redhat.com/security/cve/cve-2026-31431 .

[omegapolice@hachyderm.io]

@alexanderkjall And there I sat, thinking it was just me being too dumb to figure out whether I had a patched kernel without running their bespoke, obfuscated script.

[omegapolice@hachyderm.io]

@raven667 @alexanderkjall Sounds like reasonable criticism to me. But then, an extended group of volunteers can only be expected to do so much. If we want SLAs, we have to pay people.

[labanskoller@infosec.exchange]

@alexanderkjall @jmm hmm…
> As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community.

Well, if it’s too complicated to be a reporter, there is always fulldisclosure@seclists.org.

[raven667@hachyderm.io]

@OmegaPolice @alexanderkjall yes and the majority of Linux kernel development is not volunteers, its a consortium of vendors organized through the Linux Foundation trade org which _does_ pay people. There are still volunteers who work on Linux but they shouldn't be a shield for the majority to pretend they are "just a smol bean, uwu" and dont have some responsibilities.

I'm the *first* to say that dragging volunteer FOSS maintainers is shitty (and that volunteers shouldn't cosplay as commercial vendors, by doing things like having public issue trackers, as it is nonsense to "open a support case" with a tracking number against a *volunteer*) but Linux kernel has volunteers it is not a volunteer led project anymore, its a consortium of major companies which benefit from pooling effort and having a neutral forum to collaborate.

I think security focused people, whose customers are also prioritizing security sometimes dont have empathy for or understand people who don't have security as their top priority, and treat people who don't share their priorities as stupid and incompetent, rather than understanding the differences in goals and constraints. That said there is probably room for improvement on kernel security, but more from a better systematic approach to prevent defects than treating every bug with a website as some super secret special thing. the current design makes a constant stream of local exploits inevitable

[alexanderkjall@mastodon.social]

@raven667 @OmegaPolice I agree that it would be great if the kernel security team had a process that made life simpler for downstream vendors.

But since neither me or my employer contributes anything to make that happen I don't think it's my place to have public opinions about it.

Personally I would love to see more effort focused on reducing the attack surface of the kernel.

[poslovitch@wikis.world]

@LabanSkoller @jmm @alexanderkjall No non I actually read that too from the FAQ on the Copyfail page yesterday. So. That was a lie?

[regishaubourg@mastodon.social]

@alexanderkjall and strangely disclosed just before the 1st of may, like the mongobleed disclosed just before 1st of January.
Almost as a buzz strategy, pushing IT folks to work on weekends and public holidays.
Seriously, waiting next Monday, letting a weekend to all distros was so hard?