CVE-2026-22856: 
NixOS vulnerability analysis and mitigation

CVE-2026-22856 is a heap use-after-free vulnerability in FreeRDP's serial channel IRP thread tracking mechanism, classified as a race condition (CWE-362 / CWE-416). It affects all FreeRDP versions prior to 3.20.1 and was disclosed on January 14, 2026, by researcher ehdgks0627 via a GitHub Security Advisory. The vulnerability carries a CVSS v3.1 base score of 8.1 (High) and a CVSS v4.0 base score of 6.8 (Medium) (GitHub Advisory, Red Hat Bugzilla). Only FreeRDP-based clients are affected; FreeRDP-based servers are not impacted (FreeRDP Release).

The root cause is improper synchronization (CWE-362) of concurrent access to the serial->IrpThreads list dictionary, which is created without internal locking (ListDictionary_New(FALSE)). When close_terminated_irp_thread_handles removes and frees a list node under TerminatingIrpThreadsLock, the create_irp_thread function can simultaneously call ListDictionary_GetItemValue without holding that lock, resulting in a heap use-after-free (CWE-416) on the freed node (GitHub Advisory). The vulnerable code path is in channels/serial/client/serial_main.c, specifically in the create_irp_thread and close_unterminated_irp_thread functions. A malicious RDP server can trigger this condition by manipulating serial port IRP (I/O Request Packet) operations to induce the race. The fix changes the list dictionary to synchronized mode (ListDictionary_New(TRUE)) so all operations acquire the internal lock (GitHub Advisory).

Successful exploitation can cause a client-side crash (denial of service) and, depending on heap layout and allocator behavior, may enable arbitrary code execution on the connecting client system. A malicious or compromised RDP server can trigger this condition against any FreeRDP-based client that has serial port redirection enabled, potentially achieving full compromise of confidentiality, integrity, and availability of the client system (GitHub Advisory). The attack is network-based and does not require authentication or elevated privileges on the attacker's side, though the high attack complexity (timing-dependent race condition) limits reliable exploitation (Red Hat Bugzilla).

A proof-of-concept (PoC) exploit demonstrating the vulnerability via AddressSanitizer output is publicly available in the GitHub Security Advisory (GitHub Advisory). There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.038% (very low probability of exploitation in the near term). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The CVSS v4.0 exploit maturity is rated as "Proof of Concept" (Feedly).

1. Setup a malicious RDP server: Configure a rogue RDP server (e.g., using a modified FreeRDP server or custom RDP implementation) that supports the rdpdr virtual channel with serial port device redirection.
2. Lure a victim client: Trick a FreeRDP-based client (version ≤ 3.20.0) into connecting to the malicious server, ensuring the client has serial port redirection enabled (e.g., via /drive or serial device options).
3. Trigger concurrent IRP operations: Once the client connects and the serial channel is established, send rapid sequences of IRP close and create requests over the rdpdr channel to induce concurrent execution of close_terminated_irp_thread_handles and create_irp_thread on the client side.
4. Race condition exploitation: The race causes create_irp_thread to call ListDictionary_GetItemValue on a node that close_unterminated_irp_thread has already freed, resulting in a heap use-after-free read at the freed memory address.
5. Achieve crash or code execution: Depending on heap layout, the freed memory may be reallocated with attacker-controlled data, potentially redirecting execution flow. At minimum, the client process crashes (DoS); with favorable heap conditions, arbitrary code execution on the client may be achievable (GitHub Advisory).

• Process: FreeRDP client process (xfreerdp, wlfreerdp, etc.) crashing unexpectedly during or after RDP sessions involving serial port redirection; crash dumps referencing ListDictionary_GetItemValue, create_irp_thread, or serial_main.c.
• Logs: AddressSanitizer or memory error output in application logs showing heap-use-after-free at addresses within ListDictionary.c:510 or serial_main.c:641; segmentation fault signals from the FreeRDP client process.
• Network: Connections from FreeRDP clients to unexpected or untrusted RDP servers, particularly those sending unusual volumes of serial IRP close/create sequences over the rdpdr virtual channel.
• File System: Core dump files generated by the FreeRDP client process in the working directory or system crash directory (e.g., /var/crash/, /tmp/core.*) following RDP sessions.

The primary remediation is to upgrade FreeRDP to version 3.20.1 or later, which fixes the vulnerability by initializing serial->IrpThreads as a synchronized list dictionary (FreeRDP Release). As a workaround, disable serial port redirection in RDP client configurations if it is not operationally required. Additionally, restrict network access to FreeRDP services so clients only connect to trusted, known-good RDP servers. Red Hat has issued multiple errata addressing this CVE across RHEL 7 through 10, including RHSA-2026:6340 (RHEL 9), RHSA-2026:6918 (RHEL 8), RHSA-2026:6799 (RHEL 10), and others (Red Hat Bugzilla). Downstream distributions including openSUSE, Ubuntu, Fedora, AlmaLinux, Rocky Linux, Amazon Linux 2, Mageia, and Debian have also released updated packages.

The vulnerability was discovered and reported by researcher ehdgks0627, who performed code review and testing that uncovered this and eight other medium-severity CVEs addressed in the FreeRDP 3.20.1 release (FreeRDP Release). The FreeRDP maintainer (akallabeth) acknowledged the findings and credited the reporter in the release notes. The vulnerability received routine coverage from Linux security news aggregators and was picked up by Tenable (Nessus), Qualys, and other scanner vendors shortly after disclosure. No significant social media controversy or broader industry debate has been observed around this specific CVE.