CVE-2022-49272

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock<br /> <br /> syzbot caught a potential deadlock between the PCM<br /> runtime-&gt;buffer_mutex and the mm-&gt;mmap_lock. It was brought by the<br /> recent fix to cover the racy read/write and other ioctls, and in that<br /> commit, I overlooked a (hopefully only) corner case that may take the<br /> revert lock, namely, the OSS mmap. The OSS mmap operation<br /> exceptionally allows to re-configure the parameters inside the OSS<br /> mmap syscall, where mm-&gt;mmap_mutex is already held. Meanwhile, the<br /> copy_from/to_user calls at read/write operations also take the<br /> mm-&gt;mmap_lock internally, hence it may lead to a AB/BA deadlock.<br /> <br /> A similar problem was already seen in the past and we fixed it with a<br /> refcount (in commit b248371628aa). The former fix covered only the<br /> call paths with OSS read/write and OSS ioctls, while we need to cover<br /> the concurrent access via both ALSA and OSS APIs now.<br /> <br /> This patch addresses the problem above by replacing the buffer_mutex<br /> lock in the read/write operations with a refcount similar as we&amp;#39;ve<br /> used for OSS. The new field, runtime-&gt;buffer_accessing, keeps the<br /> number of concurrent read/write operations. Unlike the former<br /> buffer_mutex protection, this protects only around the<br /> copy_from/to_user() calls; the other codes are basically protected by<br /> the PCM stream lock. The refcount can be a negative, meaning blocked<br /> by the ioctls. If a negative value is seen, the read/write aborts<br /> with -EBUSY. In the ioctl side, OTOH, they check this refcount, too,<br /> and set to a negative value for blocking unless it&amp;#39;s already being<br /> accessed.