From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Matheus Tavares Bernardino <quic_mathbern@quicinc.com>
Cc: qemu-devel@nongnu.org, alejandro.zeise@seagate.com,
clg@redhat.com, qemu-arm@nongnu.org, kris.conklin@seagate.com,
jonathan.henze@seagate.com, evan.burgess@seagate.com,
clg@kaod.org, peter.maydell@linaro.org, bcain@quicinc.com,
sidneym@quicinc.com
Subject: Re: qcrypto_ivgen mem leak and possible issue?
Date: Fri, 25 Oct 2024 17:23:57 +0100 [thread overview]
Message-ID: <ZxvGHesrhPlQri__@redhat.com> (raw)
In-Reply-To: <60849a6166bba234230bc1761835cc188a9f765f.1729858348.git.quic_mathbern@quicinc.com>
On Fri, Oct 25, 2024 at 01:06:01PM -0300, Matheus Tavares Bernardino wrote:
> Hi,
>
> Since e3c07527f3 (crypto/hash: Implement and use new hash API,
> 2024-10-08), we've been seeing a memory leak in two check-unit tests:
> test-crypto-hash and test-crypto-ivgen. Looking a bit further to try and
> plug the leak, I got a bit confused regarding how the result crypto
> buffer is handled. Looks like we are allocating different sizes at two
> different places, and I'm unsure if these places follow the same
> convention or could be breaking expectations from one another...
There was a screwup in the commit you mention causing a memory leak. Can
you check whether it reproduces after
commit dde538c9a76f328a92c532893e97e18785d57364
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Tue Oct 15 13:25:36 2024 +0100
crypto/hash: avoid overwriting user supplied result pointer
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2024-10-25 16:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-25 16:06 qcrypto_ivgen mem leak and possible issue? Matheus Tavares Bernardino
2024-10-25 16:23 ` Daniel P. Berrangé [this message]
2024-10-25 17:31 ` Matheus Tavares Bernardino
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=ZxvGHesrhPlQri__@redhat.com \
--to=berrange@redhat.com \
--cc=alejandro.zeise@seagate.com \
--cc=bcain@quicinc.com \
--cc=clg@kaod.org \
--cc=clg@redhat.com \
--cc=evan.burgess@seagate.com \
--cc=jonathan.henze@seagate.com \
--cc=kris.conklin@seagate.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quic_mathbern@quicinc.com \
--cc=sidneym@quicinc.com \
/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.