CVE-2023-52699: sysv: don't call sb_bread() with pointers_lock held
In the Linux kernel, the following vulnerability has been resolved:
sysv: don't call sbbread() with pointerslock held
syzbot is reporting sleep in atomic context in SysV filesystem [1], for sbbread() is called with rwspinlock held.
A "writelock(&pointerslock) => readlock(&pointerslock) deadlock" bug and a "sbbread() with writelock(&pointerslock)" bug were introduced by "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.
Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the former bug by moving pointerslock lock to the callers, but instead introduced a "sbbread() with readlock(&pointerslock)" bug (which made this problem easier to hit).
Al Viro suggested that why not to do like getbranch()/getblock()/ findshared() in Minix filesystem does. And doing like that is almost a revert of "[PATCH] err1-40: sysvfs locking fix" except that getbranch() from with findshared() is called without writelock(&pointerslock).
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2023-52699?
CVE-2023-52699 is classified as a vulnerability in the Linux kernel affecting the SysV filesystem.
How do I fix CVE-2023-52699?
To fix CVE-2023-52699, you should update your Linux kernel to the patched versions 5.10.223-1, 5.10.226-1, 6.1.119-1, 6.1.123-1, 6.12.10-1, or 6.12.11-1.
What specific problem does CVE-2023-52699 address?
CVE-2023-52699 addresses an issue where sb_bread() can be called while holding pointers_lock, potentially causing sleep in atomic context.
Which software versions are affected by CVE-2023-52699?
Affected software versions for CVE-2023-52699 include certain prior releases of the Linux kernel before the aforementioned patched versions.
Is CVE-2023-52699 a critical vulnerability?
While not designated as critical, CVE-2023-52699 poses potential risks to system stability and performance due to its nature.