linux-kernel - Re: [PATCH] watchdog:alim1535_wdt: Fix data race in ali_settimer() concerning ali_timeout

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>] [day] [month] [year] [list]

Message-ID: <20190722163855.GC8122@roeck-us.net>
Date:   Mon, 22 Jul 2019 09:38:55 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Mark Balantzyan <mbalant3@...il.com>
Cc:     Pavel Andrianov <andrianov@...ras.ru>, wim@...ux-watchdog.org,
        linux-kernel@...r.kernel.org, linux-watchdog@...r.kernel.org
Subject: Re: [PATCH] watchdog:alim1535_wdt: Fix data race in ali_settimer()
 concerning ali_timeout_bits variable.

On Mon, Jul 22, 2019 at 07:35:03AM -0700, Mark Balantzyan wrote:
> Hello all,
> 
> I had previously submitted 2 patches attempting to fix the data race
> condition in alim1535_wdt.c as part of my work with individuals on the
> Linux Driver Verification project. I am including the original patch
> description I provided, below, along with revised patch. Thank you.
> 
> (PATCH DESCRIPTION AND PATCH BELOW)
> 
This is not how the description is supposed to look like; the above would
end up in the commit log. Please check the kernel documentation on how
to write subject lines and patch descriptions.

> In drivers/watchdog/ailm1535_wdt.c, there is the potential for a data race
> due to parallel call stacks as follows: Thread 1 calls a file operation
> callback, denoted *ali_fops* in the .c file, which in turn results in calls
> to ali_write() followed by ali_start(), which has the line
> 
> val |= (1 << 25) | ali_timeout_bits;
> 
> surrounded by a spin_lock and spin_unlock. This is crucial because Thread 2

The "surrounded by spinlock" does not refer to the line above, but to
pci_read_config_dword() followed by pci_write_config_dword(), which
needs to be protected. The described race condition around ali_timeout_bits
[ali_start() vs. ali_settimer()] does not exist.

The only race condition in the driver is 'ali_timeout_bits' vs. 'timeout'.
It is theoretically possible that those two get out of sync, ie that
ali_timeout_bits does not reflect the value of timeout. This can happen
if one of the threads is interrupted after setting 'ali_timeout_bits' but
before updating 'timeout'.

> can access "ali_timeout_bits" then when it calls ali_ioctl(), which calls
> ali_settimer() having the lines (else if (t < 60) ali_timeout_bits = t|(1
>  << 6);, lines 112-113, etc.)
> 
There is no need to be that detailed. It is sufficient to explain that
there is a race condition when updating 'ali_timeout_bits' and 'timeout'
(or maybe use my explanation above).

> (Revised) patch adds spinlocking around "ali_timeout_bits" in
> ali_settimer() should "ali_ioctl()" be called in a concurrent thread (at
> any time).
> ---
>  drivers/watchdog/alim1535_wdt.c | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/watchdog/alim1535_wdt.c
> b/drivers/watchdog/alim1535_wdt.c
> index 60f0c2e..1260e9e 100644
> --- a/drivers/watchdog/alim1535_wdt.c
> +++ b/drivers/watchdog/alim1535_wdt.c
> @@ -106,19 +106,23 @@ static void ali_keepalive(void)
>   */
> 
>  static int ali_settimer(int t)
> -{
> - if (t < 0)
> +{ spin_lock(&ali_lock);
> + if (t < 0) {
> + spin_unlock(&ali_unlock);
>   return -EINVAL;
> + }
>   else if (t < 60)
>   ali_timeout_bits = t|(1 << 6);
>   else if (t < 3600)
>   ali_timeout_bits = (t / 60)|(1 << 7);
>   else if (t < 18000)
>   ali_timeout_bits = (t / 300)|(1 << 6)|(1 << 7);
> - else
> + else {
> + spin_unlock(&ali_lock);
>   return -EINVAL;

Please use goto for error exits, as suggested in the coding style document.

> -
> + }
>   timeout = t;
> + spin_unlock(&ali_lock);
>   return 0;
>  }

Formatting is completely messed up.

> 
> -- 
> 2.15.1
> Signed-off-by: Mark Balantzyan <mbalant3@...il.com>

Wrong location for Signed-off-by:.

Guenter