CVE-2024-46741

What it actually does

Double free of a fastrpc buffer object in drivers/misc/fastrpc.c:1926 when fastrpc_req_mmap() takes an error path that already performed an unmap via fastrpc_req_munmap_impl() followed by an unconditional fastrpc_buf_free() call, resulting in use-after-free memory corruption.

Why it matters to the business

Kernel memory corruption on systems using the fastrpc misc driver can cause crashes, denial of service, or local privilege escalation; organizations running affected Linux kernels face unplanned downtime and potential full system compromise until patched.

How an attack unfolds

An attacker with local access invokes the fastrpc_req_mmap ioctl in a way that forces the error path after a successful unmap, triggering the double-free; repeated attempts may allow control of freed memory for code execution or information leaks.

How to fix it

Update the Linux kernel to a version containing commit f77dc8a75859e559f3238a6d906206259227985e or later; rebuild and deploy the fixed kernel across all affected hosts; verify the fastrpc driver no longer contains the double-free sequence in fastrpc_req_mmap.

How to confirm the fix worked

Confirm kernel source contains the referenced commit or inspect drivers/misc/fastrpc.c around line 1926 to ensure the unconditional fastrpc_buf_free call after the unmap path has been removed; boot the updated kernel and exercise fastrpc mmap paths under error conditions.

Typical attack path

1. Obtain local user access on a system exposing /dev/fastrpc or equivalent fastrpc device nodes
2. Craft and send mmap request parameters that cause fastrpc_req_mmap to enter the error path after fastrpc_req_munmap_impl succeeds
3. Trigger the unconditional fastrpc_buf_free that re-frees the already-freed buffer
4. Leverage the resulting use-after-free for memory manipulation or privilege escalation

How to detect it

Review kernel logs for oops, BUG, or slab corruption messages mentioning fastrpc or fastrpc_buf_free; inspect auditd or syscall logs for unusual ioctl sequences against fastrpc device nodes; correlate with process crashes or restarts of userspace components using FastRPC.

What your security team should do

• Prioritize kernel upgrades on any systems exposing fastrpc interfaces within the next patching cycle
• Restrict local access and device node permissions for fastrpc until patches are applied
• Monitor for kernel oops or memory corruption reports referencing fastrpc after deployment
• Include the fixed commit in automated kernel build and validation pipelines