CVE-2022-48775

What it actually does

Failure to call kobject_put() after kobject_init_and_add() returns an error in vmbus_add_channel_kobj leads to a memory leak of the associated kobject structure.

Why it matters to the business

Over time, repeated triggering of the error path can exhaust kernel memory on systems using Hyper-V virtualization, causing degraded performance, instability, or denial of service in cloud and virtualized workloads; widespread use of affected kernels increases exposure across many deployments.

How an attack unfolds

An attacker with the ability to induce repeated failures during vmbus channel object initialization (for example via crafted hypervisor messages or driver interactions) can cause incremental memory leaks; the low EPSS and lack of known threat actor exploitation indicate this is primarily a reliability rather than a targeted remote code execution issue.

How to fix it

Upgrade affected packages to the listed fixed versions: linux (Debian:12/13) to 5.15.15-1 or later; Ubuntu 20.04 LTS variants (linux, linux-aws, linux-azure, linux-gcp, etc.) to the corresponding 5.4.0 or 5.15.0 packages listed (for example linux-aws to 5.4.0-1005.5, linux-azure-5.15 to 5.15.0-1007.8~20.04.1). Reboot into the new kernel after installation.

How to confirm the fix worked

Verify the running kernel version matches or exceeds one of the fixed package versions; confirm the presence of the kobject_put() call in vmbus_add_channel_kobj via source inspection or by checking for the upstream commit that resolved the leak.

Typical attack path

1. Identify or reach a Hyper-V guest environment running an affected kernel version
2. Trigger error conditions in vmbus_add_channel_kobj repeatedly
3. Accumulate leaked kobject memory until system resources are exhausted

How to detect it

Review kernel logs for repeated vmbus channel initialization errors; correlate with gradual increases in slab or kobject memory usage via /proc/meminfo or slabtop; no public exploit artifacts or ransomware campaigns are associated with this issue.

What your security team should do

• Prioritize patching production Hyper-V hosts and guests within normal change windows given the memory-leak nature and broad package coverage
• Monitor memory usage trends on affected systems for unexpected growth correlated with vmbus channel activity
• Apply the exact fixed kernel packages listed for each distribution before the next scheduled maintenance cycle