CVE-2022-50857

What it actually does

Improper error handling in rio_register_mport() after a failing device_register() leaves a dev_set_name() allocated name unreleased because put_device() is not called on the error path, so kobject_cleanup() never frees it and list_del() is skipped.

Why it matters to the business

Long-running systems can experience gradual kernel memory exhaustion from repeated registration failures, increasing operational risk and potential downtime in environments using the rapidio subsystem.

How an attack unfolds

An attacker with local access triggers repeated device registration attempts that fail, causing the kernel to leak kobject names and references; over time this can contribute to memory pressure or be combined with other bugs to facilitate denial of service or memory corruption.

How to fix it

Update to a kernel containing commit 0a71344f99289250e4d5b8adbac76f444485c840 or apply the equivalent fix that adds put_device() and list_del() on the device_register() error path; for affected rdesktop packages on Debian 11-14 upgrade to version 1.8.4-1 or later.

How to confirm the fix worked

Confirm the running kernel contains the fix commit or the patched rio_register_mport() implementation; recompile and boot-test with error-injection on device_register() to verify no name leak occurs.

Typical attack path

1. Obtain local execution on a system with the vulnerable rapidio driver loaded
2. Induce repeated rio_mport registration failures (e.g., via crafted device or error injection)
3. Accumulate unreleased kobject names and references
4. Combine with other memory pressure or corruption primitives to achieve escalation or denial of service

How to detect it

Review kernel logs for rapidio mport registration failures around the time of suspected exploitation; look for unusual growth in kobject or device name allocations without corresponding frees in memory profiling tools.

What your security team should do

• Prioritize patching kernel packages on all systems exposing the rapidio subsystem
• Monitor EPSS and KEV status for any future increase in exploit maturity
• Audit custom drivers or out-of-tree rapidio code for similar reference-counting patterns