linux-kernel - Re: BUG: possible deadlock in __ata_sff

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <2475124e-d4a1-4836-b5a0-3c00f5a5a94d@kernel.org>
Date: Mon, 9 Dec 2024 09:34:55 +0900
From: Damien Le Moal <dlemoal@...nel.org>
To: Juefei Pu <juefei.pu@...il.ucr.edu>, cassel@...nel.org,
 linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: BUG: possible deadlock in __ata_sff_interrupt

On 8/27/24 05:46, Juefei Pu wrote:
> Hello,
> We found the following issue using syzkaller on Linux v6.10.

Can you run the same against the latest 6.13-rc2 ?

> A possible deadlock issue was discovered in function
> `__ata_sff_interrupt` when it attempted to acquire lock `host->lock`.
> 
> Unfortunately, the syzkaller failed to generate a reproducer.
> But at least we have the report:
> 
> sr 1:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_ERROR
> driverbyte=DRIVER_OK cmd_age=0s
> sr 1:0:0:0: [sr0] tag#0 CDB: opcode=0x98 98 61 1e 1d 47 a1 77 90 29 76
> 7f 40 b8 5e 03 63
> =====================================================
> WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
> 6.10.0 #13 Not tainted
> -----------------------------------------------------
> syz.1.961/19801 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
> ffff88802d3a4018 (&new->fa_lock){....}-{2:2}, at: kill_fasync_rcu
> fs/fcntl.c:1028 [inline]
> ffff88802d3a4018 (&new->fa_lock){....}-{2:2}, at:
> kill_fasync+0x196/0x4d0 fs/fcntl.c:1049
> 
> and this task is already holding:
> ffff88801ca06018 (&host->lock){-.-.}-{2:2}, at:
> ata_scsi_queuecmd+0x8a/0x520 drivers/ata/libata-scsi.c:4197
> which would create a new lock dependency:
>  (&host->lock){-.-.}-{2:2} -> (&new->fa_lock){....}-{2:2}

[...]

> Chain exists of:
>   &host->lock --> &new->fa_lock --> tasklist_lock
> 
>  Possible interrupt unsafe locking scenario:
> 
>        CPU0                    CPU1
>        ----                    ----
>   lock(tasklist_lock);
>                                local_irq_disable();
>                                lock(&host->lock);
>                                lock(&new->fa_lock);
>   <Interrupt>
>     lock(&host->lock);

I fail to see how this can happen given that the first thing that
kill_fasync+0x196/0x4d0 fs/fcntl.c:1049 is "write_lock_irq(&fa->fa_lock);" so
IRQs are disabled... Lockdep is confused ?

-- 
Damien Le Moal
Western Digital Research