linux-kernel - Re: [PATCH] futex: Prevent pi_state from double freeing in case of error

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

Message-ID: <20151218145534.GD17386@linux-uzut.site>
Date:	Fri, 18 Dec 2015 06:55:34 -0800
From:	Davidlohr Bueso <dave@...olabs.net>
To:	Bhuvanesh_Surachari@...tor.com
Cc:	tglx@...utronix.de, peterz@...radead.org, mingo@...nel.org,
	akpm@...ux-foundation.org, linux@...musvillemoes.dk,
	viresh.kumar@...aro.org, luto@...capital.net,
	bigeasy@...utronix.de, mtk.manpages@...il.com,
	linux-kernel@...r.kernel.org, Andy Lowe <Andy_Lowe@...tor.com>
Subject: Re: [PATCH] futex: Prevent pi_state from double freeing in case of
 error

On Fri, 18 Dec 2015, Bhuvanesh_Surachari@...tor.com wrote:

>From: Bhuvanesh Surachari <bhuvanesh_surachari@...tor.com>
>
>In case of error from rt_mutex_start_proxy_lock pi_state is freed
>twice in futex_requeue function. Hence removing free_pi_state in
>else branch and branching to the location where pi_state is freed.

This reads weird.

Do note that free_pi_state is already protected against passing it a nil
pi_state, so this is merely cosmetic.

Hmm but yeah, looks legit. The cases were we free the pi_state on error
are when doing retry kind of paths, EDEADLK not being one of those cases.

>
>Signed-off-by: Bhuvanesh Surachari <Bhuvanesh_Surachari@...tor.com>
>Signed-off-by: Andy Lowe <Andy_Lowe@...tor.com>

This last SoB tag is incorrect, Andy Lowe is not carrying the patch for you.

>---
> kernel/futex.c |    1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/kernel/futex.c b/kernel/futex.c
>index 684d754..264b3f2 100644
>--- a/kernel/futex.c
>+++ b/kernel/futex.c
>@@ -1815,7 +1815,6 @@ retry_private:
> 			} else if (ret) {
> 				/* -EDEADLK */
> 				this->pi_state = NULL;
>-				free_pi_state(pi_state);
> 				goto out_unlock;
> 			}
> 		}


Nit but I think we also want to set pi_state to nil after freeing it
in out_unlock. That way this scenario would simply be goto out_unlock.

Thanks,
Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/