Bug 2464470 (CVE-2026-31730)

Summary: CVE-2026-31730 kernel: misc: fastrpc: possible double-free of cctx->remote_heap
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's fastrpc component that could lead to a denial of service (DoS) or potentially arbitrary code execution. This memory corruption vulnerability, specifically a double-free, occurs when the cctx->remote_heap memory is freed twice due to an error handling issue in the fastrpc_init_create_static_process() function. If the INIT_CREATE_STATIC ioctl hits an error path and the rpmsg device is subsequently removed, fastrpc_rpmsg_remove() attempts to free the same memory again.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-05-01 15:08:37 UTC
In the Linux kernel, the following vulnerability has been resolved:

misc: fastrpc: possible double-free of cctx->remote_heap

fastrpc_init_create_static_process() may free cctx->remote_heap on the
err_map path but does not clear the pointer. Later, fastrpc_rpmsg_remove()
frees cctx->remote_heap again if it is non-NULL, which can lead to a
double-free if the INIT_CREATE_STATIC ioctl hits the error path and the rpmsg
device is subsequently removed/unbound.
Clear cctx->remote_heap after freeing it in the error path to prevent the
later cleanup from freeing it again.

This issue was found by an in-house analysis workflow that extracts AST-based
information and runs static checks, with LLM assistance for triage, and was
confirmed by manual code review.
No hardware testing was performed.