All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill O'Donnell <bodonnel@redhat.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
	linux-xfs@vger.kernel.org, cem@kernel.org
Subject: Re: [PATCH v3] xfs_db: release ip resource before returning from get_next_unlinked()
Date: Thu, 8 Aug 2024 14:41:39 -0500	[thread overview]
Message-ID: <ZrUfc57VJ-RPreCL@redhat.com> (raw)
In-Reply-To: <3a91d785-8c8f-4d2b-998f-a4cd92353120@sandeen.net>

On Thu, Aug 08, 2024 at 02:00:22PM -0500, Eric Sandeen wrote:
> On 8/8/24 1:28 PM, Darrick J. Wong wrote:
> > On Wed, Aug 07, 2024 at 02:38:03PM -0500, Bill O'Donnell wrote:
> >> Fix potential memory leak in function get_next_unlinked(). Call
> >> libxfs_irele(ip) before exiting.
> >>
> >> Details:
> >> Error: RESOURCE_LEAK (CWE-772):
> >> xfsprogs-6.5.0/db/iunlink.c:51:2: alloc_arg: "libxfs_iget" allocates memory that is stored into "ip".
> >> xfsprogs-6.5.0/db/iunlink.c:68:2: noescape: Resource "&ip->i_imap" is not freed or pointed-to in "libxfs_imap_to_bp".
> >> xfsprogs-6.5.0/db/iunlink.c:76:2: leaked_storage: Variable "ip" going out of scope leaks the storage it points to.
> >> #   74|   	libxfs_buf_relse(ino_bp);
> >> #   75|
> >> #   76|-> 	return ret;
> >> #   77|   bad:
> >> #   78|   	dbprintf(_("AG %u agino %u: %s\n"), agno, agino, strerror(error));
> >>
> >> Signed-off-by: Bill O'Donnell <bodonnel@redhat.com>
> >> ---
> >> v2: cover error case.
> >> v3: fix coverage to not release unitialized variable.
> >> ---
> >>  db/iunlink.c | 7 +++++--
> >>  1 file changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/db/iunlink.c b/db/iunlink.c
> >> index d87562e3..57e51140 100644
> >> --- a/db/iunlink.c
> >> +++ b/db/iunlink.c
> >> @@ -66,15 +66,18 @@ get_next_unlinked(
> >>  	}
> >>  
> >>  	error = -libxfs_imap_to_bp(mp, NULL, &ip->i_imap, &ino_bp);
> >> -	if (error)
> >> +	if (error) {
> >> +		libxfs_buf_relse(ino_bp);
> > 
> > Sorry, I think I've led you astray -- it's not necessary to
> > libxfs_buf_relse in any of the bailouts.
> > 
> > --D
> > 
> >>  		goto bad;
> >> -
> >> +	}
> >>  	dip = xfs_buf_offset(ino_bp, ip->i_imap.im_boffset);
> >>  	ret = be32_to_cpu(dip->di_next_unlinked);
> >>  	libxfs_buf_relse(ino_bp);
> >> +	libxfs_irele(ip);
> >>  
> >>  	return ret;
> >>  bad:
> >> +	libxfs_irele(ip);
> 
> And this addition results in a libxfs_irele of an ip() which failed iget()
> via the first goto bad, so you're releasing a thing which was never obtained,
> which doesn't make sense.
> 
> 
> There are 2 relevant actions here. The libxfs_iget, and the libxfs_imap_to_bp.
> Only after libxfs_iget(ip) /succeeds/ does it need a libxfs_irele(ip), on either
> error paths or normal exit. The fact that it does neither leads to the two leaks
> noted in CID 1554242.

In libxfs_iget, -ENOMEM is returned when kmem_cache_zalloc() fails. For all other
error cases in that function, kmem_cache_free() releases the memory that was presumably
successfully allocated. I had wondered if we need to use libxfs_irele() at all in
get_next_unlinked() (except for the success case)?


> libxfs_imap_to_bp needs a corresponding libxfs_buf_relse() (thanks for clarifying
> djwong) but that libxfs_buf_relse() is already present if libxfs_imap_to_bp
> succeeds. It's not needed if it fails, because there's nothing to release.
> 
> When Darrick said
> 
> > I think this needs to cover the error return for libxfs_imap_to_bp too,
> > doesn't it?
> 
> I think he meant that in the error case where libxfs_imap_to_bp fails, libxfs_irele
> is also needed. (In addition to being needed on a normal return.)
> 
> -Eric
> 


  reply	other threads:[~2024-08-08 19:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-07 19:38 [PATCH v3] xfs_db: release ip resource before returning from get_next_unlinked() Bill O'Donnell
2024-08-08 14:14 ` Christoph Hellwig
2024-08-08 18:28 ` Darrick J. Wong
2024-08-08 19:00   ` Eric Sandeen
2024-08-08 19:41     ` Bill O'Donnell [this message]
2024-08-08 21:13       ` Bill O'Donnell
2024-08-09  2:04         ` Eric Sandeen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZrUfc57VJ-RPreCL@redhat.com \
    --to=bodonnel@redhat.com \
    --cc=cem@kernel.org \
    --cc=djwong@kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.