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: <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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