In the Linux kernel, the following vulnerability has been resolved: iio: light: opt3001: fix deadlock due to concurrent flag access The threaded IRQ function in this driver is reading the flag twice: once to lock a mutex and once to unlock it. Even though the code setting the flag is designed to prevent it, there are subtle cases where the flag could be true at the mutex_lock stage and false at the mutex_unlock stage. This results in the mutex not being unlocked, resulting in a deadlock. Fix it by making the opt3001_irq() code generally more robust, reading the flag into a variable and using the variable value at both stages.
https://git.kernel.org/stable/c/f063a28002e3350088b4577c5640882bf4ea17ea
https://git.kernel.org/stable/c/e791bf216c9e236b34dabf514ec0ede140cca719
https://git.kernel.org/stable/c/a9c56ccb7cddfca754291fb24b108a5350a5fbe9
https://git.kernel.org/stable/c/957e8be112636d9bc692917286e81e54bd87decc
https://git.kernel.org/stable/c/7ca84f6a22d50bf8b31efe9eb05f9859947266d7
https://git.kernel.org/stable/c/748ebd8e61d0bc182c331b8df3887af7285c8a8f
https://git.kernel.org/stable/c/2c95c8f0959d0a72575eabf2ff888f47ed6d8b77
https://git.kernel.org/stable/c/1d7def97e7eb65865ccc01bbdf4eb9e6bbe8a5b5