CVE-2022-49024

What it actually does

Missing m_can_class_free_dev() calls in m_can_pci_probe error paths and m_can_pci_remove allow resources allocated by m_can_class_allocate_dev to leak, resulting in unreleased kernel memory.

Why it matters to the business

Repeated device probe/remove cycles on affected Linux systems can gradually exhaust kernel memory, leading to instability or denial of service; low immediate risk given low EPSS and absence from KEV despite mentions in broader 2024 exploitation campaigns.

How an attack unfolds

An attacker with local access or ability to trigger PCI device events repeatedly invokes the probe and remove paths to accumulate leaked allocations until memory pressure causes system impact, potentially as part of espionage or financially motivated operations noted in 2024 campaigns.

How to fix it

Apply the fix from commit ea8dc27bb044e19868155e500ce397007be98656 in the Linux kernel stable tree; for coffee2code/remember-me-controls update to a684b05d5072eee5cd13b4b8ffba8e46becca258.

How to confirm the fix worked

Inspect m_can_pci.c to confirm m_can_class_free_dev is invoked in both the error path of m_can_pci_probe and in m_can_pci_remove; test module load/unload cycles for absence of leaks via kmemleak or similar tools.

Typical attack path

1. Obtain ability to trigger m_can_pci device attachment or detachment events
2. Repeatedly exercise probe and remove code paths to induce allocations without corresponding frees
3. Monitor for progressive kernel memory depletion leading to instability

How to detect it

Review kernel logs and dmesg for repeated m_can allocation messages without matching frees; use memory leak detectors or track slab usage for m_can related structures during device events.

What your security team should do

• Prioritize kernel updates on systems exposing CAN bus PCI devices
• Audit custom or downstream kernel builds for the missing free calls
• Monitor memory usage trends on affected hosts even though EPSS remains low