linux-kernel - Re: [PATCH] xfs: destroy mutex qi_tree_lock before free xfs_quotainfo

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: <20180102203819.GF4857@magnolia>
Date:   Tue, 2 Jan 2018 12:38:19 -0800
From:   "Darrick J. Wong" <darrick.wong@...cle.com>
To:     Xiongwei Song <sxwjean@...il.com>
Cc:     linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] xfs: destroy mutex qi_tree_lock before free
 xfs_quotainfo_t object

On Sun, Dec 24, 2017 at 08:34:47PM +0800, Xiongwei Song wrote:
> The mutex qi_tree_lock of xfs_quotainfo_t object was initialized when
> calling xfs_qm_init_quotainfo, but it was not destroyed before free
> xfs_quotainfo_t object when calling xfs_qm_destroy_quotainfo, this was
> incorrect, so destroy it in function xfs_qm_destroy_quotainfo.

Already in for-next, but thank you for catching this.

https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/commit/?h=for-next&id=2196881566225f3c3428d1a5f847a992944daa5b

--D

> Signed-off-by: Xiongwei Song <sxwjean@...il.com>
> ---
>  fs/xfs/xfs_qm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/xfs/xfs_qm.c b/fs/xfs/xfs_qm.c
> index ec952dfad359..deceef5cbbf3 100644
> --- a/fs/xfs/xfs_qm.c
> +++ b/fs/xfs/xfs_qm.c
> @@ -737,6 +737,7 @@ xfs_qm_destroy_quotainfo(
>  		qi->qi_pquotaip = NULL;
>  	}
>  	mutex_destroy(&qi->qi_quotaofflock);
> +	mutex_destroy(&qi->qi_tree_lock);
>  	kmem_free(qi);
>  	mp->m_quotainfo = NULL;
>  }
> -- 
> 2.15.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html