Re: [PATCH] ceph: avoid putting the realm twice when docoding snaps fails

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 07, 2022 at 03:17:59PM +0800, xiubli@xxxxxxxxxx wrote:
> From: Xiubo Li <xiubli@xxxxxxxxxx>
> 
> When decoding the snaps fails it maybe leaving the 'first_realm'
> and 'realm' pointing to the same snaprealm memory. And then it'll
> put it twice and could cause random use-after-free, BUG_ON, etc
> issues.
> 
> Cc: stable@xxxxxxxxxxxxxxx
> URL: https://tracker.ceph.com/issues/57686
> Signed-off-by: Xiubo Li <xiubli@xxxxxxxxxx>
> ---
>  fs/ceph/snap.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/ceph/snap.c b/fs/ceph/snap.c
> index 9bceed2ebda3..baf17df05107 100644
> --- a/fs/ceph/snap.c
> +++ b/fs/ceph/snap.c
> @@ -849,10 +849,12 @@ int ceph_update_snap_trace(struct ceph_mds_client *mdsc,
>  	if (realm_to_rebuild && p >= e)
>  		rebuild_snap_realms(realm_to_rebuild, &dirty_realms);
>  
> -	if (!first_realm)
> +	if (!first_realm) {
>  		first_realm = realm;
> -	else
> +		realm = NULL;
> +	} else {
>  		ceph_put_snap_realm(mdsc, realm);
> +	}
>  
>  	if (p < e)
>  		goto more;
> -- 
> 2.31.1
> 

This patch looks correct to me.  But I wonder if there's a deeper problem
there (probably not on the kernel client).  Because the other question is:
why are we failing to decode the snaps?  But I guess this fix is worth it
anyway.

Reviewed-by: Luís Henriques <lhenriques@xxxxxxx>


Cheers,
--
Luís



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Ceph Dev]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux