[PATCH 0/4] arm: Fix some memory leaks

[PATCH 0/4] arm: Fix some memory leaks

[Peter Maydell]

This patchset fixes a couple of minor memory leaks I found by running
"make check" for the arm targets with the clang leak sanitizer enabled.

The first two patches are necessary because there are a few leaks
that are either not interesting to fix or which are not in our code,
and which otherwise clutter up the logs with failure messages.
We have a suppressions-file already, but it's in the scripts/oss-fuzz
subdirectory, so I move it out as it's more widely useful than that,
and add some more suppression lines to it.

Patches 3 and 4 are the actual leak fixes, which are straightforward.

This gets me what would be a clean run, except that there's something
wrong with the refcounting of qio channel objects in the chardev code,
which results in variously use-after-free, leak, or assertion failures
when running the vhost-user tests in qos-test. I'm still looking at
those, but in the meantime posting this series gives me something to
point at as part of the repro instructions for those errors.

thanks
-- PMM

Peter Maydell (4):
  scripts: Move lsan_suppressions.txt out of oss-fuzz subdir
  scripts/lsan_suppressions.txt: Add more leaks
  hw/arm/aspeed_gpio: Don't leak string in aspeed_gpio_init()
  tests/qtest/iommu-smmuv3-test: Free QPCIDevice

 .gitlab-ci.d/buildtest.yml             |  2 +-
 hw/gpio/aspeed_gpio.c                  |  2 +-
 scripts/lsan_suppressions.txt          | 31 ++++++++++++++++++++++++++
 scripts/oss-fuzz/lsan_suppressions.txt |  5 -----
 tests/qtest/iommu-smmuv3-test.c        |  1 +
 5 files changed, 34 insertions(+), 7 deletions(-)
 create mode 100644 scripts/lsan_suppressions.txt
 delete mode 100644 scripts/oss-fuzz/lsan_suppressions.txt

-- 
2.43.0

[PATCH 1/4] scripts: Move lsan_suppressions.txt out of oss-fuzz subdir

[Peter Maydell]

The oss-fuzz code uses an lsan_suppressions file to suppress certain
leak-sanitizer cases that are known issues or not our code's bug.
This is useful more widely than just for the fuzzer harness: if you
want to build QEMU with the leak sanitizer enabled and run 'make
check' then you will want to suppress some bogus leak reports.

Move the file up a directory, and add the usual SPDX identifier
and a comment describing how to use it.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 .gitlab-ci.d/buildtest.yml             |  2 +-
 scripts/lsan_suppressions.txt          | 11 +++++++++++
 scripts/oss-fuzz/lsan_suppressions.txt |  5 -----
 3 files changed, 12 insertions(+), 6 deletions(-)
 create mode 100644 scripts/lsan_suppressions.txt
 delete mode 100644 scripts/oss-fuzz/lsan_suppressions.txt

diff --git a/.gitlab-ci.d/buildtest.yml b/.gitlab-ci.d/buildtest.yml
index 1b656b9eb0..7548057c54 100644
--- a/.gitlab-ci.d/buildtest.yml
+++ b/.gitlab-ci.d/buildtest.yml
@@ -626,7 +626,7 @@ build-oss-fuzz:
     IMAGE: fedora
   script:
     - mkdir build-oss-fuzz
-    - export LSAN_OPTIONS=suppressions=scripts/oss-fuzz/lsan_suppressions.txt
+    - export LSAN_OPTIONS=suppressions=scripts/lsan_suppressions.txt
     - CC="clang" CXX="clang++" CFLAGS="-fsanitize=address"
       ./scripts/oss-fuzz/build.sh
     - export ASAN_OPTIONS="fast_unwind_on_malloc=0"
diff --git a/scripts/lsan_suppressions.txt b/scripts/lsan_suppressions.txt
new file mode 100644
index 0000000000..ffade3ba5a
--- /dev/null
+++ b/scripts/lsan_suppressions.txt
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+# This is a set of suppressions for LeakSanitizer; you can use it by setting
+#   LSAN_OPTIONS="suppressions=/path/to/scripts/lsan_suppressions.txt"
+# when running a QEMU built with the leak-sanitizer.
+
+# The tcmalloc on Fedora37 confuses things
+leak:/lib64/libtcmalloc_minimal.so.4
+
+# libxkbcommon also leaks in qemu-keymap
+leak:/lib64/libxkbcommon.so.0
diff --git a/scripts/oss-fuzz/lsan_suppressions.txt b/scripts/oss-fuzz/lsan_suppressions.txt
deleted file mode 100644
index 7d90c280d0..0000000000
--- a/scripts/oss-fuzz/lsan_suppressions.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-# The tcmalloc on Fedora37 confuses things
-leak:/lib64/libtcmalloc_minimal.so.4
-
-# libxkbcommon also leaks in qemu-keymap
-leak:/lib64/libxkbcommon.so.0
-- 
2.43.0

