Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (Cyborg)
  • No Skin
Collapse
Brand Logo

CIRCLE WITH A DOT

  1. Home
  2. Uncategorized
  3. So CopyFail CVE-2026-31431 is a thing.

So CopyFail CVE-2026-31431 is a thing.

Scheduled Pinned Locked Moved Uncategorized
174 Posts 63 Posters 14 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • wdormann@infosec.exchangeW wdormann@infosec.exchange

    @gunstick
    The original (and current) CVE entry is merely the commit message.

    Which is unintelligible nonsense for anyone other than a Linux kernel developer.

    Link Preview Image
    gunstick@mastodon.opencloud.luG This user is from outside of this forum
    gunstick@mastodon.opencloud.luG This user is from outside of this forum
    gunstick@mastodon.opencloud.lu
    wrote last edited by
    #81

    @wdormann exactly.
    If it would say CVSS 7.3 more eyes would have looked (distro maintainers).
    If it says "exploit to root available" even more eyes would heve looked.
    Instead it is just technobabble to align the dilithium crystals, so nobody knows what it means.

    1 Reply Last reply
    0
    • gregkh@social.kernel.orgG gregkh@social.kernel.org
      @joshbressers @wdormann @deftpunk @Viss What do you mean, they told us, we fixed it, it got in some stable kernels, and so our work on the security team was done. The CVE team assigned a CVE after a while, and even gave it a CVSS score.

      The fact that no distro popped up that used older kernel versions to do the real work to backport to older kernels seems to be everyone's major problem here. That is outside of the kernel security team's work entirely. So take it up with the distros that people are paying support for to do this for them?

      And yes, Debian was vulnerable, that is not good, and once it was noticed people worked hard and quickly to fix that. Not bad for a community-based distro that no one pays for in my opinion.
      joshbressers@infosec.exchangeJ This user is from outside of this forum
      joshbressers@infosec.exchangeJ This user is from outside of this forum
      joshbressers@infosec.exchange
      wrote last edited by
      #82

      @gregkh @deftpunk @wdormann @Viss

      You said this wasn't reported to the kernel security team

      From where I sit (and I'm not in the middle of this) it seems like if you plan to make a website and give something a name, tell the securiy team

      If you're OK with the current process though I shall trust you on this, you're the expert, I'm just the peanut gallery

      gregkh@social.kernel.orgG 1 Reply Last reply
      0
      • joshbressers@infosec.exchangeJ joshbressers@infosec.exchange

        @gregkh @deftpunk @wdormann @Viss

        You said this wasn't reported to the kernel security team

        From where I sit (and I'm not in the middle of this) it seems like if you plan to make a website and give something a name, tell the securiy team

        If you're OK with the current process though I shall trust you on this, you're the expert, I'm just the peanut gallery

        gregkh@social.kernel.orgG This user is from outside of this forum
        gregkh@social.kernel.orgG This user is from outside of this forum
        gregkh@social.kernel.org
        wrote last edited by
        #83
        @joshbressers @deftpunk @wdormann @Viss the "announcement of a public web site and exploit" was not sent to the kernel security team. If you look at the timeline they published, they show what they sent the kernel security team and when, which seems to be correct to me.
        joshbressers@infosec.exchangeJ 1 Reply Last reply
        0
        • wdormann@infosec.exchangeW wdormann@infosec.exchange

          @alcastronic
          "Good" is a weird way to describe something that only works on some distributions.

          alcastronic@infosec.exchangeA This user is from outside of this forum
          alcastronic@infosec.exchangeA This user is from outside of this forum
          alcastronic@infosec.exchange
          wrote last edited by
          #84

          @wdormann
          With "good", I was referring to RHEL's proposal that requires a reboot to become effective.

          1 Reply Last reply
          0
          • gregkh@social.kernel.orgG gregkh@social.kernel.org
            @joshbressers @deftpunk @wdormann @Viss the "announcement of a public web site and exploit" was not sent to the kernel security team. If you look at the timeline they published, they show what they sent the kernel security team and when, which seems to be correct to me.
            joshbressers@infosec.exchangeJ This user is from outside of this forum
            joshbressers@infosec.exchangeJ This user is from outside of this forum
            joshbressers@infosec.exchange
            wrote last edited by
            #85

            @gregkh @deftpunk @wdormann @Viss

            I do think signaling intent to publish a website and make noise falls under a proper disclosure plan

            1 Reply Last reply
            0
            • gregkh@social.kernel.orgG gregkh@social.kernel.org
              @joshbressers @wdormann @deftpunk @Viss What do you mean, they told us, we fixed it, it got in some stable kernels, and so our work on the security team was done. The CVE team assigned a CVE after a while, and even gave it a CVSS score.

              The fact that no distro popped up that used older kernel versions to do the real work to backport to older kernels seems to be everyone's major problem here. That is outside of the kernel security team's work entirely. So take it up with the distros that people are paying support for to do this for them?

              And yes, Debian was vulnerable, that is not good, and once it was noticed people worked hard and quickly to fix that. Not bad for a community-based distro that no one pays for in my opinion.
              penguin42@mastodon.org.ukP This user is from outside of this forum
              penguin42@mastodon.org.ukP This user is from outside of this forum
              penguin42@mastodon.org.uk
              wrote last edited by
              #86

              @gregkh @deftpunk @joshbressers @wdormann @Viss How did 'The CVE team assigned a CVE after a while' work? I see the docs say it's the reporters job to tell the CVE team; but hmm that CVE assignment was ~3 weeks after the fix went in mainline - is there something that could help there? e.g. did linux-security give the CVE guys a nudge, or remind the original reporters they needed to do that?

              gregkh@social.kernel.orgG 1 Reply Last reply
              0
              • penguin42@mastodon.org.ukP penguin42@mastodon.org.uk

                @gregkh @deftpunk @joshbressers @wdormann @Viss How did 'The CVE team assigned a CVE after a while' work? I see the docs say it's the reporters job to tell the CVE team; but hmm that CVE assignment was ~3 weeks after the fix went in mainline - is there something that could help there? e.g. did linux-security give the CVE guys a nudge, or remind the original reporters they needed to do that?

                gregkh@social.kernel.orgG This user is from outside of this forum
                gregkh@social.kernel.orgG This user is from outside of this forum
                gregkh@social.kernel.org
                wrote last edited by
                #87
                @penguin42 @deftpunk @joshbressers @wdormann @Viss I honestly don't remember, and if I did, we don't publish who asked for CVE ids from us as that's generally not a good idea to do so (and is not a requirement for being a CNA).
                penguin42@mastodon.org.ukP 1 Reply Last reply
                0
                • gregkh@social.kernel.orgG gregkh@social.kernel.org
                  @penguin42 @deftpunk @joshbressers @wdormann @Viss I honestly don't remember, and if I did, we don't publish who asked for CVE ids from us as that's generally not a good idea to do so (and is not a requirement for being a CNA).
                  penguin42@mastodon.org.ukP This user is from outside of this forum
                  penguin42@mastodon.org.ukP This user is from outside of this forum
                  penguin42@mastodon.org.uk
                  wrote last edited by
                  #88

                  @gregkh @deftpunk @joshbressers @wdormann @Viss Hmm OK - tbh I think that gap to the CVE being issued is the biggest thing here (says he on the outside), if that was issued earlier I think there would have been a better chance a distro might have noticed. So perhaps if linux-security makes sure it reminds reporters to do it, and also asks them to give you a heads up before any announcement that might have helped here.

                  1 Reply Last reply
                  0
                  • gregkh@social.kernel.orgG gregkh@social.kernel.org
                    @joshbressers @wdormann @deftpunk @Viss What do you mean, they told us, we fixed it, it got in some stable kernels, and so our work on the security team was done. The CVE team assigned a CVE after a while, and even gave it a CVSS score.

                    The fact that no distro popped up that used older kernel versions to do the real work to backport to older kernels seems to be everyone's major problem here. That is outside of the kernel security team's work entirely. So take it up with the distros that people are paying support for to do this for them?

                    And yes, Debian was vulnerable, that is not good, and once it was noticed people worked hard and quickly to fix that. Not bad for a community-based distro that no one pays for in my opinion.
                    corsac@mastodon.socialC This user is from outside of this forum
                    corsac@mastodon.socialC This user is from outside of this forum
                    corsac@mastodon.social
                    wrote last edited by
                    #89

                    @gregkh @deftpunk @joshbressers @wdormann @Viss I think we (the distro security teams, speaking as a member of the Debian one) would have liked a heads up, including maybe to help backporting to the stable kernel we run. We didn't have that heads up, we discovered the thing like everyone else.

                    corsac@mastodon.socialC 1 Reply Last reply
                    0
                    • corsac@mastodon.socialC corsac@mastodon.social

                      @gregkh @deftpunk @joshbressers @wdormann @Viss I think we (the distro security teams, speaking as a member of the Debian one) would have liked a heads up, including maybe to help backporting to the stable kernel we run. We didn't have that heads up, we discovered the thing like everyone else.

                      corsac@mastodon.socialC This user is from outside of this forum
                      corsac@mastodon.socialC This user is from outside of this forum
                      corsac@mastodon.social
                      wrote last edited by
                      #90

                      @gregkh @deftpunk @joshbressers @wdormann @Viss

                      As Greg mentioned, vulnerability coordination is difficult, and it's hard to draw a line about who to include and who not to.

                      Maybe the researchers thought they did the right thing by notifying the kernel security team (and they did), and they thought it was enough. But I don't think it's written anywhere that the kernel security team will coordinate with downstream (or anyone else), and again I'm not sure it's really possible.

                      corsac@mastodon.socialC 1 Reply Last reply
                      0
                      • corsac@mastodon.socialC corsac@mastodon.social

                        @gregkh @deftpunk @joshbressers @wdormann @Viss

                        As Greg mentioned, vulnerability coordination is difficult, and it's hard to draw a line about who to include and who not to.

                        Maybe the researchers thought they did the right thing by notifying the kernel security team (and they did), and they thought it was enough. But I don't think it's written anywhere that the kernel security team will coordinate with downstream (or anyone else), and again I'm not sure it's really possible.

                        corsac@mastodon.socialC This user is from outside of this forum
                        corsac@mastodon.socialC This user is from outside of this forum
                        corsac@mastodon.social
                        wrote last edited by
                        #91

                        @gregkh @deftpunk @joshbressers @wdormann @Viss
                        Still, it leaves a bit of a bitter taste. Not sure how we can do better though.

                        aissen@social.treehouse.systemsA 1 Reply Last reply
                        0
                        • gregkh@social.kernel.orgG gregkh@social.kernel.org
                          @wdormann @joshbressers @Viss I love it how people think that "coordination of vulnerabilities" is actually something that can be done these days. Think of just who uses the software in question, and who should, and should not, be on such a list to get a "early disclosure notification".

                          As I have said for quite some time now, all early-disclosure lists are leaks, otherwise why would your government allow them to be in existence?

                          Software, and specifically open source software, runs the world. So should the whole world be on that notification list? 🙂
                          zmanion@infosec.exchangeZ This user is from outside of this forum
                          zmanion@infosec.exchangeZ This user is from outside of this forum
                          zmanion@infosec.exchange
                          wrote last edited by
                          #92

                          @gregkh @joshbressers @wdormann @Viss so there's absolutely no middle ground? When there is clearly a bug with security impact, give the distros list a week notice (two weeks max, per their policy). If it leaks, outcome is no worse than not notifying distros. The researcher can even do it instead of the kernel. At scale (Linux!) this seems like a Pareto distribution: major distros cover disproportionally most users.

                          gregkh@social.kernel.orgG 1 Reply Last reply
                          0
                          • corsac@mastodon.socialC corsac@mastodon.social

                            @gregkh @deftpunk @joshbressers @wdormann @Viss
                            Still, it leaves a bit of a bitter taste. Not sure how we can do better though.

                            aissen@social.treehouse.systemsA This user is from outside of this forum
                            aissen@social.treehouse.systemsA This user is from outside of this forum
                            aissen@social.treehouse.systems
                            wrote last edited by
                            #93

                            @corsac
                            > Not sure how we can do better though

                            A random idea, not sure how far it is from what you already do:
                            Bump automation where packages from latest stable branches are built and available with no human intervention in specific repositories. Manual promotion for generic repos should be as effortless as possible.

                            corsac@mastodon.socialC 1 Reply Last reply
                            0
                            • aissen@social.treehouse.systemsA aissen@social.treehouse.systems

                              @corsac
                              > Not sure how we can do better though

                              A random idea, not sure how far it is from what you already do:
                              Bump automation where packages from latest stable branches are built and available with no human intervention in specific repositories. Manual promotion for generic repos should be as effortless as possible.

                              corsac@mastodon.socialC This user is from outside of this forum
                              corsac@mastodon.socialC This user is from outside of this forum
                              corsac@mastodon.social
                              wrote last edited by
                              #94

                              @Aissen The process is already pretty scripted but there's still some manual things to do (whether in the kernel packaging or in the DSA processing).

                              On Apr 30th v6.12.85 was tagged at 1116Z and the DSA was sent at 2005Z. I'm unsure we can do much faster.

                              note: I didn't do anything this time, it's mainly the work of Salvatore Bonaccorso (as a volunteer): https://salsa.debian.org/kernel-team/linux/-/merge_requests/1895

                              1 Reply Last reply
                              0
                              • wdormann@infosec.exchangeW wdormann@infosec.exchange

                                @letoams @CliffsEsport
                                Up-to-date Fedora (42 or later) are not affected at the time of publication (Yesterday).
                                At least on this Fedora 42 system, the kernel was built on April 23 and in stable 2 days ago. Not a few hours ago.

                                letoams@defcon.socialL This user is from outside of this forum
                                letoams@defcon.socialL This user is from outside of this forum
                                letoams@defcon.social
                                wrote last edited by
                                #95

                                @wdormann weird because I had a successful test on up to date f42 yesterday …

                                wdormann@infosec.exchangeW 1 Reply Last reply
                                0
                                • letoams@defcon.socialL letoams@defcon.social

                                  @wdormann weird because I had a successful test on up to date f42 yesterday …

                                  wdormann@infosec.exchangeW This user is from outside of this forum
                                  wdormann@infosec.exchangeW This user is from outside of this forum
                                  wdormann@infosec.exchange
                                  wrote last edited by
                                  #96

                                  @letoams
                                  Got a snapshot that you can revert to?
                                  I'd like to see the evidence (along with showing the current kernel version).

                                  letoams@defcon.socialL 1 Reply Last reply
                                  0
                                  • zmanion@infosec.exchangeZ zmanion@infosec.exchange

                                    @gregkh @joshbressers @wdormann @Viss so there's absolutely no middle ground? When there is clearly a bug with security impact, give the distros list a week notice (two weeks max, per their policy). If it leaks, outcome is no worse than not notifying distros. The researcher can even do it instead of the kernel. At scale (Linux!) this seems like a Pareto distribution: major distros cover disproportionally most users.

                                    gregkh@social.kernel.orgG This user is from outside of this forum
                                    gregkh@social.kernel.orgG This user is from outside of this forum
                                    gregkh@social.kernel.org
                                    wrote last edited by
                                    #97
                                    @zmanion @joshbressers @wdormann @Viss Why is linux-distros somehow "special" enough to get these types of announcements and not everyone else? How exactly would you explain that to your favorite government entity?
                                    zmanion@infosec.exchangeZ 1 Reply Last reply
                                    0
                                    • wdormann@infosec.exchangeW wdormann@infosec.exchange

                                      @letoams
                                      Got a snapshot that you can revert to?
                                      I'd like to see the evidence (along with showing the current kernel version).

                                      letoams@defcon.socialL This user is from outside of this forum
                                      letoams@defcon.socialL This user is from outside of this forum
                                      letoams@defcon.social
                                      wrote last edited by
                                      #98

                                      @wdormann it seemed my VM was on 6.18.7–100 and hadn’t pulled in the updates yet

                                      1 Reply Last reply
                                      0
                                      • wdormann@infosec.exchangeW wdormann@infosec.exchange

                                        There's also a C version of it that works quite well. Even supports aarch64.

                                        Link Preview Image
                                        wdormann@infosec.exchangeW This user is from outside of this forum
                                        wdormann@infosec.exchangeW This user is from outside of this forum
                                        wdormann@infosec.exchange
                                        wrote last edited by
                                        #99

                                        The CEO of Theori / Xint has a damage-control thread explaining why they chose to release the vulnerability details in a way that left all of the Linux distros in the dark.

                                        TL;DR: With AI in the mix, the old way of coordinating vulnerabilities doesn't scale anymore.

                                        renerebe@chaos.socialR aristot73@infosec.exchangeA cirio@infosec.exchangeC slater450413@infosec.exchangeS jc0f0116@infosec.exchangeJ 5 Replies Last reply
                                        0
                                        • wdormann@infosec.exchangeW wdormann@infosec.exchange

                                          @k8ie
                                          Yes, it's clear that it was published as a "Look at us!" vehicle.

                                          But their abysmally bad coordination put every Linux user on the planet at risk, and is clear evidence that they don't care about anybody other than themselves.

                                          tezoatlipoca@mas.toT This user is from outside of this forum
                                          tezoatlipoca@mas.toT This user is from outside of this forum
                                          tezoatlipoca@mas.to
                                          wrote last edited by
                                          #100

                                          @wdormann @k8ie From what I've seen having been volunteered to be our infosec d00d, quarterbacking a coordination of affected downstream parties can sometimes be a big PITA. But no familiarity with the linux kernel CVD process - I presume its not as onerous as these guys are claiming?

                                          Like.. isn't there a dist.list/channel that all distro maintainers hang out on? call a meeting, answer questions, set a timetable, take minutes... pain yes but not that hard..?

                                          1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          • Login

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • World
                                          • Users
                                          • Groups