CVE-2023-52670

What it actually does

Failure to release the driver_override allocation in rpmsg_remove() causes a persistent kernel memory leak for each rpmsg device registration/removal cycle.

Why it matters to the business

Long-running systems that repeatedly register and unregister rpmsg devices can experience gradual memory exhaustion, leading to degraded performance or unplanned reboots.

How an attack unfolds

An attacker with local access repeatedly triggers rpmsg device probe and removal paths (for example via virtio or rpmsg_ns operations), causing the kernel to allocate but never free the driver_override buffer on each cycle.

How to fix it

Upgrade the Linux kernel to a version containing commit 229ce47cbfdc7d3a9415eb676abbfb77d676cb08 (or the corresponding stable backport) and reboot affected systems.

How to confirm the fix worked

Confirm the fix commit is present in the running kernel source tree or verify the kernel version matches a release that includes the patch; inspect dmesg for absence of the previously reported leak backtrace.

Typical attack path

1. Obtain local execution on a Linux system using rpmsg/virtio
2. Trigger repeated rpmsg_ns_register_device or equivalent device attach/detach operations
3. Cause the rpmsg_probe and rpmsg_remove paths to execute without the fix
4. Accumulate unreferenced allocations until memory pressure occurs

How to detect it

Review kernel logs and dmesg for the exact backtrace referencing driver_set_override and rpmsg_remove; track slab or kmalloc growth correlated with rpmsg device lifecycle events.

What your security team should do

• Prioritize kernel upgrades on all systems exposing rpmsg/virtio interfaces
• Apply the patch or update within normal change windows given the low EPSS and non-KEV status
• Monitor kernel memory usage and slab allocator statistics for rpmsg-related growth