CVE-2022-48968

What it actually does

Failure to free tc->tc_entries_bitmap allocated in otx2_tc_alloc_ent_bitmap when rhashtable_init fails inside otx2_init_tc, causing a memory leak in the octeontx2-pf driver.

Why it matters to the business

Repeated trigger conditions can exhaust kernel memory over time, leading to degraded network performance, instability, or system crashes on affected Linux deployments; low exploitability reduces immediate urgency despite the long publication window.

How an attack unfolds

An attacker with local or network-adjacent access manipulates traffic control configuration to force rhashtable_init failures during TC initialization in the octeontx2-pf path, accumulating unfreed bitmap allocations; generic Linux kernel exploitation campaigns may attempt similar resource-handling flaws but no specific actor or ransomware usage is tied to this issue.

How to fix it

Upgrade sulu/sulu (GIT) to commit a5a5ae555d282e88ff8559d38cfb46dea7939bda or apply the equivalent upstream Linux kernel patch that ensures tc_entries_bitmap is freed on rhashtable_init failure.

How to confirm the fix worked

Confirm the patch is present by reviewing the otx2_init_tc function for an explicit kfree on the bitmap after rhashtable_init error; test by simulating rhashtable failure and checking for no net memory growth.

Typical attack path

1. Gain ability to invoke otx2_init_tc via network device configuration
2. Force rhashtable_init failure condition
3. Trigger repeated allocation without corresponding free
4. Observe gradual kernel memory depletion

How to detect it

Review kernel logs for repeated otx2_init_tc and rhashtable_init error messages combined with increasing slab allocations; inspect memory usage trends on systems with octeontx2-pf devices.

What your security team should do

• Apply the referenced commit or kernel update to all systems using octeontx2-pf
• Monitor memory usage on network devices exposing TC configuration
• Prioritize patching if custom traffic control policies are in use