nvme-ns has a use-after-free of a formatted string, so fix it by
embedding a fixed-length buffer to the object. Embedding a buffer lets
me avoid a chore to add a function to call g_free().

But I don't want to worry about a buffer overflow, so let the compiler
check that the buffer won't overflow; C is so restrictive that it cannot
enforce the existence of g_free(). Compilers can check the length of
formatted string on the other hand.

Then GCC started complaining about buffer overflow, so let's treat them.
Fortunately, the potential buffer overflows it detected are not
user-facing or very subtle. Treating them by growing buffers can improve
robustness with practically no cost.

Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
---
Akihiko Odaki (5):
      contrib/elf2dmp: Grow PDB URL buffer
      vfio/pci: Grow buffer in vfio_pci_host_match()
      tests: Grow buffers for double string
      meson: Add -Wformat-overflow=2
      hw/nvme: Fix bootindex suffix use-after-free

 meson.build                              |  1 +
 hw/nvme/nvme.h                           |  1 +
 contrib/elf2dmp/main.c                   | 27 ++++++++++-----------------
 hw/nvme/ns.c                             |  7 +++----
 hw/vfio/pci.c                            |  2 +-
 tests/unit/test-qobject-input-visitor.c  |  2 +-
 tests/unit/test-qobject-output-visitor.c |  2 +-
 7 files changed, 18 insertions(+), 24 deletions(-)
---
base-commit: d03c3e522eb0696dcfc9c2cf643431eaaf51ca0f
change-id: 20260125-nvme-b4661e0a409e

Best regards,
--  
Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>

On Sun, 25 Jan 2026, Akihiko Odaki wrote:
> nvme-ns has a use-after-free of a formatted string, so fix it by
> embedding a fixed-length buffer to the object. Embedding a buffer lets
> me avoid a chore to add a function to call g_free().

Isn't that where g_autofree would help?

> But I don't want to worry about a buffer overflow, so let the compiler
> check that the buffer won't overflow; C is so restrictive that it cannot
> enforce the existence of g_free(). Compilers can check the length of
> formatted string on the other hand.
>
> Then GCC started complaining about buffer overflow, so let's treat them.
> Fortunately, the potential buffer overflows it detected are not
> user-facing or very subtle. Treating them by growing buffers can improve
> robustness with practically no cost.

This is useful but maybe there's a better fix for some of these than 
arbitrarily enlarging buffers but I don't care enough about these to 
judge.

Regards,
BALATON Zoltan

> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
> ---
> Akihiko Odaki (5):
>      contrib/elf2dmp: Grow PDB URL buffer
>      vfio/pci: Grow buffer in vfio_pci_host_match()
>      tests: Grow buffers for double string
>      meson: Add -Wformat-overflow=2
>      hw/nvme: Fix bootindex suffix use-after-free
>
> meson.build                              |  1 +
> hw/nvme/nvme.h                           |  1 +
> contrib/elf2dmp/main.c                   | 27 ++++++++++-----------------
> hw/nvme/ns.c                             |  7 +++----
> hw/vfio/pci.c                            |  2 +-
> tests/unit/test-qobject-input-visitor.c  |  2 +-
> tests/unit/test-qobject-output-visitor.c |  2 +-
> 7 files changed, 18 insertions(+), 24 deletions(-)
> ---
> base-commit: d03c3e522eb0696dcfc9c2cf643431eaaf51ca0f
> change-id: 20260125-nvme-b4661e0a409e
>
> Best regards,
> --
> Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
>
>
>

On 2026/01/25 20:55, BALATON Zoltan wrote:
> On Sun, 25 Jan 2026, Akihiko Odaki wrote:
>> nvme-ns has a use-after-free of a formatted string, so fix it by
>> embedding a fixed-length buffer to the object. Embedding a buffer lets
>> me avoid a chore to add a function to call g_free().
> 
> Isn't that where g_autofree would help?

Unfortunately no. It helps only if the lifetime is bound to a scope. In 
this case, the lifetime is bound to an object.

> 
>> But I don't want to worry about a buffer overflow, so let the compiler
>> check that the buffer won't overflow; C is so restrictive that it cannot
>> enforce the existence of g_free(). Compilers can check the length of
>> formatted string on the other hand.
>>
>> Then GCC started complaining about buffer overflow, so let's treat them.
>> Fortunately, the potential buffer overflows it detected are not
>> user-facing or very subtle. Treating them by growing buffers can improve
>> robustness with practically no cost.
> 
> This is useful but maybe there's a better fix for some of these than 
> arbitrarily enlarging buffers but I don't care enough about these to judge.

They can be fixed with g_autofree. I think either enlarging buffers or 
using g_autofree is fine; differences between them are insignificant.

Regards,
Akihiko Odaki