CVE-2023-52699

What it actually does

The SysV filesystem implementation calls sb_bread() while holding the pointers_lock rw_spinlock, violating atomic context rules and enabling sleep-in-atomic or deadlock conditions during block reads.

Why it matters to the business

Systems mounting SysV filesystems risk kernel panics or hangs, leading to service disruption, data unavailability, and forced reboots on affected Linux kernels.

How an attack unfolds

An attacker with local access crafts filesystem operations that trigger concurrent reads under the rwlock, forcing sb_bread() to sleep while the lock is held and causing the kernel to panic or deadlock.

How to fix it

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

How to confirm the fix worked

Verify the running kernel contains commit 13b33feb2ebddc2b1aa607f553566b18a4af1d76 via git log or kernel version string; attempt to reproduce the original syzbot reproducer under the lock.

Typical attack path

1. Mount a SysV filesystem image
2. Perform concurrent directory or inode operations that acquire pointers_lock
3. Force sb_bread() under the held read lock
4. Trigger scheduling while in atomic context

How to detect it

Inspect kernel logs for atomic sleep warnings or SysV-related oops traces; search for processes performing heavy SysV filesystem activity preceding crashes.

What your security team should do

• Prioritize kernel upgrade on all systems using SysV filesystems
• Audit custom kernels and embedded devices for the vulnerable code path
• Monitor for kernel oops or panic logs referencing sysv or pointers_lock