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.
  • aristot73@infosec.exchangeA aristot73@infosec.exchange

    @wdormann I wrote about what happens when vulnerability triage (in a broader sense) fails under the pressure from the expected surge of LLM discovered triage in the link below.

    I totally missed what you have highlighted here as a case where the CVE, CVD systems fail not because a vuln is not reported but because it is not appropriately (or accurately?) enriched and the report is subsequently lost in the noise.

    https://codeberg.org/tzafaar/Buffers_overflow_into_policy/src/branch/main/briefing%20notes/geer-unmitigatable-surprise-llm-age.md

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

    @aristot73
    Unless something changes, it won't be the last time this happens with the Linux kernel. πŸ˜•

    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...

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