CVE-2022-49272

In the Linux kernel, the following vulnerability has been resolved:

ALSA: pcm: Fix potential AB/BA lock with buffermutex and mmaplock

syzbot caught a potential deadlock between the PCM runtime->buffermutex and the mm->mmaplock. It was brought by the recent fix to cover the racy read/write and other ioctls, and in that commit, I overlooked a (hopefully only) corner case that may take the revert lock, namely, the OSS mmap. The OSS mmap operation exceptionally allows to re-configure the parameters inside the OSS mmap syscall, where mm->mmapmutex is already held. Meanwhile, the copyfrom/touser calls at read/write operations also take the mm->mmaplock internally, hence it may lead to a AB/BA deadlock.

A similar problem was already seen in the past and we fixed it with a refcount (in commit b248371628aa). The former fix covered only the call paths with OSS read/write and OSS ioctls, while we need to cover the concurrent access via both ALSA and OSS APIs now.

This patch addresses the problem above by replacing the buffermutex lock in the read/write operations with a refcount similar as we've used for OSS. The new field, runtime->bufferaccessing, keeps the number of concurrent read/write operations. Unlike the former buffermutex protection, this protects only around the copyfrom/to_user() calls; the other codes are basically protected by the PCM stream lock. The refcount can be a negative, meaning blocked by the ioctls. If a negative value is seen, the read/write aborts with -EBUSY. In the ioctl side, OTOH, they check this refcount, too, and set to a negative value for blocking unless it's already being accessed.