CVE-2026-63797 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
rpmsg: char: Fix use-after-free on probe error path
rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer.
Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/19/2026
This vulnerability exists within the Linux kernel's remote processor messaging subsystem, specifically affecting the character device implementation that handles communication between processors. The issue manifests as a use-after-free condition that occurs during the probe error handling path of the rpmsg character device driver. The flaw stems from improper resource management where the system allocates a new endpoint device structure and stores it in the default endpoint's private pointer before completing the full initialization process. This creates a dangerous race condition where subsequent error handling can attempt to free memory that may still be referenced by active callback mechanisms.
The technical root cause involves the rpmsg_chrdev_probe() function which orchestrates the creation and setup of character device endpoints for remote processor communication. When this function allocates a new endpoint device structure called eptdev, it immediately stores this reference in the default endpoint's private pointer field. Following this storage operation, the function invokes rpmsg_chrdev_eptdev_add() to complete the endpoint registration process. However, if this add operation fails for any reason such as resource exhaustion or configuration errors, the error path executes and frees the eptdev structure while the default endpoint may still be processing callbacks that reference the stale private pointer value.
The operational impact of this vulnerability is significant as it represents a potential security risk that could allow malicious actors to exploit memory corruption patterns within the kernel. When the error path executes and frees the endpoint device structure, any active callback handlers that are still processing messages or flow control updates may attempt to access freed memory locations through the stale private pointer reference. This creates opportunities for denial of service conditions, data corruption, or potentially more severe exploitation scenarios where attackers could leverage the use-after-free condition to execute arbitrary code within kernel space.
The vulnerability aligns with CWE-416 which specifically addresses use-after-free conditions in software systems, and it demonstrates the typical challenges associated with proper resource management during complex initialization sequences. From an attack surface perspective, this flaw falls under ATT&CK technique T1068 which involves privilege escalation through exploitation of kernel vulnerabilities, making it particularly concerning for embedded systems and devices that rely on remote processor communication for critical operations. The fix implements a defensive programming pattern by ensuring that endpoint device publication to the default endpoint occurs only after successful completion of all initialization steps, preventing premature exposure of potentially invalid references.
The solution addresses this vulnerability through careful control flow management that separates the allocation phase from the publication phase of endpoint devices. By deferring the assignment of the eptdev reference to the default endpoint's private pointer until after rpmsg_chrdev_eptdev_add() successfully completes, the system eliminates the window where stale pointers could cause issues during error handling. Additionally, the fix includes specific handling for callback functions that might be invoked during this transitional period, ensuring that both rpmsg_ept_cb() and rpmsg_ept_flow_cb() return success when encountering a NULL private pointer rather than attempting to dereference invalid memory locations. This approach follows established kernel security practices for managing complex initialization sequences and demonstrates proper error handling patterns that prevent resource leaks and memory corruption scenarios.
The mitigation strategy implemented in this fix represents a fundamental principle of secure kernel development where defensive programming techniques are employed to prevent race conditions during initialization phases. The solution eliminates the potential for arbitrary code execution by ensuring that callback handlers cannot access freed memory structures, while maintaining system stability through graceful error handling. This approach also aligns with modern kernel security practices that emphasize the importance of proper resource lifecycle management and the principle of least privilege in kernel subsystems. The fix specifically addresses a pattern commonly found in complex kernel drivers where multiple initialization steps must occur in sequence while maintaining consistency between internal data structures and external interfaces, making it representative of broader security challenges faced in operating system kernel development.