CVE-2021-47456

What it actually does

Use-after-free in the peak_pci Linux kernel driver occurs when peak_pci_remove releases the device structure before a subsequent reference to the channel structure, allowing a dangling pointer access during module unload.

Why it matters to the business

Systems using the affected CAN PCI hardware face elevated risk of local kernel memory corruption, crashes, or privilege escalation that can disrupt operations or allow unauthorized access until the kernel is updated.

How an attack unfolds

An attacker with local access loads the peak_pci module on supported hardware, then triggers module removal (for example via rmmod) to exercise the faulty release order and obtain a use-after-free primitive that can be leveraged for kernel code execution.

How to fix it

Update the Linux kernel to a version containing the fix that moves the device release after the channel reference; apply the stable or distribution backport that resolves the ordering in peak_pci_remove.

How to confirm the fix worked

Confirm the running kernel contains the corrected peak_pci_remove function ordering; inspect kernel source or changelog for the commit that releases 'dev' after the final 'chan' access; re-test module load and unload cycles under KASAN or similar instrumentation.

Typical attack path

1. Obtain local unprivileged access to a Linux system with the peak_pci driver loaded
2. Trigger driver removal through module unload or device hot-unplug
3. Reference the freed channel structure inside peak_pci_remove to trigger the UAF
4. Use the resulting memory corruption to escalate privileges or crash the kernel

How to detect it

Search kernel logs and crash reports for KASAN use-after-free messages or stack traces containing peak_pci_remove; correlate with recent module unload events or modprobe activity on systems with peak_pci hardware.

• BUG: KASAN: use-after-free in peak_pci_remove
• peak_pci_remove+0x16f/0x270 [peak_pci]
• Read of size 8 at addr .* by task modprobe

What your security team should do

• Prioritize kernel updates on any host exposing the peak_pci CAN PCI driver
• Restrict local module unload privileges via LSM or policy where feasible
• Monitor for KASAN or kernel oops reports referencing peak_pci_remove