Re: [PATCH 1/4] scripts: Move lsan_suppressions.txt out of oss-fuzz subdir

[Peter Maydell]

I forgot to cc the 'device fuzzing' maintainers on this patch;
sorry about that.

-- PMM

On Fri, 27 Feb 2026 at 13:57, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> The oss-fuzz code uses an lsan_suppressions file to suppress certain
> leak-sanitizer cases that are known issues or not our code's bug.
> This is useful more widely than just for the fuzzer harness: if you
> want to build QEMU with the leak sanitizer enabled and run 'make
> check' then you will want to suppress some bogus leak reports.
>
> Move the file up a directory, and add the usual SPDX identifier
> and a comment describing how to use it.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>  .gitlab-ci.d/buildtest.yml             |  2 +-
>  scripts/lsan_suppressions.txt          | 11 +++++++++++
>  scripts/oss-fuzz/lsan_suppressions.txt |  5 -----
>  3 files changed, 12 insertions(+), 6 deletions(-)
>  create mode 100644 scripts/lsan_suppressions.txt
>  delete mode 100644 scripts/oss-fuzz/lsan_suppressions.txt
>
> diff --git a/.gitlab-ci.d/buildtest.yml b/.gitlab-ci.d/buildtest.yml
> index 1b656b9eb0..7548057c54 100644
> --- a/.gitlab-ci.d/buildtest.yml
> +++ b/.gitlab-ci.d/buildtest.yml
> @@ -626,7 +626,7 @@ build-oss-fuzz:
>      IMAGE: fedora
>    script:
>      - mkdir build-oss-fuzz
> -    - export LSAN_OPTIONS=suppressions=scripts/oss-fuzz/lsan_suppressions.txt
> +    - export LSAN_OPTIONS=suppressions=scripts/lsan_suppressions.txt
>      - CC="clang" CXX="clang++" CFLAGS="-fsanitize=address"
>        ./scripts/oss-fuzz/build.sh
>      - export ASAN_OPTIONS="fast_unwind_on_malloc=0"
> diff --git a/scripts/lsan_suppressions.txt b/scripts/lsan_suppressions.txt
> new file mode 100644
> index 0000000000..ffade3ba5a
> --- /dev/null
> +++ b/scripts/lsan_suppressions.txt
> @@ -0,0 +1,11 @@
> +# SPDX-License-Identifier: GPL-2.0-or-later
> +
> +# This is a set of suppressions for LeakSanitizer; you can use it by setting
> +#   LSAN_OPTIONS="suppressions=/path/to/scripts/lsan_suppressions.txt"
> +# when running a QEMU built with the leak-sanitizer.
> +
> +# The tcmalloc on Fedora37 confuses things
> +leak:/lib64/libtcmalloc_minimal.so.4
> +
> +# libxkbcommon also leaks in qemu-keymap
> +leak:/lib64/libxkbcommon.so.0
> diff --git a/scripts/oss-fuzz/lsan_suppressions.txt b/scripts/oss-fuzz/lsan_suppressions.txt
> deleted file mode 100644
> index 7d90c280d0..0000000000
> --- a/scripts/oss-fuzz/lsan_suppressions.txt
> +++ /dev/null
> @@ -1,5 +0,0 @@
> -# The tcmalloc on Fedora37 confuses things
> -leak:/lib64/libtcmalloc_minimal.so.4
> -
> -# libxkbcommon also leaks in qemu-keymap
> -leak:/lib64/libxkbcommon.so.0
> --
> 2.43.0

Re: [PATCH 1/4] scripts: Move lsan_suppressions.txt out of oss-fuzz subdir

[Yodel Eldar]

Hi, Peter

