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

    What went wrong with this case?

    Theori appear to have only contacted the linux kernel devs with the vulnerability, as opposed to going the usual CVD route that includes all of the major Linux distros.

    Why is this a problem? Since the linux kernel became a CNA, there has been a flood of CVEs for the Linux kernel. The Linux kernel devs' arguments is that any given kernel flaw could presumably be leveraged to behave as a vulnerability, and it's not worth their time to determine "vulnerability" or "not a vulnerability". Everything gets a CVE.

    Now the case with copy.fail? It was indeed reported to the kernel devs. And it got a CVE. A single CVE buried in flood of all of the Linux kernel CVEs.

    And it appears that every distro on the planet was blindsided by this proven-exploitable vulnerability because they were not given any warning. Or even any suggestion to pick this single CVE out of the sea of Linux kernel CVEs as worth cherry picking.

    Much to the chagrin of the Linux devs, RHEL doesn't use up-to-date Linux kernels. They cherry pick CVEs to backport to their chosen kernel version. (e.g. the latest and greates RHEL 10.1 uses 6.12.0, which was released November 17 2024). And in this world where bad actors like Theori don't involve vendors in vulnerability coordination, and just about every Linux kernel bug gets a CVE, this workflow fails. Hard.

    Good times...

    viss@mastodon.socialV This user is from outside of this forum
    viss@mastodon.socialV This user is from outside of this forum
    viss@mastodon.social
    wrote last edited by
    #43

    @wdormann cves turning into marketing vehicles for every company thats a cna is also undoubtedly creating problems in this vein

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

      What went wrong with this case?

      Theori appear to have only contacted the linux kernel devs with the vulnerability, as opposed to going the usual CVD route that includes all of the major Linux distros.

      Why is this a problem? Since the linux kernel became a CNA, there has been a flood of CVEs for the Linux kernel. The Linux kernel devs' arguments is that any given kernel flaw could presumably be leveraged to behave as a vulnerability, and it's not worth their time to determine "vulnerability" or "not a vulnerability". Everything gets a CVE.

      Now the case with copy.fail? It was indeed reported to the kernel devs. And it got a CVE. A single CVE buried in flood of all of the Linux kernel CVEs.

      And it appears that every distro on the planet was blindsided by this proven-exploitable vulnerability because they were not given any warning. Or even any suggestion to pick this single CVE out of the sea of Linux kernel CVEs as worth cherry picking.

      Much to the chagrin of the Linux devs, RHEL doesn't use up-to-date Linux kernels. They cherry pick CVEs to backport to their chosen kernel version. (e.g. the latest and greates RHEL 10.1 uses 6.12.0, which was released November 17 2024). And in this world where bad actors like Theori don't involve vendors in vulnerability coordination, and just about every Linux kernel bug gets a CVE, this workflow fails. Hard.

      Good times...

      merospit@infosec.exchangeM This user is from outside of this forum
      merospit@infosec.exchangeM This user is from outside of this forum
      merospit@infosec.exchange
      wrote last edited by
      #44

      @wdormann And a CVSS 7.8 won't standout when only 8.0+ typically get patched by OS. LPE are very underrated by CVSS.

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

        While this vulnerability seems to be discovered using AI ("Xint Code"), I have to assume that they also let the AI decide how to do the vulnerability coordination as well.

        • major builds are out as of this writing πŸ˜‚

          No distros have official updates for CVE-2026-31431. Fedora 42 and newer have updates, but no official advisory or acknowledgement of CVE-2026-31431. So with them it's unclear if it's even intentional. Red Hat, Ubuntu, Amazon Linux, and Suse all have advisories as of now, but NO updates.

        • disable the algif_aead module as a mitigation. πŸ˜‚

          Bespoke distros like RHEL don't use a module, it's compiled into the kernel.

        I can't figure out what the Xint Code angle is with this copyfail stuff. On one hand, yes, it is a true vulnerability that affects a LOT of Linux distros available. And they did submit the bug for fixing to the upstream kernel people.

        BUT the CVE has only existed for a week. And NONE of the distros IN THEIR ADVISORY had updates available at the time that they pulled the trigger for publication of the shiny copy.fail website.

        I struggle to think of how this even happens. In all my years of infosec, you're either on board with doing CVD (e.g. coordinating with the former CERT/CC) or you're not (dropping 0day). But this all fits bizarrely in the middle. The publication gives the guise that they did the right thing, (and please use our AI services). But at the same time, they clearly chose to release the vulnerability details and functional exploit before any distro had the ability to properly do anything about it.

        Either these Xint Code (Theori) people have a hidden agenda or ulterior motive that we aren't aware of yet. Or they're just really bad at coordinated vulnerability disclosure. You pick.

        lengau@mastodon.worldL This user is from outside of this forum
        lengau@mastodon.worldL This user is from outside of this forum
        lengau@mastodon.world
        wrote last edited by
        #45

        @wdormann

        > I have to assume that they also let the AI decide how to do the vulnerability coordination as well.

        r/MurderedByWords material right there.

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

          @squalouJenkins
          And interestingly, even downgrading to an older kernel (to ensure that nothing got backported into this otherwise vulnerable 6.1.166 kernel) still gives the same results. πŸ€”

          Link Preview Image
          squaloujenkins@fosstodon.orgS This user is from outside of this forum
          squaloujenkins@fosstodon.orgS This user is from outside of this forum
          squaloujenkins@fosstodon.org
          wrote last edited by
          #46

          @wdormann I 'll take this as good - even if weird - news.
          Less servers to patch...

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

            What went wrong with this case?

            Theori appear to have only contacted the linux kernel devs with the vulnerability, as opposed to going the usual CVD route that includes all of the major Linux distros.

            Why is this a problem? Since the linux kernel became a CNA, there has been a flood of CVEs for the Linux kernel. The Linux kernel devs' arguments is that any given kernel flaw could presumably be leveraged to behave as a vulnerability, and it's not worth their time to determine "vulnerability" or "not a vulnerability". Everything gets a CVE.

            Now the case with copy.fail? It was indeed reported to the kernel devs. And it got a CVE. A single CVE buried in flood of all of the Linux kernel CVEs.

            And it appears that every distro on the planet was blindsided by this proven-exploitable vulnerability because they were not given any warning. Or even any suggestion to pick this single CVE out of the sea of Linux kernel CVEs as worth cherry picking.

            Much to the chagrin of the Linux devs, RHEL doesn't use up-to-date Linux kernels. They cherry pick CVEs to backport to their chosen kernel version. (e.g. the latest and greates RHEL 10.1 uses 6.12.0, which was released November 17 2024). And in this world where bad actors like Theori don't involve vendors in vulnerability coordination, and just about every Linux kernel bug gets a CVE, this workflow fails. Hard.

            Good times...

            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
            #47

            Unlike what the buffoons at Theori published as a "mitigation", the folks at Red Hat actually published a viable mitigation for CopyFail CVE-2026-31431.

            Specifically, edit your grub (or whatever you use to load your kernel) configuration to have one of the following arguments:
            initcall_blacklist=algif_aead_init
            initcall_blacklist=af_alg_init
            initcall_blacklist=crypto_authenc_esn_module_init

            With such boot arguments to the Linux kernel, the affected bits won't be reachable.

            wdormann@infosec.exchangeW mjdxp@labyrinth.zoneM alcastronic@infosec.exchangeA oscherler@tooting.chO 4 Replies Last reply
            0
            • viss@mastodon.socialV viss@mastodon.social

              @wdormann cves turning into marketing vehicles for every company thats a cna is also undoubtedly creating problems in this vein

              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
              #48

              @Viss @wdormann every AI vulnerability company wants to find something juicy, and have no idea how to coordinate the findings

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

                @Viss @wdormann every AI vulnerability company wants to find something juicy, and have no idea how to coordinate the findings

                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
                #49

                @joshbressers @Viss
                If only there were human beings out there who had any sort of experience with coordinating vulnerabilities... πŸ˜‚

                joshbressers@infosec.exchangeJ gregkh@social.kernel.orgG 2 Replies Last reply
                0
                • wdormann@infosec.exchangeW wdormann@infosec.exchange

                  @joshbressers @Viss
                  If only there were human beings out there who had any sort of experience with coordinating vulnerabilities... πŸ˜‚

                  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
                  #50

                  @wdormann @Viss I mean, in their defense we're not easy to find outside a very specific bubble

                  And we have historically been gigantic assholes

                  1 Reply Last reply
                  0
                  • squaloujenkins@fosstodon.orgS squaloujenkins@fosstodon.org

                    @wdormann I 'll take this as good - even if weird - news.
                    Less servers to patch...

                    natanbc@mastodon.socialN This user is from outside of this forum
                    natanbc@mastodon.socialN This user is from outside of this forum
                    natanbc@mastodon.social
                    wrote last edited by
                    #51

                    @squalouJenkins @wdormann This[1] exploit worked on AL2023 `2023.11.20260413`, the modprobe.d + rmmod combo "fixed" it (`bind: No such file or directory`)

                    [1]: https://gist.github.com/blasty/d7b5d0599b154c9ec83c182acbd56e8b

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

                      Unlike what the buffoons at Theori published as a "mitigation", the folks at Red Hat actually published a viable mitigation for CopyFail CVE-2026-31431.

                      Specifically, edit your grub (or whatever you use to load your kernel) configuration to have one of the following arguments:
                      initcall_blacklist=algif_aead_init
                      initcall_blacklist=af_alg_init
                      initcall_blacklist=crypto_authenc_esn_module_init

                      With such boot arguments to the Linux kernel, the affected bits won't be reachable.

                      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
                      #52

                      As mentioned earlier in this thread, the su corruption route was only one possible strategy to be used by this exploit.

                      Here's another variant of the exploit that doesn't have to rely on such things to achieve its goal.

                      For example, the simple escalate argument simply removes the password requirement for su'ing to root. There are other payloads also possible.

                      Such exploits will not have process 'su' launched '/bin/sh IOCs in the syslogs. Perhaps all that is relevant is the alg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac-sha256-lib,cbc-aes-aesni)) part. But there's no evidence of what was done.

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

                        As mentioned earlier in this thread, the su corruption route was only one possible strategy to be used by this exploit.

                        Here's another variant of the exploit that doesn't have to rely on such things to achieve its goal.

                        For example, the simple escalate argument simply removes the password requirement for su'ing to root. There are other payloads also possible.

                        Such exploits will not have process 'su' launched '/bin/sh IOCs in the syslogs. Perhaps all that is relevant is the alg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac-sha256-lib,cbc-aes-aesni)) part. But there's no evidence of what was done.

                        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
                        #53

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

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

                          @joshbressers @Viss
                          If only there were human beings out there who had any sort of experience with coordinating vulnerabilities... πŸ˜‚

                          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
                          #54
                          @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? πŸ™‚
                          deftpunk@fosstodon.orgD zmanion@infosec.exchangeZ joshbressers@infosec.exchangeJ 3 Replies Last reply
                          0
                          • wdormann@infosec.exchangeW wdormann@infosec.exchange

                            Unlike what the buffoons at Theori published as a "mitigation", the folks at Red Hat actually published a viable mitigation for CopyFail CVE-2026-31431.

                            Specifically, edit your grub (or whatever you use to load your kernel) configuration to have one of the following arguments:
                            initcall_blacklist=algif_aead_init
                            initcall_blacklist=af_alg_init
                            initcall_blacklist=crypto_authenc_esn_module_init

                            With such boot arguments to the Linux kernel, the affected bits won't be reachable.

                            mjdxp@labyrinth.zoneM This user is from outside of this forum
                            mjdxp@labyrinth.zoneM This user is from outside of this forum
                            mjdxp@labyrinth.zone
                            wrote last edited by
                            #55
                            @wdormann sorry this is off topic, but this is the first time i've ever seen anyone using the stock xfce layout
                            moses_izumi@fe.disroot.orgM dazo@infosec.exchangeD 2 Replies Last reply
                            0
                            • wdormann@infosec.exchangeW wdormann@infosec.exchange

                              What went wrong with this case?

                              Theori appear to have only contacted the linux kernel devs with the vulnerability, as opposed to going the usual CVD route that includes all of the major Linux distros.

                              Why is this a problem? Since the linux kernel became a CNA, there has been a flood of CVEs for the Linux kernel. The Linux kernel devs' arguments is that any given kernel flaw could presumably be leveraged to behave as a vulnerability, and it's not worth their time to determine "vulnerability" or "not a vulnerability". Everything gets a CVE.

                              Now the case with copy.fail? It was indeed reported to the kernel devs. And it got a CVE. A single CVE buried in flood of all of the Linux kernel CVEs.

                              And it appears that every distro on the planet was blindsided by this proven-exploitable vulnerability because they were not given any warning. Or even any suggestion to pick this single CVE out of the sea of Linux kernel CVEs as worth cherry picking.

                              Much to the chagrin of the Linux devs, RHEL doesn't use up-to-date Linux kernels. They cherry pick CVEs to backport to their chosen kernel version. (e.g. the latest and greates RHEL 10.1 uses 6.12.0, which was released November 17 2024). And in this world where bad actors like Theori don't involve vendors in vulnerability coordination, and just about every Linux kernel bug gets a CVE, this workflow fails. Hard.

                              Good times...

                              brotundspiele@chaos.socialB This user is from outside of this forum
                              brotundspiele@chaos.socialB This user is from outside of this forum
                              brotundspiele@chaos.social
                              wrote last edited by
                              #56

                              @wdormann And that's why you don't cherry pick bugfixes. If the Linux kernel team says they can't tell for sure if a bug might be a security issue, how do Redhat, Debian, Canonical etc. have the hubris to think they are better at that?

                              My distros kernel was fixed on 11.4.2026, just hours after the kernel team released their fix. I use Arch by the way.

                              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? πŸ™‚
                                deftpunk@fosstodon.orgD This user is from outside of this forum
                                deftpunk@fosstodon.orgD This user is from outside of this forum
                                deftpunk@fosstodon.org
                                wrote last edited by
                                #57

                                @gregkh @joshbressers @wdormann @Viss So just to clarify: In your view, would it have been equally fine to announce without contacting the Linux security team?

                                gregkh@social.kernel.orgG 1 Reply Last reply
                                0
                                • deftpunk@fosstodon.orgD deftpunk@fosstodon.org

                                  @gregkh @joshbressers @wdormann @Viss So just to clarify: In your view, would it have been equally fine to announce without contacting the Linux security team?

                                  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
                                  #58
                                  @deftpunk @joshbressers @wdormann @Viss no one did contact the kernel security team before they announced this. It was nice enough that they sent us a bug report and we got it fixed and pushed out to the latest stable kernel releases. That's all I can ever hope for.
                                  joshbressers@infosec.exchangeJ 1 Reply Last reply
                                  0
                                  • mjdxp@labyrinth.zoneM mjdxp@labyrinth.zone
                                    @wdormann sorry this is off topic, but this is the first time i've ever seen anyone using the stock xfce layout
                                    moses_izumi@fe.disroot.orgM This user is from outside of this forum
                                    moses_izumi@fe.disroot.orgM This user is from outside of this forum
                                    moses_izumi@fe.disroot.org
                                    wrote last edited by
                                    #59
                                    @mjdxp @wdormann
                                    Yeah I always get rid of the dock.
                                    On my latest run I also disabled the start menu, because I prefer the Application Finder program.
                                    1 Reply Last reply
                                    0
                                    • wdormann@infosec.exchangeW wdormann@infosec.exchange

                                      What went wrong with this case?

                                      Theori appear to have only contacted the linux kernel devs with the vulnerability, as opposed to going the usual CVD route that includes all of the major Linux distros.

                                      Why is this a problem? Since the linux kernel became a CNA, there has been a flood of CVEs for the Linux kernel. The Linux kernel devs' arguments is that any given kernel flaw could presumably be leveraged to behave as a vulnerability, and it's not worth their time to determine "vulnerability" or "not a vulnerability". Everything gets a CVE.

                                      Now the case with copy.fail? It was indeed reported to the kernel devs. And it got a CVE. A single CVE buried in flood of all of the Linux kernel CVEs.

                                      And it appears that every distro on the planet was blindsided by this proven-exploitable vulnerability because they were not given any warning. Or even any suggestion to pick this single CVE out of the sea of Linux kernel CVEs as worth cherry picking.

                                      Much to the chagrin of the Linux devs, RHEL doesn't use up-to-date Linux kernels. They cherry pick CVEs to backport to their chosen kernel version. (e.g. the latest and greates RHEL 10.1 uses 6.12.0, which was released November 17 2024). And in this world where bad actors like Theori don't involve vendors in vulnerability coordination, and just about every Linux kernel bug gets a CVE, this workflow fails. Hard.

                                      Good times...

                                      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
                                      #60

                                      @wdormann did the initial CVE have a CVSS score and LPE written all over it?
                                      The kernel patch I saw only says "revert to previous way of doing things"

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

                                        Unlike what the buffoons at Theori published as a "mitigation", the folks at Red Hat actually published a viable mitigation for CopyFail CVE-2026-31431.

                                        Specifically, edit your grub (or whatever you use to load your kernel) configuration to have one of the following arguments:
                                        initcall_blacklist=algif_aead_init
                                        initcall_blacklist=af_alg_init
                                        initcall_blacklist=crypto_authenc_esn_module_init

                                        With such boot arguments to the Linux kernel, the affected bits won't be reachable.

                                        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
                                        #61

                                        @wdormann The mitigation to block the modules on boot is good. There is one drawback tough - it requires a reboot. Something that may not be immediately feasible in every environment. On RHEL, this is, however, needed, as algif_aead is part of the kernel.

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

                                          @wdormann The mitigation to block the modules on boot is good. There is one drawback tough - it requires a reboot. Something that may not be immediately feasible in every environment. On RHEL, this is, however, needed, as algif_aead is part of the kernel.

                                          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
                                          #62

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

                                          alcastronic@infosec.exchangeA 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