CVE-2026-63797

What it actually does

This is a Linux kernel use-after-free in the rpmsg character device driver. During rpmsg_chrdev_probe(), the driver stored a newly allocated endpoint device object in the default endpoint private pointer before the endpoint registration path had fully succeeded. If rpmsg_chrdev_eptdev_add() failed, the object could be freed while callbacks such as rpmsg_ept_cb() or rpmsg_ept_flow_cb() could still be invoked through the stale pointer. A successful exploit could cause kernel memory corruption, leading to local privilege escalation, kernel information disclosure, or a system crash. The vulnerable code is most relevant on systems that use rpmsg for inter-processor communication, common in embedded, mobile, automotive, industrial, and SoC-based Linux deployments.

Why it matters to the business

Systems using vulnerable Linux kernels with rpmsg character device support may be exposed to full host compromise or denial of service from an attacker who can trigger the affected rpmsg probe/error path and cause messages or flow-control callbacks during the vulnerable window. Business impact is highest for embedded and appliance-like products where kernel updates are slower, devices are physically distributed, and downtime may affect operations. Although EPSS is currently low and there is no known CISA KEV listing or public exploit maturity reported, the CVSS impact is high because successful exploitation occurs in kernel context and can compromise confidentiality, integrity, and availability.

How an attack unfolds

An attacker first needs a position that allows interaction with the affected rpmsg subsystem, such as local code execution on the Linux host, influence over rpmsg device creation, or control of a communicating remote processor/firmware component. The attacker then attempts to force rpmsg_chrdev_eptdev_add() to fail after rpmsg_chrdev_probe() has assigned the newly allocated eptdev object to the endpoint private pointer. This may involve racing device initialization, manipulating resource pressure, or causing error conditions during endpoint-device creation. Once the error path frees the object, the attacker causes the endpoint to receive a message or flow-control update so that rpmsg_ept_cb() or rpmsg_ept_flow_cb() dereferences the stale private pointer. Depending on heap state and timing, this can result in a kernel crash or controlled memory corruption that may be shaped into privilege escalation or information disclosure. There are no named threat actors or known ransomware campaigns associated with this vulnerability at this time.

How to fix it

Apply the Linux kernel update that includes the rpmsg char fix for this issue. The corrected behavior delays publishing the eptdev pointer through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds, and makes rpmsg_ept_cb() and rpmsg_ept_flow_cb() safely return when the private pointer is NULL. If an immediate kernel update is not possible, reduce exposure by disabling unused rpmsg character device support, removing or blacklisting the rpmsg_char module where operationally safe, restricting access to rpmsg device nodes, limiting untrusted local code execution, and ensuring remote processor firmware/images are trusted and integrity-protected. For vendor kernels, obtain the fix from the device, distribution, or BSP vendor because embedded Linux products often carry downstream rpmsg backports rather than mainline version numbers.

How to confirm the fix worked

Confirm the running kernel or vendor BSP contains the upstream fix in drivers/rpmsg/rpmsg_char.c. Validate that rpmsg_chrdev_probe() does not assign the default endpoint private pointer before rpmsg_chrdev_eptdev_add() succeeds, and that rpmsg_ept_cb() and rpmsg_ept_flow_cb() safely handle a NULL private pointer. On systems where source verification is not available, confirm the installed kernel package includes the vendor advisory fix, then reboot into the patched kernel and verify the active kernel version with uname or the distribution package manager. For exposure validation, inventory systems with rpmsg enabled, loaded rpmsg-related modules, device nodes such as /dev/rpmsg* or /dev/rpmsg_ctrl*, and kernels built with rpmsg character device support.

Typical attack path

1. Gain local execution on a system using a vulnerable Linux kernel with rpmsg character device support, or compromise/control a remote processor that communicates through rpmsg.
2. Identify or trigger rpmsg character device probing for an endpoint handled by the vulnerable driver.
3. Induce failure in the endpoint-device add path after the endpoint private pointer has been populated but before initialization is safely complete.
4. Race an rpmsg message or flow-control event into the default endpoint while the private pointer references freed memory.
5. Trigger dereference of the stale eptdev pointer in the rpmsg callback path.
6. Use the resulting kernel memory corruption for denial of service, information disclosure, or privilege escalation, depending on exploit reliability and memory layout.

How to detect it

There are no public, reliable, exploit-specific indicators for this vulnerability. Detection should focus on evidence of attempted kernel memory corruption around the rpmsg character driver and on systems where rpmsg is enabled. Review kernel logs, persistent journal logs, crash dumps, pstore/ramoops records, KASAN/KFENCE reports, oops traces, and endpoint/remote-processor logs for crashes or memory-safety warnings referencing rpmsg_char, rpmsg_chrdev_probe(), rpmsg_chrdev_eptdev_add(), rpmsg_ept_cb(), or rpmsg_ept_flow_cb(). Look for repeated rpmsg device probe failures followed closely by endpoint messages, flow-control events, kernel oopses, use-after-free diagnostics, general protection faults, slab corruption, or unexplained reboots. On embedded devices, correlate Linux-side kernel crashes with remote processor resets, firmware updates, debug access, or anomalous rpmsg traffic. Because successful exploitation may leave little more than a kernel crash or privilege escalation artifact, also review authentication logs, new privileged processes, unexpected module loads, changed init/service files, and device-node access around the time of any rpmsg-related crash.

• BUG: KASAN: use-after-free
• KASAN: use-after-free in rpmsg_ept_cb
• KASAN: use-after-free in rpmsg_ept_flow_cb
• rpmsg_chrdev_probe
• rpmsg_chrdev_eptdev_add
• rpmsg_ept_cb
• rpmsg_ept_flow_cb
• drivers/rpmsg/rpmsg_char.c
• general protection fault: 0000
• kernel BUG at drivers/rpmsg/rpmsg_char.c
• Unable to handle kernel NULL pointer dereference
• slab-use-after-free
• /dev/rpmsg_ctrl
• /dev/rpmsg

What your security team should do

• Prioritize patching Linux-based embedded, appliance, industrial, mobile, automotive, and SoC platforms that enable rpmsg character devices.
• Ask Linux distribution, hardware, BSP, and appliance vendors for the exact fixed kernel build or backported patch status if fixed versions are not explicitly documented.
• Inventory where rpmsg is enabled, especially systems exposing /dev/rpmsg* or loading rpmsg_char, and rank those systems above general-purpose Linux hosts that do not use rpmsg.
• Temporarily disable or blacklist unused rpmsg character device functionality where business operations allow.
• Restrict local shell, container escape paths, debug interfaces, and physical/service access on affected devices because exploitation requires local or tightly coupled subsystem access.
• Monitor kernel logs for crashes, KASAN reports, general protection faults, or NULL/stale pointer activity referencing rpmsg_char or rpmsg endpoint callbacks.
• Validate remote processor firmware trust chains and update mechanisms, since malicious or compromised remote firmware could help trigger rpmsg callback behavior.