As &info->lock is acquired by slgt_interrupt() under irq context, other
process context code acquiring the lock should disable irq, otherwise
deadlock could happen if the irq preempt the execution while the
lock is held in process context on the same CPU.
Lock acquisition inside set_params32() does not disable irq, and this
function is called by slgt_compat_ioctl() from process context.
Possible deadlock scenario:
slgt_compat_ioctl()
-> set_params32()
-> spin_lock(&info->lock)
<irq>
-> slgt_interrupt()
-> spin_lock(&info->lock); (deadlock here)
This flaw was found by an experimental static analysis tool I am developing
for irq-related deadlock. x86_64 allmodconfig using gcc shows no new
warning.
The patch fixes the potential deadlock by spin_lock_irqsave() like other
lock acquisition sites.
Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230728123901.64225-1-dg573847474@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
static long set_params32(struct slgt_info *info, struct MGSL_PARAMS32 __user *new_params)
{
struct MGSL_PARAMS32 tmp_params;
+ unsigned long flags;
DBGINFO(("%s set_params32\n", info->device_name));
if (copy_from_user(&tmp_params, new_params, sizeof(struct MGSL_PARAMS32)))
return -EFAULT;
- spin_lock(&info->lock);
+ spin_lock_irqsave(&info->lock, flags);
if (tmp_params.mode == MGSL_MODE_BASE_CLOCK) {
info->base_clock = tmp_params.clock_speed;
} else {
info->params.stop_bits = tmp_params.stop_bits;
info->params.parity = tmp_params.parity;
}
- spin_unlock(&info->lock);
+ spin_unlock_irqrestore(&info->lock, flags);
program_hw(info);