linux-kernel - Re: [PATCH] tty: synclink_gt: Fix potential deadlock on &info->lock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <75f58741-a18d-2e92-ecb3-8f997a3ef404@kernel.org>
Date:   Mon, 31 Jul 2023 07:40:38 +0200
From:   Jiri Slaby <jirislaby@...nel.org>
To:     Chengfeng Ye <dg573847474@...il.com>, gregkh@...uxfoundation.org,
        ilpo.jarvinen@...ux.intel.com, bhelgaas@...gle.com,
        russell.h.weight@...el.com
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tty: synclink_gt: Fix potential deadlock on &info->lock

On 28. 07. 23, 14:39, Chengfeng Ye wrote:
> 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@...il.com>

Oh well, this driver deserves to die (or a massive rewrite).

Reviewed-by: Jiri Slaby <jirislaby@...nel.org>

thanks,
-- 
js
suse labs