CVE-2023-52652

What it actually does

Failure of device_register() in ntb_register_device() leaves a device name allocated via dev_set_name() unfreed because the error path omits put_device(), allowing the reference to be released only later in kobject_cleanup().

Why it matters to the business

Low-severity risk of gradual kernel memory consumption on systems that load the NTB driver and encounter rare device registration failures; no widespread operational impact expected given low EPSS and absence from KEV.

How an attack unfolds

An attacker would need to induce repeated failures in the ntb_register_device() error path to trigger incremental name leaks; no known threat actors or ransomware campaigns exploit this issue, and the 898-day-old patch has seen no meaningful EPSS growth.

How to fix it

Update the affected Linux kernel or backport package to include the fix that adds put_device() on the device_register() error path; for devent/globalpom-utils (GIT) apply commit 77a820bac2f68e662ce261ecb050c643bd7ee560.

How to confirm the fix worked

Inspect the ntb_register_device() error path in source to confirm put_device() is present before returning the error code, or verify the running kernel contains the referenced commit.

Typical attack path

1. Load or trigger the NTB driver initialization path
2. Force device_register() to fail inside ntb_register_device()
3. Repeat to accumulate unfreed device names and exhaust memory

How to detect it

Examine kernel logs for repeated NTB device registration failures around the time of any unexplained memory pressure; no public indicators of active exploitation exist.

What your security team should do

• Apply the upstream fix or the listed commit in all kernels that include the NTB driver
• Review NTB driver usage in embedded or specialized deployments where device registration errors are more likely
• Monitor kernel memory statistics on systems that expose NTB interfaces