On 27/02/2026 09:04, Peter Maydell wrote:
> I forgot to cc the 'device fuzzing' maintainers on this patch;
> sorry about that.
> 
> -- PMM
> 
> On Fri, 27 Feb 2026 at 13:57, Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> The oss-fuzz code uses an lsan_suppressions file to suppress certain
>> leak-sanitizer cases that are known issues or not our code's bug.
>> This is useful more widely than just for the fuzzer harness: if you
>> want to build QEMU with the leak sanitizer enabled and run 'make
>> check' then you will want to suppress some bogus leak reports.
>>
>> Move the file up a directory, and add the usual SPDX identifier
>> and a comment describing how to use it.
>>
>> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>> ---
>>   .gitlab-ci.d/buildtest.yml             |  2 +-
>>   scripts/lsan_suppressions.txt          | 11 +++++++++++
>>   scripts/oss-fuzz/lsan_suppressions.txt |  5 -----
>>   3 files changed, 12 insertions(+), 6 deletions(-)
>>   create mode 100644 scripts/lsan_suppressions.txt
>>   delete mode 100644 scripts/oss-fuzz/lsan_suppressions.txt
>>
>> diff --git a/.gitlab-ci.d/buildtest.yml b/.gitlab-ci.d/buildtest.yml
>> index 1b656b9eb0..7548057c54 100644
>> --- a/.gitlab-ci.d/buildtest.yml
>> +++ b/.gitlab-ci.d/buildtest.yml
>> @@ -626,7 +626,7 @@ build-oss-fuzz:
>>       IMAGE: fedora
>>     script:
>>       - mkdir build-oss-fuzz
>> -    - export LSAN_OPTIONS=suppressions=scripts/oss-fuzz/lsan_suppressions.txt
>> +    - export LSAN_OPTIONS=suppressions=scripts/lsan_suppressions.txt
>>       - CC="clang" CXX="clang++" CFLAGS="-fsanitize=address"
>>         ./scripts/oss-fuzz/build.sh
>>       - export ASAN_OPTIONS="fast_unwind_on_malloc=0"
>> diff --git a/scripts/lsan_suppressions.txt b/scripts/lsan_suppressions.txt
>> new file mode 100644
>> index 0000000000..ffade3ba5a
>> --- /dev/null
>> +++ b/scripts/lsan_suppressions.txt
>> @@ -0,0 +1,11 @@
>> +# SPDX-License-Identifier: GPL-2.0-or-later
>> +
>> +# This is a set of suppressions for LeakSanitizer; you can use it by setting
>> +#   LSAN_OPTIONS="suppressions=/path/to/scripts/lsan_suppressions.txt"
>> +# when running a QEMU built with the leak-sanitizer.
>> +
>> +# The tcmalloc on Fedora37 confuses things
>> +leak:/lib64/libtcmalloc_minimal.so.4
>> +
>> +# libxkbcommon also leaks in qemu-keymap
>> +leak:/lib64/libxkbcommon.so.0
>> diff --git a/scripts/oss-fuzz/lsan_suppressions.txt b/scripts/oss-fuzz/lsan_suppressions.txt
>> deleted file mode 100644
>> index 7d90c280d0..0000000000
>> --- a/scripts/oss-fuzz/lsan_suppressions.txt
>> +++ /dev/null
>> @@ -1,5 +0,0 @@
>> -# The tcmalloc on Fedora37 confuses things
>> -leak:/lib64/libtcmalloc_minimal.so.4
>> -
>> -# libxkbcommon also leaks in qemu-keymap
>> -leak:/lib64/libxkbcommon.so.0
>> --
>> 2.43.0
> 

The similarity index is under 40%, so `git log --follow` doesn't follow
the move; not a big deal, but separate patches for the move and the new
lines would avoid this and make it easier for folks to get the full
history in one go.

Also, there's a missed reference in the docker test script (diff below).

Thanks,
Yodel

-- >8 --

diff --git a/tests/docker/test-fuzz b/tests/docker/test-fuzz
index 7e506ae1f6..d2bdc8afba 100755
--- a/tests/docker/test-fuzz
+++ b/tests/docker/test-fuzz
@@ -18,7 +18,7 @@ cd "$BUILD_DIR"
  cp -a $QEMU_SRC .
  cd src
  mkdir build-oss-fuzz
