Description A vulnerability was found in the Linux kernel that allows an unprivileged local user to read sensitive files normally restricted to the root user. The flaw occurs during process exit, where a brief window allows an attacker to intercept file access from a privileged process before it fully terminates. Successful exploitation may lead to the disclosure of sensitive data such as SSH host private keys or /etc/shadow contents. This is an Important flaw in the Linux kernel that allows a local unprivileged attacker to read root-owned files. This could lead to unauthorized access to sensitive information on affected Red Hat mainstream Linux systems. Affected Products Common Linux distributions, such as Red Hat, Debian, and Ubuntu. Mitigation Qualys has confirmed a simple mitigation: tightening Yama’s ptrace_scope. Setting it to 2 (admin-only attach) or 3 (no attach) blocks every public exploit we are aware of: sudo sysctl -w kernel.yama.ptrace_scope=3 echo 'kernel.yama.ptrace_scope = 3' | sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf ptrace_scope=3 disables ptrace attach entirely, which can break debuggers (gdb attaching to a running process, strace -p, etc.). If you need ptrace for local debugging on the affected box, use 2 instead, which restricts attach to admins. Either value blocks the known PoCs because they rely on pidfd_getfd(2)’s access check, which routes through __ptrace_may_access(). This is a workaround, not a fix. Other paths to the same bug may exist. Install the patched kernel and reboot when you can. References https://access.redhat.com/security/cve/cve-2026-46333 https://security-tracker.debian.org/tracker/CVE-2026-46333 https://almalinux.org/blog/2026-05-15-ssh-keysign-pwn-cve-2026-46333/

Description "Dirty Frag" (also referred to as "Copy Fail 2") is a set of deterministic Linux kernel local privilege escalation vulnerabilities stemming from unsafe in-place cryptographic processing of shared skb fragments that reference file-backed page-cache pages in the xfrm-ESP (IPsec ESP) and RxRPC paths, belonging to the same broader bug class as Dirty Pipe and Copy Fail. A low-privileged local attacker can abuse zero-copy/splice mechanisms to manipulate the kernel page cache, overwrite privileged files such as /usr/bin/su or /etc/passwd, and gain root access. The collection comprises two distinct issues with assigned CVEs: the IPsec ESP flaw (involving the esp4 and esp6 modules, commonly used for VPNs and site-to-site tunnels) tracked as CVE-2026-43284, and the RxRPC flaw (which underpins the AFS distributed filesystem) tracked as CVE-2026-43500, both rated as "Important". Exploitation conditions differ—the ESP variant typically requires unprivileged user/network namespace creation, while the RxRPC variant depends on the rxrpc module being loaded or enabled (e.g., on Ubuntu), together providing broad exploitability across major Linux distributions. Until upstream patches are fully merged and deployed, mitigation involves disabling the vulnerable kernel modules (esp4, esp6, rxrpc) and applying appropriate kernel configuration to further reduce the attack surface. CVE-2026-46300: "Fragnesia" is a variant of Dirty Frag vulnerability in the ESP/XFRM leading to Local Privilege Escalation (LPE) vulnerability in the Linux. Affected Products CentOS/RHEL 8,9,10 Debian Mitigation Overall Guidance Any hardening measures that limit local access help reduce the risk of exploitation. Examples include disabling SSH, ensuring SELinux is in enforcing mode, using the default Security Context Constraints (SCC), running workloads as non-root, and restricting oc debug access to trusted cluster administrators. This list is not exhaustive, and the applicability of each measure should be evaluated in the context of your operational requirements and security policies. Additionally, disabling any single access method does not eliminate all other means by which a user could gain local access. Determining if IPsec is in use lsmod | grep -E 'esp4|esp6' If the modules are not loaded, IPsec is not in active use and the blocklist is safe to apply. If the modules are loaded and IPsec is actively configured, the blocklist will prevent IPsec from functioning after the next reboot. In that case, consider the "No Impact to IPsec Method" below. Note that even if the modules are loaded, rmmod will refuse to unload them if they are in active use. No running IPsec connections will be disrupted by the command itself. Blocklist Method Warning: Blocklisting esp4/esp6 will break IPsec functionality. Blocklisting rxrpc will break AFS client connectivity. Evaluate the impact on your environment before applying. printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf rmmod esp4 esp6 rxrpc 2>/dev/null; true No Impact to IPsec Method Alternatively, for environments where IPsec must remain functional, the ESP variant (CVE-2026-43284) can be blocked by disabling unprivileged user namespaces: Warning: This only blocks the ESP variant. On RHEL 9 and 10, the rxrpc variant (CVE-2026-43500) remains exploitable unless rxrpc is also blocklisted as shown above. Disabling unprivileged user namespaces may also affect rootless containers, sandboxed browsers, and Flatpak. echo "user.max_user_namespaces=0" > /etc/sysctl.d/dirtyfrag.conf sysctl --system Reverse Mitigation remove /etc/modprobe.d/dirtyfrag.conf References https://access.redhat.com/security/cve/cve-2026-43284 https://security-tracker.debian.org/tracker/CVE-2026-43284 https://security-tracker.debian.org/tracker/CVE-2026-46300

Description A flaw was found in the Linux kernel's algif_aead cryptographic algorithm interface. An incorrect 'in-place operation' was introduced, where the source and destination data mappings were different. This could lead to unexpected behavior or data integrity issues during cryptographic operations, potentially impacting the reliability of encrypted communications. This local privilege escalation is rated as Important severity. Part of the Linux kernel's cryptographic interface contains an incorrect in-place operation, where source and destination data mappings differ. This could lead to data integrity issues, including the escalation to root privileges. Affected Products RHEL/CentOS/Rocky Linux/AlmaLinux 8, 9, 10 (Fixed) openEuler 20.03 LTS and later versions (Fixed) Mitigation (for RHEL/CentOS) Warning: there may be performance impacts for modifying functionality that uses kernel cryptographic functions. Run below command to append the option to grub: # grubby --update-kernel=ALL --args='initcall_blacklist=algif_aead_init' Restart the system: # reboot Verification: once rebooted, verify the parameter: # cat /proc/cmdline | grep initcall_blacklist BOOT_IMAGE=(hd0,gpt2)/vmlinuz<...> initcall_blacklist=algif_aead_init Reverse Mitigation Once the fixed kernel is available and installed to reverse the mitigation see steps below: Run below command to remove the option to grub: # grubby --update-kernel=ALL --remove-args='initcall_blacklist=algif_aead_init' Restart the system: # reboot Verification: once rebooted, verify the parameter has been removed: # cat /proc/cmdline | grep initcall_blacklist <... no output ...> References https://access.redhat.com/security/cve/cve-2026-31431