linux-kernel - Re: [PATCH] enic: Fix a sleep-in-atomic bug

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: <20170531.143738.91013741875059886.davem@davemloft.net>
Date:   Wed, 31 May 2017 14:37:38 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     baijiaju1990@....com
Cc:     benve@...co.com, _govind@....com, neepatel@...co.com,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] enic: Fix a sleep-in-atomic bug

From: Jia-Ju Bai <baijiaju1990@....com>
Date: Wed, 31 May 2017 10:34:49 +0800

> The driver may sleep under a spin lock in some function call paths.
> The 1st function call path is:
> enic_reset (acquire the lock by spin_lock)
>   enic_stop
>     enic_synchronize_irqs
>       synchronize_irq --> may sleep
> The 2nd function call path is:
> enic_reset (acquire the lock by spin_lock)
>   enic_dev_soft_reset
>     enic_dev_wait
>       schedule_timeout_uninterruptible --> may sleep
> The 3rd function call path is:
> enic_reset (acquire the lock by spin_lock)
>   enic_open
>     enic_request_intr
>       enic_set_rx_cpu_rmap
>         enic_free_rx_cpu_rmap
>           free_irq_cpu_rmap --> may sleep
> 
> To fix it, the "spin_lock" and "spin_unlock" are removed in enic_reset.
> 
> Signed-off-by: Jia-Ju Bai <baijiaju1990@....com>

That's not necessarily safe at all, the lock is probably needed for
synchronization.