-export LSAN_OPTIONS=suppressions=scripts/oss-fuzz/lsan_suppressions.txt
+export LSAN_OPTIONS=suppressions=scripts/lsan_suppressions.txt
  env CC="clang" CXX="clang++" CFLAGS="-fsanitize=address" 
./scripts/oss-fuzz/build.sh
  export ASAN_OPTIONS="fast_unwind_on_malloc=0"
  for fuzzer in $(find ./build-oss-fuzz/DEST_DIR/ -executable -type f | 
grep -v slirp); do

Re: [PATCH 1/4] scripts: Move lsan_suppressions.txt out of oss-fuzz subdir

[Peter Maydell]

On Fri, 27 Feb 2026 at 15:32, Yodel Eldar <yodel.eldar@yodel.dev> wrote:
> Also, there's a missed reference in the docker test script (diff below).

Oops, thanks for catching that.

-- PMM

[PATCH 2/4] scripts/lsan_suppressions.txt: Add more leaks

[Peter Maydell]

Running "make check" with the clang leak sanitizer reveals some
leak reports which are either not our problem or else not
a leak which is worth our time to fix. Add some suppressions
for these.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 scripts/lsan_suppressions.txt | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/scripts/lsan_suppressions.txt b/scripts/lsan_suppressions.txt
index ffade3ba5a..bd6ef07079 100644
--- a/scripts/lsan_suppressions.txt
+++ b/scripts/lsan_suppressions.txt
@@ -9,3 +9,23 @@ leak:/lib64/libtcmalloc_minimal.so.4
 
 # libxkbcommon also leaks in qemu-keymap
 leak:/lib64/libxkbcommon.so.0
+
+# g_set_user_dirs() deliberately leaks the previous cached g_get_user_*
+# values. This is documented in upstream glib's valgrind-format
+# suppression file:
+# https://github.com/GNOME/glib/blob/main/tools/glib.supp
+# This avoids false positive leak reports for the qga-ssh-test.
+leak:g_set_user_dirs
+
+# The walk_path() function in qos-test does free its memory,
+# but something about the setup with tests run in a subprocess
+# seems to confuse the sanitizer. Suppress the errors.
+leak:walk_path
+
+# qemu_irq_intercept_in is only used by the qtest harness, and
+# its API inherently involves a leak.
+# While we could keep track of the old IRQ data structure
+# in order to free it, it doesn't seem very important to fix
+# since it is only used by the qtest test harness.
+# Just ignore the leak, at least for the moment.
+leak:qemu_irq_intercept_in
-- 
2.43.0

Re: [PATCH 2/4] scripts/lsan_suppressions.txt: Add more leaks

[Fabiano Rosas]

Peter Maydell <peter.maydell@linaro.org> writes:

> Running "make check" with the clang leak sanitizer reveals some
> leak reports which are either not our problem or else not
> a leak which is worth our time to fix. Add some suppressions
> for these.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Reviewed-by: Fabiano Rosas <farosas@suse.de>

FYI, mine has these. The first one is on my list to fix once I find some
time. The last two seem to be part of the stack for the ones you added
here.

leak:qcrypto_tls_session_push
leak:gnutls_handshake
leak:memory_region_do_init
leak:qos_traverse_graph
leak:qdev_get_named_gpio_list

> ---
>  scripts/lsan_suppressions.txt | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>
> diff --git a/scripts/lsan_suppressions.txt b/scripts/lsan_suppressions.txt
> index ffade3ba5a..bd6ef07079 100644
> --- a/scripts/lsan_suppressions.txt
> +++ b/scripts/lsan_suppressions.txt
> @@ -9,3 +9,23 @@ leak:/lib64/libtcmalloc_minimal.so.4
>  
>  # libxkbcommon also leaks in qemu-keymap
>  leak:/lib64/libxkbcommon.so.0
> +
> +# g_set_user_dirs() deliberately leaks the previous cached g_get_user_*
> +# values. This is documented in upstream glib's valgrind-format
> +# suppression file:
> +# https://github.com/GNOME/glib/blob/main/tools/glib.supp
> +# This avoids false positive leak reports for the qga-ssh-test.
> +leak:g_set_user_dirs
> +
> +# The walk_path() function in qos-test does free its memory,
> +# but something about the setup with tests run in a subprocess
> +# seems to confuse the sanitizer. Suppress the errors.
> +leak:walk_path
> +
> +# qemu_irq_intercept_in is only used by the qtest harness, and
> +# its API inherently involves a leak.
> +# While we could keep track of the old IRQ data structure
> +# in order to free it, it doesn't seem very important to fix
> +# since it is only used by the qtest test harness.
> +# Just ignore the leak, at least for the moment.
> +leak:qemu_irq_intercept_in

