CVE-2026-64600

Vendor product assessments

Showing 32 of 2223 vendor product statements; 2191 omitted. Read the full vendor advisory.

• kernel-0:6.12.0-231.17.el10nv.aarch64 as a component of NVIDIA for RHEL 10 · fixed

  Vendor assessment for this product only.

  pkg:rpm/redhat/[email protected]?arch=aarch64

  • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 The system must be rebooted for this update to take effect. Vendor guidance
  • workaround: This vulnerability can be mitigated using a SystemTap script. To create and apply the mitigation, follow the steps below: 1. Install and configure SystemTap Install the SystemTap package and its dependencies following the instructions at: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/monitoring_and_managing_system_status_and_performance/getting-started-with-systemtap 2. Create the mitigation script Create a file named `refluxfs_mitigation.stp` with the following contents: ~~~ probe begin { printf("refluxfs mitigation loaded\n") } probe module("xfs").function("xfs_file_remap_range").call { $remap_flags = 0xffff } probe module("xfs").function("xfs_file_remap_range").return { $return = -95 } probe end { printf("refluxfs mitigation unloaded\n") } ~~~ 3. Load the mitigation As the `root` user, execute SystemTap in guru mode: ~~~ stap -g refluxfs_mitigation.stp ~~~ Once the script is compiled and loaded, the following message will appear: ~~~ refluxfs mitigation loaded ~~~ With the mitigation active, any application attempting to use reflink to copy files will receive `-EOPNOTSUPP` (`-95`) when calling the `FICLONE` ioctl (or its variants) or the `copy_file_range()` syscall. Important considerations: 1. SystemTap scripts are compiled into kernel modules. On systems with Secure Boot enabled, the kernel is in lockdown mode and will only load modules signed with a valid Secure Boot key or a key enrolled in the MOK. SystemTap can sign the generated module at compile time, but the user is responsible for key management. For instructions, refer to the "Sign a SystemTap module" section of: https://www.redhat.com/en/blog/secure-boot-systemtap 2. The SystemTap module is not persistent across reboots. If the machine is restarted or the `stap` process is terminated, the module will be unloaded and the mitigation must be reapplied. 3. Programs that rely on CoW/reflink without a fallback mechanism may fail, as reflink operations will be unavailable on any XFS filesystem while the mitigation is loaded. This includes the `cp` command when run with `--reflink=always`. In that case, use `--reflink=auto` instead, which is the default behavior in Red Hat Enterprise Linux.

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-debuginfo-common-aarch64-0:6.12.0-211.34.1.el10_2.aarch64 as a component of Red Hat Enterprise Linux AppStream (v. 10) · fixed

  Vendor assessment for this product only.

  pkg:rpm/redhat/[email protected]_2?arch=aarch64

  • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 The system must be rebooted for this update to take effect. Vendor guidance
  • workaround: This vulnerability can be mitigated using a SystemTap script. To create and apply the mitigation, follow the steps below: 1. Install and configure SystemTap Install the SystemTap package and its dependencies following the instructions at: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/monitoring_and_managing_system_status_and_performance/getting-started-with-systemtap 2. Create the mitigation script Create a file named `refluxfs_mitigation.stp` with the following contents: ~~~ probe begin { printf("refluxfs mitigation loaded\n") } probe module("xfs").function("xfs_file_remap_range").call { $remap_flags = 0xffff } probe module("xfs").function("xfs_file_remap_range").return { $return = -95 } probe end { printf("refluxfs mitigation unloaded\n") } ~~~ 3. Load the mitigation As the `root` user, execute SystemTap in guru mode: ~~~ stap -g refluxfs_mitigation.stp ~~~ Once the script is compiled and loaded, the following message will appear: ~~~ refluxfs mitigation loaded ~~~ With the mitigation active, any application attempting to use reflink to copy files will receive `-EOPNOTSUPP` (`-95`) when calling the `FICLONE` ioctl (or its variants) or the `copy_file_range()` syscall. Important considerations: 1. SystemTap scripts are compiled into kernel modules. On systems with Secure Boot enabled, the kernel is in lockdown mode and will only load modules signed with a valid Secure Boot key or a key enrolled in the MOK. SystemTap can sign the generated module at compile time, but the user is responsible for key management. For instructions, refer to the "Sign a SystemTap module" section of: https://www.redhat.com/en/blog/secure-boot-systemtap 2. The SystemTap module is not persistent across reboots. If the machine is restarted or the `stap` process is terminated, the module will be unloaded and the mitigation must be reapplied. 3. Programs that rely on CoW/reflink without a fallback mechanism may fail, as reflink operations will be unavailable on any XFS filesystem while the mitigation is loaded. This includes the `cp` command when run with `--reflink=always`. In that case, use `--reflink=auto` instead, which is the default behavior in Red Hat Enterprise Linux.

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-devel-0:5.14.0-427.138.1.el9_4.aarch64 as a component of Red Hat Enterprise Linux AppStream E4S (v.9.4) · fixed

  Vendor assessment for this product only.

  pkg:rpm/redhat/[email protected]_4?arch=aarch64

  • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 The system must be rebooted for this update to take effect. Vendor guidance
  • workaround: This vulnerability can be mitigated using a SystemTap script. To create and apply the mitigation, follow the steps below: 1. Install and configure SystemTap Install the SystemTap package and its dependencies following the instructions at: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/monitoring_and_managing_system_status_and_performance/getting-started-with-systemtap 2. Create the mitigation script Create a file named `refluxfs_mitigation.stp` with the following contents: ~~~ probe begin { printf("refluxfs mitigation loaded\n") } probe module("xfs").function("xfs_file_remap_range").call { $remap_flags = 0xffff } probe module("xfs").function("xfs_file_remap_range").return { $return = -95 } probe end { printf("refluxfs mitigation unloaded\n") } ~~~ 3. Load the mitigation As the `root` user, execute SystemTap in guru mode: ~~~ stap -g refluxfs_mitigation.stp ~~~ Once the script is compiled and loaded, the following message will appear: ~~~ refluxfs mitigation loaded ~~~ With the mitigation active, any application attempting to use reflink to copy files will receive `-EOPNOTSUPP` (`-95`) when calling the `FICLONE` ioctl (or its variants) or the `copy_file_range()` syscall. Important considerations: 1. SystemTap scripts are compiled into kernel modules. On systems with Secure Boot enabled, the kernel is in lockdown mode and will only load modules signed with a valid Secure Boot key or a key enrolled in the MOK. SystemTap can sign the generated module at compile time, but the user is responsible for key management. For instructions, refer to the "Sign a SystemTap module" section of: https://www.redhat.com/en/blog/secure-boot-systemtap 2. The SystemTap module is not persistent across reboots. If the machine is restarted or the `stap` process is terminated, the module will be unloaded and the mitigation must be reapplied. 3. Programs that rely on CoW/reflink without a fallback mechanism may fail, as reflink operations will be unavailable on any XFS filesystem while the mitigation is loaded. This includes the `cp` command when run with `--reflink=always`. In that case, use `--reflink=auto` instead, which is the default behavior in Red Hat Enterprise Linux.

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-debuginfo-common-x86_64-0:5.14.0-687.26.1.el9_8.x86_64 as a component of Red Hat Enterprise Linux AppStream (v. 9) · fixed

  Vendor assessment for this product only.

  pkg:rpm/redhat/[email protected]_8?arch=x86_64

  • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 The system must be rebooted for this update to take effect. Vendor guidance
  • workaround: This vulnerability can be mitigated using a SystemTap script. To create and apply the mitigation, follow the steps below: 1. Install and configure SystemTap Install the SystemTap package and its dependencies following the instructions at: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/monitoring_and_managing_system_status_and_performance/getting-started-with-systemtap 2. Create the mitigation script Create a file named `refluxfs_mitigation.stp` with the following contents: ~~~ probe begin { printf("refluxfs mitigation loaded\n") } probe module("xfs").function("xfs_file_remap_range").call { $remap_flags = 0xffff } probe module("xfs").function("xfs_file_remap_range").return { $return = -95 } probe end { printf("refluxfs mitigation unloaded\n") } ~~~ 3. Load the mitigation As the `root` user, execute SystemTap in guru mode: ~~~ stap -g refluxfs_mitigation.stp ~~~ Once the script is compiled and loaded, the following message will appear: ~~~ refluxfs mitigation loaded ~~~ With the mitigation active, any application attempting to use reflink to copy files will receive `-EOPNOTSUPP` (`-95`) when calling the `FICLONE` ioctl (or its variants) or the `copy_file_range()` syscall. Important considerations: 1. SystemTap scripts are compiled into kernel modules. On systems with Secure Boot enabled, the kernel is in lockdown mode and will only load modules signed with a valid Secure Boot key or a key enrolled in the MOK. SystemTap can sign the generated module at compile time, but the user is responsible for key management. For instructions, refer to the "Sign a SystemTap module" section of: https://www.redhat.com/en/blog/secure-boot-systemtap 2. The SystemTap module is not persistent across reboots. If the machine is restarted or the `stap` process is terminated, the module will be unloaded and the mitigation must be reapplied. 3. Programs that rely on CoW/reflink without a fallback mechanism may fail, as reflink operations will be unavailable on any XFS filesystem while the mitigation is loaded. This includes the `cp` command when run with `--reflink=always`. In that case, use `--reflink=auto` instead, which is the default behavior in Red Hat Enterprise Linux.

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• libperf-debuginfo-0:6.12.0-55.89.1.el10_0.aarch64 as a component of Red Hat Enterprise Linux BaseOS EUS (v. 10.0) · fixed

  Vendor assessment for this product only.

  pkg:rpm/redhat/[email protected]_0?arch=aarch64

  • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 The system must be rebooted for this update to take effect. Vendor guidance
  • workaround: This vulnerability can be mitigated using a SystemTap script. To create and apply the mitigation, follow the steps below: 1. Install and configure SystemTap Install the SystemTap package and its dependencies following the instructions at: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/monitoring_and_managing_system_status_and_performance/getting-started-with-systemtap 2. Create the mitigation script Create a file named `refluxfs_mitigation.stp` with the following contents: ~~~ probe begin { printf("refluxfs mitigation loaded\n") } probe module("xfs").function("xfs_file_remap_range").call { $remap_flags = 0xffff } probe module("xfs").function("xfs_file_remap_range").return { $return = -95 } probe end { printf("refluxfs mitigation unloaded\n") } ~~~ 3. Load the mitigation As the `root` user, execute SystemTap in guru mode: ~~~ stap -g refluxfs_mitigation.stp ~~~ Once the script is compiled and loaded, the following message will appear: ~~~ refluxfs mitigation loaded ~~~ With the mitigation active, any application attempting to use reflink to copy files will receive `-EOPNOTSUPP` (`-95`) when calling the `FICLONE` ioctl (or its variants) or the `copy_file_range()` syscall. Important considerations: 1. SystemTap scripts are compiled into kernel modules. On systems with Secure Boot enabled, the kernel is in lockdown mode and will only load modules signed with a valid Secure Boot key or a key enrolled in the MOK. SystemTap can sign the generated module at compile time, but the user is responsible for key management. For instructions, refer to the "Sign a SystemTap module" section of: https://www.redhat.com/en/blog/secure-boot-systemtap 2. The SystemTap module is not persistent across reboots. If the machine is restarted or the `stap` process is terminated, the module will be unloaded and the mitigation must be reapplied. 3. Programs that rely on CoW/reflink without a fallback mechanism may fail, as reflink operations will be unavailable on any XFS filesystem while the mitigation is loaded. This includes the `cp` command when run with `--reflink=always`. In that case, use `--reflink=auto` instead, which is the default behavior in Red Hat Enterprise Linux.

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-debug-0:4.18.0-553.144.1.el8_10.aarch64 as a component of Red Hat Enterprise Linux BaseOS (v. 8) · fixed

  Vendor assessment for this product only.

  pkg:rpm/redhat/[email protected]_10?arch=aarch64

  • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 The system must be rebooted for this update to take effect. Vendor guidance
  • workaround: This vulnerability can be mitigated using a SystemTap script. To create and apply the mitigation, follow the steps below: 1. Install and configure SystemTap Install the SystemTap package and its dependencies following the instructions at: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/monitoring_and_managing_system_status_and_performance/getting-started-with-systemtap 2. Create the mitigation script Create a file named `refluxfs_mitigation.stp` with the following contents: ~~~ probe begin { printf("refluxfs mitigation loaded\n") } probe module("xfs").function("xfs_file_remap_range").call { $remap_flags = 0xffff } probe module("xfs").function("xfs_file_remap_range").return { $return = -95 } probe end { printf("refluxfs mitigation unloaded\n") } ~~~ 3. Load the mitigation As the `root` user, execute SystemTap in guru mode: ~~~ stap -g refluxfs_mitigation.stp ~~~ Once the script is compiled and loaded, the following message will appear: ~~~ refluxfs mitigation loaded ~~~ With the mitigation active, any application attempting to use reflink to copy files will receive `-EOPNOTSUPP` (`-95`) when calling the `FICLONE` ioctl (or its variants) or the `copy_file_range()` syscall. Important considerations: 1. SystemTap scripts are compiled into kernel modules. On systems with Secure Boot enabled, the kernel is in lockdown mode and will only load modules signed with a valid Secure Boot key or a key enrolled in the MOK. SystemTap can sign the generated module at compile time, but the user is responsible for key management. For instructions, refer to the "Sign a SystemTap module" section of: https://www.redhat.com/en/blog/secure-boot-systemtap 2. The SystemTap module is not persistent across reboots. If the machine is restarted or the `stap` process is terminated, the module will be unloaded and the mitigation must be reapplied. 3. Programs that rely on CoW/reflink without a fallback mechanism may fail, as reflink operations will be unavailable on any XFS filesystem while the mitigation is loaded. This includes the `cp` command when run with `--reflink=always`. In that case, use `--reflink=auto` instead, which is the default behavior in Red Hat Enterprise Linux.

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-debug-core-0:4.18.0-305.198.1.el8_4.x86_64 as a component of Red Hat Enterprise Linux BaseOS EUS EXTENSION (v.8.4) · fixed

  Vendor assessment for this product only.

  pkg:rpm/redhat/[email protected]_4?arch=x86_64

  • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 The system must be rebooted for this update to take effect. Vendor guidance
  • workaround: This vulnerability can be mitigated using a SystemTap script. To create and apply the mitigation, follow the steps below: 1. Install and configure SystemTap Install the SystemTap package and its dependencies following the instructions at: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/monitoring_and_managing_system_status_and_performance/getting-started-with-systemtap 2. Create the mitigation script Create a file named `refluxfs_mitigation.stp` with the following contents: ~~~ probe begin { printf("refluxfs mitigation loaded\n") } probe module("xfs").function("xfs_file_remap_range").call { $remap_flags = 0xffff } probe module("xfs").function("xfs_file_remap_range").return { $return = -95 } probe end { printf("refluxfs mitigation unloaded\n") } ~~~ 3. Load the mitigation As the `root` user, execute SystemTap in guru mode: ~~~ stap -g refluxfs_mitigation.stp ~~~ Once the script is compiled and loaded, the following message will appear: ~~~ refluxfs mitigation loaded ~~~ With the mitigation active, any application attempting to use reflink to copy files will receive `-EOPNOTSUPP` (`-95`) when calling the `FICLONE` ioctl (or its variants) or the `copy_file_range()` syscall. Important considerations: 1. SystemTap scripts are compiled into kernel modules. On systems with Secure Boot enabled, the kernel is in lockdown mode and will only load modules signed with a valid Secure Boot key or a key enrolled in the MOK. SystemTap can sign the generated module at compile time, but the user is responsible for key management. For instructions, refer to the "Sign a SystemTap module" section of: https://www.redhat.com/en/blog/secure-boot-systemtap 2. The SystemTap module is not persistent across reboots. If the machine is restarted or the `stap` process is terminated, the module will be unloaded and the mitigation must be reapplied. 3. Programs that rely on CoW/reflink without a fallback mechanism may fail, as reflink operations will be unavailable on any XFS filesystem while the mitigation is loaded. This includes the `cp` command when run with `--reflink=always`. In that case, use `--reflink=auto` instead, which is the default behavior in Red Hat Enterprise Linux.

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• perf-debuginfo-0:4.18.0-477.154.1.el8_8.x86_64 as a component of Red Hat Enterprise Linux BaseOS E4S (v.8.8) · fixed

  Vendor assessment for this product only.

  pkg:rpm/redhat/[email protected]_8?arch=x86_64

  • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 The system must be rebooted for this update to take effect. Vendor guidance
  • workaround: This vulnerability can be mitigated using a SystemTap script. To create and apply the mitigation, follow the steps below: 1. Install and configure SystemTap Install the SystemTap package and its dependencies following the instructions at: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/monitoring_and_managing_system_status_and_performance/getting-started-with-systemtap 2. Create the mitigation script Create a file named `refluxfs_mitigation.stp` with the following contents: ~~~ probe begin { printf("refluxfs mitigation loaded\n") } probe module("xfs").function("xfs_file_remap_range").call { $remap_flags = 0xffff } probe module("xfs").function("xfs_file_remap_range").return { $return = -95 } probe end { printf("refluxfs mitigation unloaded\n") } ~~~ 3. Load the mitigation As the `root` user, execute SystemTap in guru mode: ~~~ stap -g refluxfs_mitigation.stp ~~~ Once the script is compiled and loaded, the following message will appear: ~~~ refluxfs mitigation loaded ~~~ With the mitigation active, any application attempting to use reflink to copy files will receive `-EOPNOTSUPP` (`-95`) when calling the `FICLONE` ioctl (or its variants) or the `copy_file_range()` syscall. Important considerations: 1. SystemTap scripts are compiled into kernel modules. On systems with Secure Boot enabled, the kernel is in lockdown mode and will only load modules signed with a valid Secure Boot key or a key enrolled in the MOK. SystemTap can sign the generated module at compile time, but the user is responsible for key management. For instructions, refer to the "Sign a SystemTap module" section of: https://www.redhat.com/en/blog/secure-boot-systemtap 2. The SystemTap module is not persistent across reboots. If the machine is restarted or the `stap` process is terminated, the module will be unloaded and the mitigation must be reapplied. 3. Programs that rely on CoW/reflink without a fallback mechanism may fail, as reflink operations will be unavailable on any XFS filesystem while the mitigation is loaded. This includes the `cp` command when run with `--reflink=always`. In that case, use `--reflink=auto` instead, which is the default behavior in Red Hat Enterprise Linux.

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kpatch-patch-5_14_0-284_158_1-0:1-8.el9_2.x86_64 as a component of Red Hat Enterprise Linux BaseOS E4S (v.9.2) · fixed

  Vendor assessment for this product only.

  pkg:rpm/redhat/[email protected]_2?arch=x86_64

  • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Vendor guidance
  • workaround: This vulnerability can be mitigated using a SystemTap script. To create and apply the mitigation, follow the steps below: 1. Install and configure SystemTap Install the SystemTap package and its dependencies following the instructions at: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/monitoring_and_managing_system_status_and_performance/getting-started-with-systemtap 2. Create the mitigation script Create a file named `refluxfs_mitigation.stp` with the following contents: ~~~ probe begin { printf("refluxfs mitigation loaded\n") } probe module("xfs").function("xfs_file_remap_range").call { $remap_flags = 0xffff } probe module("xfs").function("xfs_file_remap_range").return { $return = -95 } probe end { printf("refluxfs mitigation unloaded\n") } ~~~ 3. Load the mitigation As the `root` user, execute SystemTap in guru mode: ~~~ stap -g refluxfs_mitigation.stp ~~~ Once the script is compiled and loaded, the following message will appear: ~~~ refluxfs mitigation loaded ~~~ With the mitigation active, any application attempting to use reflink to copy files will receive `-EOPNOTSUPP` (`-95`) when calling the `FICLONE` ioctl (or its variants) or the `copy_file_range()` syscall. Important considerations: 1. SystemTap scripts are compiled into kernel modules. On systems with Secure Boot enabled, the kernel is in lockdown mode and will only load modules signed with a valid Secure Boot key or a key enrolled in the MOK. SystemTap can sign the generated module at compile time, but the user is responsible for key management. For instructions, refer to the "Sign a SystemTap module" section of: https://www.redhat.com/en/blog/secure-boot-systemtap 2. The SystemTap module is not persistent across reboots. If the machine is restarted or the `stap` process is terminated, the module will be unloaded and the mitigation must be reapplied. 3. Programs that rely on CoW/reflink without a fallback mechanism may fail, as reflink operations will be unavailable on any XFS filesystem while the mitigation is loaded. This includes the `cp` command when run with `--reflink=always`. In that case, use `--reflink=auto` instead, which is the default behavior in Red Hat Enterprise Linux.

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kpatch-patch-5_14_0-427_68_2-debuginfo-0:1-18.el9_4.ppc64le as a component of Red Hat Enterprise Linux BaseOS E4S (v.9.4) · fixed

  Vendor assessment for this product only.

  pkg:rpm/redhat/[email protected]_4?arch=ppc64le

  • vendor fix: Before applying this update, make sure all previously released errata relevant to your system have been applied. For details on how to apply this update, refer to: https://access.redhat.com/articles/11258 Vendor guidance
  • workaround: This vulnerability can be mitigated using a SystemTap script. To create and apply the mitigation, follow the steps below: 1. Install and configure SystemTap Install the SystemTap package and its dependencies following the instructions at: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/monitoring_and_managing_system_status_and_performance/getting-started-with-systemtap 2. Create the mitigation script Create a file named `refluxfs_mitigation.stp` with the following contents: ~~~ probe begin { printf("refluxfs mitigation loaded\n") } probe module("xfs").function("xfs_file_remap_range").call { $remap_flags = 0xffff } probe module("xfs").function("xfs_file_remap_range").return { $return = -95 } probe end { printf("refluxfs mitigation unloaded\n") } ~~~ 3. Load the mitigation As the `root` user, execute SystemTap in guru mode: ~~~ stap -g refluxfs_mitigation.stp ~~~ Once the script is compiled and loaded, the following message will appear: ~~~ refluxfs mitigation loaded ~~~ With the mitigation active, any application attempting to use reflink to copy files will receive `-EOPNOTSUPP` (`-95`) when calling the `FICLONE` ioctl (or its variants) or the `copy_file_range()` syscall. Important considerations: 1. SystemTap scripts are compiled into kernel modules. On systems with Secure Boot enabled, the kernel is in lockdown mode and will only load modules signed with a valid Secure Boot key or a key enrolled in the MOK. SystemTap can sign the generated module at compile time, but the user is responsible for key management. For instructions, refer to the "Sign a SystemTap module" section of: https://www.redhat.com/en/blog/secure-boot-systemtap 2. The SystemTap module is not persistent across reboots. If the machine is restarted or the `stap` process is terminated, the module will be unloaded and the mitigation must be reapplied. 3. Programs that rely on CoW/reflink without a fallback mechanism may fail, as reflink operations will be unavailable on any XFS filesystem while the mitigation is loaded. This includes the `cp` command when run with `--reflink=always`. In that case, use `--reflink=auto` instead, which is the default behavior in Red Hat Enterprise Linux.

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kpatch-patch-5_14_0-570_66_1-debugsource-0:1-11.el9_6.ppc64le as a component of Red Hat Enterprise Linux BaseOS EUS (v.9.6) · fixed

  Vendor assessment for this product only.

  pkg:rpm/redhat/[email protected]_6?arch=ppc64le

  • vendor fix: Before applying this update, make sure all previously released errata relevant to your system have been applied. For details on how to apply this update, refer to: https://access.redhat.com/articles/11258 Vendor guidance
  • workaround: This vulnerability can be mitigated using a SystemTap script. To create and apply the mitigation, follow the steps below: 1. Install and configure SystemTap Install the SystemTap package and its dependencies following the instructions at: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/monitoring_and_managing_system_status_and_performance/getting-started-with-systemtap 2. Create the mitigation script Create a file named `refluxfs_mitigation.stp` with the following contents: ~~~ probe begin { printf("refluxfs mitigation loaded\n") } probe module("xfs").function("xfs_file_remap_range").call { $remap_flags = 0xffff } probe module("xfs").function("xfs_file_remap_range").return { $return = -95 } probe end { printf("refluxfs mitigation unloaded\n") } ~~~ 3. Load the mitigation As the `root` user, execute SystemTap in guru mode: ~~~ stap -g refluxfs_mitigation.stp ~~~ Once the script is compiled and loaded, the following message will appear: ~~~ refluxfs mitigation loaded ~~~ With the mitigation active, any application attempting to use reflink to copy files will receive `-EOPNOTSUPP` (`-95`) when calling the `FICLONE` ioctl (or its variants) or the `copy_file_range()` syscall. Important considerations: 1. SystemTap scripts are compiled into kernel modules. On systems with Secure Boot enabled, the kernel is in lockdown mode and will only load modules signed with a valid Secure Boot key or a key enrolled in the MOK. SystemTap can sign the generated module at compile time, but the user is responsible for key management. For instructions, refer to the "Sign a SystemTap module" section of: https://www.redhat.com/en/blog/secure-boot-systemtap 2. The SystemTap module is not persistent across reboots. If the machine is restarted or the `stap` process is terminated, the module will be unloaded and the mitigation must be reapplied. 3. Programs that rely on CoW/reflink without a fallback mechanism may fail, as reflink operations will be unavailable on any XFS filesystem while the mitigation is loaded. This includes the `cp` command when run with `--reflink=always`. In that case, use `--reflink=auto` instead, which is the default behavior in Red Hat Enterprise Linux.

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-rt-64k-debug-debuginfo-0:6.12.0-55.89.1.el10_0.aarch64 as a component of Red Hat Enterprise Linux CodeReady Linux Builder EUS (v. 10.0) · fixed

  Vendor assessment for this product only.

  pkg:rpm/redhat/[email protected]_0?arch=aarch64

  • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 The system must be rebooted for this update to take effect. Vendor guidance
  • workaround: This vulnerability can be mitigated using a SystemTap script. To create and apply the mitigation, follow the steps below: 1. Install and configure SystemTap Install the SystemTap package and its dependencies following the instructions at: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/monitoring_and_managing_system_status_and_performance/getting-started-with-systemtap 2. Create the mitigation script Create a file named `refluxfs_mitigation.stp` with the following contents: ~~~ probe begin { printf("refluxfs mitigation loaded\n") } probe module("xfs").function("xfs_file_remap_range").call { $remap_flags = 0xffff } probe module("xfs").function("xfs_file_remap_range").return { $return = -95 } probe end { printf("refluxfs mitigation unloaded\n") } ~~~ 3. Load the mitigation As the `root` user, execute SystemTap in guru mode: ~~~ stap -g refluxfs_mitigation.stp ~~~ Once the script is compiled and loaded, the following message will appear: ~~~ refluxfs mitigation loaded ~~~ With the mitigation active, any application attempting to use reflink to copy files will receive `-EOPNOTSUPP` (`-95`) when calling the `FICLONE` ioctl (or its variants) or the `copy_file_range()` syscall. Important considerations: 1. SystemTap scripts are compiled into kernel modules. On systems with Secure Boot enabled, the kernel is in lockdown mode and will only load modules signed with a valid Secure Boot key or a key enrolled in the MOK. SystemTap can sign the generated module at compile time, but the user is responsible for key management. For instructions, refer to the "Sign a SystemTap module" section of: https://www.redhat.com/en/blog/secure-boot-systemtap 2. The SystemTap module is not persistent across reboots. If the machine is restarted or the `stap` process is terminated, the module will be unloaded and the mitigation must be reapplied. 3. Programs that rely on CoW/reflink without a fallback mechanism may fail, as reflink operations will be unavailable on any XFS filesystem while the mitigation is loaded. This includes the `cp` command when run with `--reflink=always`. In that case, use `--reflink=auto` instead, which is the default behavior in Red Hat Enterprise Linux.

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-debug-debuginfo-0:5.14.0-687.26.1.el9_8.ppc64le as a component of Red Hat Enterprise Linux CodeReady Linux Builder (v. 9) · fixed

  Vendor assessment for this product only.

  pkg:rpm/redhat/[email protected]_8?arch=ppc64le

  • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 The system must be rebooted for this update to take effect. Vendor guidance
  • workaround: This vulnerability can be mitigated using a SystemTap script. To create and apply the mitigation, follow the steps below: 1. Install and configure SystemTap Install the SystemTap package and its dependencies following the instructions at: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/monitoring_and_managing_system_status_and_performance/getting-started-with-systemtap 2. Create the mitigation script Create a file named `refluxfs_mitigation.stp` with the following contents: ~~~ probe begin { printf("refluxfs mitigation loaded\n") } probe module("xfs").function("xfs_file_remap_range").call { $remap_flags = 0xffff } probe module("xfs").function("xfs_file_remap_range").return { $return = -95 } probe end { printf("refluxfs mitigation unloaded\n") } ~~~ 3. Load the mitigation As the `root` user, execute SystemTap in guru mode: ~~~ stap -g refluxfs_mitigation.stp ~~~ Once the script is compiled and loaded, the following message will appear: ~~~ refluxfs mitigation loaded ~~~ With the mitigation active, any application attempting to use reflink to copy files will receive `-EOPNOTSUPP` (`-95`) when calling the `FICLONE` ioctl (or its variants) or the `copy_file_range()` syscall. Important considerations: 1. SystemTap scripts are compiled into kernel modules. On systems with Secure Boot enabled, the kernel is in lockdown mode and will only load modules signed with a valid Secure Boot key or a key enrolled in the MOK. SystemTap can sign the generated module at compile time, but the user is responsible for key management. For instructions, refer to the "Sign a SystemTap module" section of: https://www.redhat.com/en/blog/secure-boot-systemtap 2. The SystemTap module is not persistent across reboots. If the machine is restarted or the `stap` process is terminated, the module will be unloaded and the mitigation must be reapplied. 3. Programs that rely on CoW/reflink without a fallback mechanism may fail, as reflink operations will be unavailable on any XFS filesystem while the mitigation is loaded. This includes the `cp` command when run with `--reflink=always`. In that case, use `--reflink=auto` instead, which is the default behavior in Red Hat Enterprise Linux.

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• libperf-debuginfo-0:5.14.0-570.128.1.el9_6.x86_64 as a component of Red Hat Enterprise Linux Real Time for NFV EUS (v.9.6) · fixed

  Vendor assessment for this product only.

  pkg:rpm/redhat/[email protected]_6?arch=x86_64

  • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 The system must be rebooted for this update to take effect. Vendor guidance
  • workaround: This vulnerability can be mitigated using a SystemTap script. To create and apply the mitigation, follow the steps below: 1. Install and configure SystemTap Install the SystemTap package and its dependencies following the instructions at: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/monitoring_and_managing_system_status_and_performance/getting-started-with-systemtap 2. Create the mitigation script Create a file named `refluxfs_mitigation.stp` with the following contents: ~~~ probe begin { printf("refluxfs mitigation loaded\n") } probe module("xfs").function("xfs_file_remap_range").call { $remap_flags = 0xffff } probe module("xfs").function("xfs_file_remap_range").return { $return = -95 } probe end { printf("refluxfs mitigation unloaded\n") } ~~~ 3. Load the mitigation As the `root` user, execute SystemTap in guru mode: ~~~ stap -g refluxfs_mitigation.stp ~~~ Once the script is compiled and loaded, the following message will appear: ~~~ refluxfs mitigation loaded ~~~ With the mitigation active, any application attempting to use reflink to copy files will receive `-EOPNOTSUPP` (`-95`) when calling the `FICLONE` ioctl (or its variants) or the `copy_file_range()` syscall. Important considerations: 1. SystemTap scripts are compiled into kernel modules. On systems with Secure Boot enabled, the kernel is in lockdown mode and will only load modules signed with a valid Secure Boot key or a key enrolled in the MOK. SystemTap can sign the generated module at compile time, but the user is responsible for key management. For instructions, refer to the "Sign a SystemTap module" section of: https://www.redhat.com/en/blog/secure-boot-systemtap 2. The SystemTap module is not persistent across reboots. If the machine is restarted or the `stap` process is terminated, the module will be unloaded and the mitigation must be reapplied. 3. Programs that rely on CoW/reflink without a fallback mechanism may fail, as reflink operations will be unavailable on any XFS filesystem while the mitigation is loaded. This includes the `cp` command when run with `--reflink=always`. In that case, use `--reflink=auto` instead, which is the default behavior in Red Hat Enterprise Linux.

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-rt-debug-devel-0:4.18.0-553.144.1.rt7.485.el8_10.x86_64 as a component of Red Hat Enterprise Linux RT (v. 8) · fixed

  Vendor assessment for this product only.

  pkg:rpm/redhat/[email protected]_10?arch=x86_64

  • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 The system must be rebooted for this update to take effect. Vendor guidance
  • workaround: This vulnerability can be mitigated using a SystemTap script. To create and apply the mitigation, follow the steps below: 1. Install and configure SystemTap Install the SystemTap package and its dependencies following the instructions at: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/monitoring_and_managing_system_status_and_performance/getting-started-with-systemtap 2. Create the mitigation script Create a file named `refluxfs_mitigation.stp` with the following contents: ~~~ probe begin { printf("refluxfs mitigation loaded\n") } probe module("xfs").function("xfs_file_remap_range").call { $remap_flags = 0xffff } probe module("xfs").function("xfs_file_remap_range").return { $return = -95 } probe end { printf("refluxfs mitigation unloaded\n") } ~~~ 3. Load the mitigation As the `root` user, execute SystemTap in guru mode: ~~~ stap -g refluxfs_mitigation.stp ~~~ Once the script is compiled and loaded, the following message will appear: ~~~ refluxfs mitigation loaded ~~~ With the mitigation active, any application attempting to use reflink to copy files will receive `-EOPNOTSUPP` (`-95`) when calling the `FICLONE` ioctl (or its variants) or the `copy_file_range()` syscall. Important considerations: 1. SystemTap scripts are compiled into kernel modules. On systems with Secure Boot enabled, the kernel is in lockdown mode and will only load modules signed with a valid Secure Boot key or a key enrolled in the MOK. SystemTap can sign the generated module at compile time, but the user is responsible for key management. For instructions, refer to the "Sign a SystemTap module" section of: https://www.redhat.com/en/blog/secure-boot-systemtap 2. The SystemTap module is not persistent across reboots. If the machine is restarted or the `stap` process is terminated, the module will be unloaded and the mitigation must be reapplied. 3. Programs that rely on CoW/reflink without a fallback mechanism may fail, as reflink operations will be unavailable on any XFS filesystem while the mitigation is loaded. This includes the `cp` command when run with `--reflink=always`. In that case, use `--reflink=auto` instead, which is the default behavior in Red Hat Enterprise Linux.

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• python3-perf-debuginfo-0:5.14.0-687.26.1.el9_8.x86_64 as a component of Red Hat Enterprise Linux Real Time (v. 9) · fixed

  Vendor assessment for this product only.

  pkg:rpm/redhat/[email protected]_8?arch=x86_64

  • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 The system must be rebooted for this update to take effect. Vendor guidance
  • workaround: This vulnerability can be mitigated using a SystemTap script. To create and apply the mitigation, follow the steps below: 1. Install and configure SystemTap Install the SystemTap package and its dependencies following the instructions at: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/monitoring_and_managing_system_status_and_performance/getting-started-with-systemtap 2. Create the mitigation script Create a file named `refluxfs_mitigation.stp` with the following contents: ~~~ probe begin { printf("refluxfs mitigation loaded\n") } probe module("xfs").function("xfs_file_remap_range").call { $remap_flags = 0xffff } probe module("xfs").function("xfs_file_remap_range").return { $return = -95 } probe end { printf("refluxfs mitigation unloaded\n") } ~~~ 3. Load the mitigation As the `root` user, execute SystemTap in guru mode: ~~~ stap -g refluxfs_mitigation.stp ~~~ Once the script is compiled and loaded, the following message will appear: ~~~ refluxfs mitigation loaded ~~~ With the mitigation active, any application attempting to use reflink to copy files will receive `-EOPNOTSUPP` (`-95`) when calling the `FICLONE` ioctl (or its variants) or the `copy_file_range()` syscall. Important considerations: 1. SystemTap scripts are compiled into kernel modules. On systems with Secure Boot enabled, the kernel is in lockdown mode and will only load modules signed with a valid Secure Boot key or a key enrolled in the MOK. SystemTap can sign the generated module at compile time, but the user is responsible for key management. For instructions, refer to the "Sign a SystemTap module" section of: https://www.redhat.com/en/blog/secure-boot-systemtap 2. The SystemTap module is not persistent across reboots. If the machine is restarted or the `stap` process is terminated, the module will be unloaded and the mitigation must be reapplied. 3. Programs that rely on CoW/reflink without a fallback mechanism may fail, as reflink operations will be unavailable on any XFS filesystem while the mitigation is loaded. This includes the `cp` command when run with `--reflink=always`. In that case, use `--reflink=auto` instead, which is the default behavior in Red Hat Enterprise Linux.

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel as a component of Red Hat Enterprise Linux 6 · known not affected

  Vendor assessment for this product only.

  Reason: vulnerable code not present

  pkg:rpm/redhat/kernel

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-debug as a component of Red Hat Enterprise Linux 6 · known not affected

  Vendor assessment for this product only.

  Reason: vulnerable code not present

  pkg:rpm/redhat/kernel-debug

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-devel as a component of Red Hat Enterprise Linux 6 · known not affected

  Vendor assessment for this product only.

  Reason: vulnerable code not present

  pkg:rpm/redhat/kernel-devel

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-headers as a component of Red Hat Enterprise Linux 6 · known not affected

  Vendor assessment for this product only.

  Reason: vulnerable code not present

  pkg:rpm/redhat/kernel-headers

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel.src as a component of Red Hat Enterprise Linux 6 · known not affected

  Vendor assessment for this product only.

  Reason: vulnerable code not present

  pkg:rpm/redhat/kernel?arch=src

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• bpftool as a component of Red Hat Enterprise Linux 7 · known not affected

  Vendor assessment for this product only.

  Reason: vulnerable code not present

  pkg:rpm/redhat/bpftool

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-abi-whitelists as a component of Red Hat Enterprise Linux 7 · known not affected

  Vendor assessment for this product only.

  Reason: vulnerable code not present

  pkg:rpm/redhat/kernel-abi-whitelists

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-debug-devel as a component of Red Hat Enterprise Linux 7 · known not affected

  Vendor assessment for this product only.

  Reason: vulnerable code not present

  pkg:rpm/redhat/kernel-debug-devel

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-headers as a component of Red Hat Enterprise Linux 7 · known not affected

  Vendor assessment for this product only.

  Reason: vulnerable code not present

  pkg:rpm/redhat/kernel-headers

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-rt as a component of Red Hat Enterprise Linux 7 · known not affected

  Vendor assessment for this product only.

  Reason: vulnerable code not present

  pkg:rpm/redhat/kernel-rt

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-rt-debug-devel as a component of Red Hat Enterprise Linux 7 · known not affected

  Vendor assessment for this product only.

  Reason: vulnerable code not present

  pkg:rpm/redhat/kernel-rt-debug-devel

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-rt-doc as a component of Red Hat Enterprise Linux 7 · known not affected

  Vendor assessment for this product only.

  Reason: vulnerable code not present

  pkg:rpm/redhat/kernel-rt-doc

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-rt-trace-devel as a component of Red Hat Enterprise Linux 7 · known not affected

  Vendor assessment for this product only.

  Reason: vulnerable code not present

  pkg:rpm/redhat/kernel-rt-trace-devel

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-tools as a component of Red Hat Enterprise Linux 7 · known not affected

  Vendor assessment for this product only.

  Reason: vulnerable code not present

  pkg:rpm/redhat/kernel-tools

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• kernel-tools-libs-devel as a component of Red Hat Enterprise Linux 7 · known not affected

  Vendor assessment for this product only.

  Reason: vulnerable code not present

  pkg:rpm/redhat/kernel-tools-libs-devel

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00
• python-perf as a component of Red Hat Enterprise Linux 7 · known not affected

  Vendor assessment for this product only.

  Reason: vulnerable code not present

  pkg:rpm/redhat/python-perf

  Red Hat · CVE-2026-64600 · Updated 2026-09-29T08:57:37+00:00

Unverified PoC candidates

Catalogue matches for further research. These repositories have not been validated as working exploits.