CVE-2024-38780

What it actually does

Incorrect replacement of spin_unlock_irqrestore with spin_unlock_irq in sync_print_obj() (called under irqsave context from sync_debugfs_show) produces inconsistent lock state and potential IRQ mishandling in the dma-buf sw-sync debugfs path.

Why it matters to the business

Kernel debug operations on dma-buf objects can trigger lockdep warnings or, in edge cases, deadlock or soft-lockup conditions, reducing stability of systems that expose these debugfs interfaces.

How an attack unfolds

A local attacker with access to the affected debugfs files reads sync object state, exercising the mismatched spinlock calls; under concurrent access this can surface as warnings or, theoretically, interrupt-state corruption.

How to fix it

Upgrade the Linux kernel to a version containing commit bebc6082da0a9f5d47a1ea2edc099bf671058bd4 or later; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm the commit bebc6082da0a9f5d47a1ea2edc099bf671058bd4 (or equivalent) is present in the running kernel source; re-run the original debugfs workload and verify absence of lockdep warnings.

Typical attack path

1. Obtain local shell or process with access to /sys/kernel/debug/dma_buf/sync*
2. Trigger repeated reads of sync_debugfs_show while other dma-buf operations occur
3. Observe lockdep splat or induce IRQ state inconsistency

How to detect it

Search kernel logs (dmesg, journalctl) for lockdep warnings mentioning inconsistent IRQ state or sw-sync; inspect /proc/lockdep or ftrace output for sync_print_obj callers.

What your security team should do

• Apply the referenced upstream commit or vendor kernel update as soon as practical
• Limit unprivileged access to dma-buf debugfs entries via mount options or SELinux policy until patched
• Monitor kernel logs for lockdep warnings referencing sync_print_obj or sw-sync