Re: [PATCH 2/4] scripts/lsan_suppressions.txt: Add more leaks

[Peter Maydell]

On Fri, 27 Feb 2026 at 18:57, Fabiano Rosas <farosas@suse.de> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > Running "make check" with the clang leak sanitizer reveals some
> > leak reports which are either not our problem or else not
> > a leak which is worth our time to fix. Add some suppressions
> > for these.
> >
> > Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>
> Reviewed-by: Fabiano Rosas <farosas@suse.de>
>
> FYI, mine has these. The first one is on my list to fix once I find some
> time. The last two seem to be part of the stack for the ones you added
> here.
>
> leak:qcrypto_tls_session_push
> leak:gnutls_handshake
> leak:memory_region_do_init
> leak:qos_traverse_graph
> leak:qdev_get_named_gpio_list

qdev_get_named_gpio_list is definitely used in paths other than
the qemu_irq_intercept_in one we want to hit.

I think that recent memory region fixes ought to have fixed the
ones you're suppressing with memory_region_do_init.

I couldn't make any sense of the qos_traverse_graph/walk_path one:
it seems to be related to the qtest "subprocess" functionality
somehow and doesn't repro without that.

thanks
-- PMM

Re: [PATCH 2/4] scripts/lsan_suppressions.txt: Add more leaks

[Fabiano Rosas]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Fri, 27 Feb 2026 at 18:57, Fabiano Rosas <farosas@suse.de> wrote:
>>
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>
>> > Running "make check" with the clang leak sanitizer reveals some
>> > leak reports which are either not our problem or else not
>> > a leak which is worth our time to fix. Add some suppressions
>> > for these.
>> >
>> > Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>>
>> Reviewed-by: Fabiano Rosas <farosas@suse.de>
>>
>> FYI, mine has these. The first one is on my list to fix once I find some
>> time. The last two seem to be part of the stack for the ones you added
>> here.
>>
>> leak:qcrypto_tls_session_push
>> leak:gnutls_handshake
>> leak:memory_region_do_init
>> leak:qos_traverse_graph
>> leak:qdev_get_named_gpio_list
>
> qdev_get_named_gpio_list is definitely used in paths other than
> the qemu_irq_intercept_in one we want to hit.
>
> I think that recent memory region fixes ought to have fixed the
> ones you're suppressing with memory_region_do_init.
>
> I couldn't make any sense of the qos_traverse_graph/walk_path one:
> it seems to be related to the qtest "subprocess" functionality
> somehow and doesn't repro without that.
>

Ahh I remember this... Here, patch 5/6:

https://lore.kernel.org/r/20241209204427.17763-1-farosas@suse.de

> thanks
> -- PMM

[PATCH 3/4] hw/arm/aspeed_gpio: Don't leak string in aspeed_gpio_init()

[Peter Maydell]

We allocate the string for the GPIO property name, but never free it.
Use g_autofree to avoid this.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 hw/gpio/aspeed_gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c
index d9237d4360..7d0f87e90c 100644
--- a/hw/gpio/aspeed_gpio.c
+++ b/hw/gpio/aspeed_gpio.c
@@ -1488,7 +1488,7 @@ static void aspeed_gpio_init(Object *obj)
     }
 
     for (int i = 0; i < agc->nr_gpio_sets; i++) {
-        char *name = g_strdup_printf("gpio-set[%d]", i);
+        g_autofree char *name = g_strdup_printf("gpio-set[%d]", i);
         object_property_add(obj, name, "uint32", aspeed_gpio_get_set,
         aspeed_gpio_set_set, NULL, NULL);
     }
-- 
2.43.0

Re: [PATCH 3/4] hw/arm/aspeed_gpio: Don't leak string in aspeed_gpio_init()

[Philippe Mathieu-Daudé]

On 27/2/26 14:57, Peter Maydell wrote:
> We allocate the string for the GPIO property name, but never free it.
> Use g_autofree to avoid this.
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>   hw/gpio/aspeed_gpio.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Re: [PATCH 3/4] hw/arm/aspeed_gpio: Don't leak string in aspeed_gpio_init()

