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: <20220310170554.GH8224@magnolia>
Date:   Thu, 10 Mar 2022 09:05:54 -0800
From:   "Darrick J. Wong" <djwong@...nel.org>
To:     Jiasheng Jiang <jiasheng@...as.ac.cn>
Cc:     linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] xfs: xfs_rmap_item: Add ASSERT after calling kmem_zalloc

On Thu, Mar 10, 2022 at 05:43:03PM +0800, Jiasheng Jiang wrote:
> As the potential failure of the kmem_zalloc() without __GFP_NOFAIL,
> it should be better to check it in order to avoid the dereference
> of NULL pointer.
> 
> Fixes: 5880f2d78ff1 ("xfs: create rmap update intent log items")
> Signed-off-by: Jiasheng Jiang <jiasheng@...as.ac.cn>
> ---
>  fs/xfs/xfs_rmap_item.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/xfs/xfs_rmap_item.c b/fs/xfs/xfs_rmap_item.c
> index c3966b4c58ef..66395faeeb87 100644
> --- a/fs/xfs/xfs_rmap_item.c
> +++ b/fs/xfs/xfs_rmap_item.c
> @@ -143,6 +143,7 @@ xfs_rui_init(
>  	else
>  		ruip = kmem_cache_zalloc(xfs_rui_cache,
>  					 GFP_KERNEL | __GFP_NOFAIL);
> +	ASSERT(ruip);
>  
>  	xfs_log_item_init(mp, &ruip->rui_item, XFS_LI_RUI, &xfs_rui_item_ops);

Setting aside for a moment the fact that we'll crash immediately on the
very next line anyways --

The defer ops code will never create an rmap intent item with nextents >
XFS_RUI_MAX_FAST_EXTENTS, so the only way that we'd end up in the
kmem_zalloc path is if one came in via log recovery.  We're allowed to
fail log recovery, so why not return NULL if kmem_zalloc fails, and then
patch xlog_recover_rui_commit_pass2 to return ENOMEM if it cannot
allocate ruip?

While we're on this topic -- do the other xfs log intent items need
similar corrections in the xfs_*_init() callers?

--D

>  	ruip->rui_format.rui_nextents = nextents;
> -- 
> 2.25.1
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