{"document":{"acknowledgments":[{"urls":["https://kb.cert.org/vuls/id/980487#acknowledgements"]}],"category":"CERT/CC Vulnerability Note","csaf_version":"2.0","notes":[{"category":"summary","text":"### Overview\r\nA privilege escalation vulnerability, nicknamed \"Dirty Frag,\" has been discovered in the Linux kernel versions 4.10 and later. This vulnerability is a result of chaining together two previously discovered vulnerabilities, xfrm-ESP Page-Cache Write [CVE-2026-43284](https://www.cve.org/CVERecord?id=CVE-2026-43284) and the RxRPC Page-Cache Write [CVE-2026-43500](https://www.cve.org/CVERecord?id=CVE-2026-43500). This vulnerability was publicly disclosed on May 07, 2026.\r\n\r\n### Description\r\nDirty Frag is a Linux kernel vulnerability affecting the IPv4/IPv6 fragmentation and reassembly subsystem. The issue stems from improper handling of overlapping or malformed fragment offsets during the reassembly process. An attacker capable of sending crafted network packets to a vulnerable host can exploit the flaw to trigger memory corruption conditions.\r\n\r\nThe publicly documented proof of concept demonstrates that fragmentation logic can be manipulated such that the kernel processes inconsistent fragment states, enabling a controlled write out-of-bounds scenario. When successfully exploited, this can result in local or remote denial of service (kernel panic) and, depending on configuration and kernel build options, may create a primitive for more advanced memory manipulation.\r\n\r\nThe vulnerability arises from insufficient validation of fragment metadata during reassembly, specifically around:\r\n\r\n* Incorrect or incomplete enforcement of fragment boundary checks\r\n* Acceptance of overlapping fragments in unsafe sequences\r\n* Inadequate cleanup when transitions occur between valid and invalid fragment states\r\n\r\nThe fragment queue logic in affected kernels does not fully verify that fragment offsets, sizes, and overlap conditions remain consistent throughout reassembly. This allows malformed sequences to be processed without proper rejection.\r\n\r\n### Impact\r\nThe primary security concern is potential privilege escalation, similar in nature to the previously disclosed [VU#260001 (\"Copy Fail\")](https://kb.cert.org/vuls/id/260001) vulnerability.\r\n\r\nDepending on system configuration, kernel hardening features, and network exposure, successful exploitation may result in:\r\n\r\n- Local or remote denial of service through kernel panic\r\n- Memory corruption within the Linux networking stack\r\n- Privilege escalation\r\n- Container escape in certain containerized environments\r\n- Additional exploit primitives when chained with other vulnerabilities\r\n\r\n### Solution\r\n\r\n#### Update Linux distribution\r\nUpdate your distribution’s kernel package as soon as vendor patches become available. Most major Linux distributions are expected to release fixes through their standard update channels.\r\n\r\n#### Workarounds (if patching is not immediately possible):\r\n1) Disable at-risk modules (if loaded and loadable):\r\nUse the following command to remove the modules in which the vulnerabilities occur and clear the page cache.\r\n`sh -c \"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; echo 3 > /proc/sys/vm/drop_caches; true\"` \r\n\r\nNote: you can verify if a module is currently being used using `lsmod` and the `Used` field or reviewing `refcnt` data in `/sys/module/<module_name>/refcnt` for e.g., `cat /sys/module/esp4/refcnt`\r\n\r\n2) If affected modules `esp4`, `esp6`, `rxrpc ` are compiled into the kernel (not a dynamic module), the following parameter can be added to grub, systemd-boot, or grubby, depending on your boot configuration:\r\n`initcall_blacklist=esp4,esp6,rxrpc`\r\nThis prevents the module from initializing at boot time. A system reboot is required for this change to take effect.\r\n\r\n#### Mitigation for Containers\r\n\r\nFor containerized environments, where this vulnerability may be leveraged for container escape, consider applying one or more of the following mitigations:\r\n\r\n* Secure computing (seccomp) filtering: Restrict or deny system calls that create sockets using the AF_ALG address family (protocol 38) and AF_RXRPC (protocol 33) .\r\n* AppArmor policies: Use AppArmor to block creation of AF_ALG sockets and AF_RXRPC via the network alg rule.\r\n* eBPF-based enforcement: Deploy BPF-based controls to deny socket creation with address family AF_ALG (38) and AF_RXRPC (33).\r\n \r\n### Acknowledgements\r\nThis vulnerability was disclosed by Hyunwoo Kim. This document was written by Bob Kemerer.","title":"Summary"},{"category":"legal_disclaimer","text":"THIS DOCUMENT IS PROVIDED ON AN 'AS IS' BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. ","title":"Legal Disclaimer"},{"category":"other","text":"CERT/CC Vulnerability Note is a limited advisory. It primarily identifies vendors impacted by the advisory and not specific products. We only support \"known_affected\" and \"known_not_affected\" status. Please consult the vendor's statements and advisory URL if provided by the vendor for more details ","title":"Limitations of Advisory"}],"publisher":{"category":"coordinator","contact_details":"Email: cert@cert.org, Phone: +1412 268 5800","issuing_authority":"CERT/CC under DHS/CISA https://www.cisa.gov/cybersecurity also see https://kb.cert.org/ ","name":"CERT/CC","namespace":"https://kb.cert.org/"},"references":[{"url":"https://certcc.github.io/certcc_disclosure_policy","summary":"CERT/CC vulnerability disclosure policy"},{"summary":"CERT/CC document released","category":"self","url":"https://kb.cert.org/vuls/id/980487"},{"url":"https://github.com/V4bel/dirtyfrag","summary":"https://github.com/V4bel/dirtyfrag"},{"url":"https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md","summary":"https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md"},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43284","summary":"https://nvd.nist.gov/vuln/detail/CVE-2026-43284"},{"url":"https://www.tenable.com/blog/dirty-frag-cve-2026-43284-cve-2026-43500-frequently-asked-questions-linux-kernel-lpe","summary":"https://www.tenable.com/blog/dirty-frag-cve-2026-43284-cve-2026-43500-frequently-asked-questions-linux-kernel-lpe"}],"title":"Local privilege escalation in Linux Kernel (Dirty Frag)","tracking":{"current_release_date":"2026-05-20T21:23:45+00:00","generator":{"engine":{"name":"VINCE","version":"3.0.41"}},"id":"VU#980487","initial_release_date":"2026-05-20 21:23:45.752600+00:00","revision_history":[{"date":"2026-05-20T21:23:45+00:00","number":"1.20260520212345.1","summary":"Released on 2026-05-20T21:23:45+00:00"}],"status":"final","version":"1.20260520212345.1"}},"vulnerabilities":[{"title":"In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true.","notes":[{"category":"summary","text":"In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused."}],"cve":"CVE-2026-43500","ids":[{"system_name":"CERT/CC V Identifier ","text":"VU#980487"}],"references":[{"url":"https://github.com/NixOS/nixpkgs/pull/518947","summary":"https://github.com/NixOS/nixpkgs/pull/518947","category":"external"}],"product_status":{"known_affected":["CSAFPID-93b4787a-54a0-11f1-b900-1264d018803b"]}},{"title":"In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb.","notes":[{"category":"summary","text":"In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data()."}],"cve":"CVE-2026-43284","ids":[{"system_name":"CERT/CC V Identifier ","text":"VU#980487"}],"references":[{"url":"https://github.com/NixOS/nixpkgs/pull/517962","summary":"https://github.com/NixOS/nixpkgs/pull/517962","category":"external"}],"product_status":{"known_affected":["CSAFPID-93b536c0-54a0-11f1-b900-1264d018803b"]}}],"product_tree":{"branches":[{"category":"vendor","name":"Linux Kernel","product":{"name":"Linux Kernel Products","product_id":"CSAFPID-93b442f6-54a0-11f1-b900-1264d018803b"}},{"category":"vendor","name":"NixOS","product":{"name":"NixOS Products","product_id":"CSAFPID-93b4787a-54a0-11f1-b900-1264d018803b"}},{"category":"vendor","name":"Linux Kernel","product":{"name":"Linux Kernel Products","product_id":"CSAFPID-93b4ff98-54a0-11f1-b900-1264d018803b"}},{"category":"vendor","name":"NixOS","product":{"name":"NixOS Products","product_id":"CSAFPID-93b536c0-54a0-11f1-b900-1264d018803b"}}]}}