[Cédric Le Goater]

On 2/27/26 14:57, Peter Maydell wrote:
> We allocate the string for the GPIO property name, but never free it.
> Use g_autofree to avoid this.
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>   hw/gpio/aspeed_gpio.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c
> index d9237d4360..7d0f87e90c 100644
> --- a/hw/gpio/aspeed_gpio.c
> +++ b/hw/gpio/aspeed_gpio.c
> @@ -1488,7 +1488,7 @@ static void aspeed_gpio_init(Object *obj)
>       }
>   
>       for (int i = 0; i < agc->nr_gpio_sets; i++) {
> -        char *name = g_strdup_printf("gpio-set[%d]", i);
> +        g_autofree char *name = g_strdup_printf("gpio-set[%d]", i);
>           object_property_add(obj, name, "uint32", aspeed_gpio_get_set,
>           aspeed_gpio_set_set, NULL, NULL);
>       }

Reviewed-by: Cédric Le Goater <clg@redhat.com>

Thanks,

C.

[PATCH 4/4] tests/qtest/iommu-smmuv3-test: Free QPCIDevice

[Peter Maydell]

The QPCIDevice we get via qpci_device_foreach() is allocated
memory, and we need to g_free() it after use.

This fixes asan leaks like this:

Direct leak of 64 byte(s) in 1 object(s) allocated from:
    #0 0x622a5f16913d in calloc (/home/pm215/qemu/build/arm-clang/tests/qtest/iommu-smmuv3-test+0x1d413d) (BuildId: bc598be1f4ad6d1a9a600c55aeef36108bdb6a04)
    #1 0x73ee41c0f771 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x63771) (BuildId: 116e142b9b52c8a4dfd403e759e71ab8f95d8bb3)
    #2 0x622a5f1d4cec in qpci_device_find /home/pm215/qemu/build/arm-clang/../../tests/qtest/libqos/pci.c:82:11
    #3 0x622a5f1d4cec in qpci_device_foreach /home/pm215/qemu/build/arm-clang/../../tests/qtest/libqos/pci.c:34:19
    #4 0x622a5f23cc73 in setup_qtest_pci_device /home/pm215/qemu/build/arm-clang/../../tests/qtest/iommu-smmuv3-test.c:45:5
    #5 0x622a5f23cc73 in run_smmuv3_translation /home/pm215/qemu/build/arm-clang/../../tests/qtest/iommu-smmuv3-test.c:74:11


Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 tests/qtest/iommu-smmuv3-test.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/qtest/iommu-smmuv3-test.c b/tests/qtest/iommu-smmuv3-test.c
index cced49a9b6..dae9821b92 100644
--- a/tests/qtest/iommu-smmuv3-test.c
+++ b/tests/qtest/iommu-smmuv3-test.c
@@ -77,6 +77,7 @@ static void run_smmuv3_translation(const QSMMUTestConfig *cfg)
     g_test_message("### SMMUv3 translation mode=%d sec_sid=%d ###",
                    cfg->trans_mode, cfg->sec_sid);
     qsmmu_run_translation_case(qts, dev, bar, VIRT_SMMU_BASE, cfg);
+    g_free(dev);
     qtest_quit(qts);
 }
 
-- 
2.43.0

Re: [PATCH 4/4] tests/qtest/iommu-smmuv3-test: Free QPCIDevice

[Fabiano Rosas]

Peter Maydell <peter.maydell@linaro.org> writes:

> The QPCIDevice we get via qpci_device_foreach() is allocated
> memory, and we need to g_free() it after use.
>
> This fixes asan leaks like this:
>
> Direct leak of 64 byte(s) in 1 object(s) allocated from:
>     #0 0x622a5f16913d in calloc (/home/pm215/qemu/build/arm-clang/tests/qtest/iommu-smmuv3-test+0x1d413d) (BuildId: bc598be1f4ad6d1a9a600c55aeef36108bdb6a04)
>     #1 0x73ee41c0f771 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x63771) (BuildId: 116e142b9b52c8a4dfd403e759e71ab8f95d8bb3)
>     #2 0x622a5f1d4cec in qpci_device_find /home/pm215/qemu/build/arm-clang/../../tests/qtest/libqos/pci.c:82:11
>     #3 0x622a5f1d4cec in qpci_device_foreach /home/pm215/qemu/build/arm-clang/../../tests/qtest/libqos/pci.c:34:19
>     #4 0x622a5f23cc73 in setup_qtest_pci_device /home/pm215/qemu/build/arm-clang/../../tests/qtest/iommu-smmuv3-test.c:45:5
>     #5 0x622a5f23cc73 in run_smmuv3_translation /home/pm215/qemu/build/arm-clang/../../tests/qtest/iommu-smmuv3-test.c:74:11
>
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>  tests/qtest/iommu-smmuv3-test.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/tests/qtest/iommu-smmuv3-test.c b/tests/qtest/iommu-smmuv3-test.c
> index cced49a9b6..dae9821b92 100644
> --- a/tests/qtest/iommu-smmuv3-test.c
> +++ b/tests/qtest/iommu-smmuv3-test.c
> @@ -77,6 +77,7 @@ static void run_smmuv3_translation(const QSMMUTestConfig *cfg)
>      g_test_message("### SMMUv3 translation mode=%d sec_sid=%d ###",
>                     cfg->trans_mode, cfg->sec_sid);
>      qsmmu_run_translation_case(qts, dev, bar, VIRT_SMMU_BASE, cfg);
> +    g_free(dev);
>      qtest_quit(qts);
>  }

Reviewed-by: Fabiano Rosas <farosas@suse.de>

Re: [PATCH 0/4] arm: Fix some memory leaks

[Fabiano Rosas]

Peter Maydell <peter.maydell@linaro.org> writes:

> This patchset fixes a couple of minor memory leaks I found by running
> "make check" for the arm targets with the clang leak sanitizer enabled.
>
> The first two patches are necessary because there are a few leaks
> that are either not interesting to fix or which are not in our code,
> and which otherwise clutter up the logs with failure messages.
> We have a suppressions-file already, but it's in the scripts/oss-fuzz
> subdirectory, so I move it out as it's more widely useful than that,
> and add some more suppression lines to it.
>
> Patches 3 and 4 are the actual leak fixes, which are straightforward.
>
> This gets me what would be a clean run, except that there's something
> wrong with the refcounting of qio channel objects in the chardev code,
> which results in variously use-after-free, leak, or assertion failures
> when running the vhost-user tests in qos-test. I'm still looking at
> those, but in the meantime posting this series gives me something to
> point at as part of the repro instructions for those errors.
>

Looks like something I worked on in the past. It seems this fell through
the cracks:

https://lore.kernel.org/r/20250515222014.4161-1-farosas@suse.de

Re: [PATCH 0/4] arm: Fix some memory leaks

[Peter Maydell]

On Fri, 27 Feb 2026 at 18:52, Fabiano Rosas <farosas@suse.de> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > This patchset fixes a couple of minor memory leaks I found by running
> > "make check" for the arm targets with the clang leak sanitizer enabled.
> >
> > The first two patches are necessary because there are a few leaks
> > that are either not interesting to fix or which are not in our code,
> > and which otherwise clutter up the logs with failure messages.
> > We have a suppressions-file already, but it's in the scripts/oss-fuzz
> > subdirectory, so I move it out as it's more widely useful than that,
> > and add some more suppression lines to it.
> >
> > Patches 3 and 4 are the actual leak fixes, which are straightforward.
> >
> > This gets me what would be a clean run, except that there's something
> > wrong with the refcounting of qio channel objects in the chardev code,
> > which results in variously use-after-free, leak, or assertion failures
> > when running the vhost-user tests in qos-test. I'm still looking at
> > those, but in the meantime posting this series gives me something to
> > point at as part of the repro instructions for those errors.
> >
>
> Looks like something I worked on in the past. It seems this fell through
> the cracks:
>
> https://lore.kernel.org/r/20250515222014.4161-1-farosas@suse.de

Yeah, that looks very familiar. The way it only reproduces in
a loaded system is fantastically annoying -- it relatively
reliably falls over in a full "make -j20 check" run for me
but I had massive trouble trying to get anything to reliably
repro in a useful way...

The vhost-user-test also seems to be doing some odd things itself:
for instance the wait_for_fds() function assumes there is RAM at
0x0, but we run the test on the arm virt board where RAM doesn't
start at that address. Presumably we should either make the test
handle that or else restrict it to not run on boards where it
will never work.

I'll have a go with your patches and see if I still see issues.

-- PMM