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 <[email protected]>
---
Changes in v4:
- Patch "tests: Avoid sprintf() with '%.6f'" now has an improved title
  ("tests: Clean up double comparisons to avoid compiler warning") and
  message written by Markus Armbruster.
- Link to v3: 
https://lore.kernel.org/qemu-devel/[email protected]

Changes in v3:
- Changed to avoid sprintf() with "%.6f" in tests.
- Replaced the message of patch "vfio/pci: Grow buffer in
  vfio_pci_host_match()" with a improved version by Alex Williamson.
- Link to v2: 
https://lore.kernel.org/qemu-devel/[email protected]

Changes in v2:
- Rebased.
- Changed to use g_strdup_printf() in patch
  "contrib/elf2dmp: Grow PDB URL buffer".
- Link to v1: 
https://lore.kernel.org/qemu-devel/[email protected]

---
Akihiko Odaki (4):
      contrib/elf2dmp: Grow PDB URL buffer
      vfio/pci: Grow buffer in vfio_pci_host_match()
      tests: Clean up double comparisons to avoid compiler warning
      meson: Add -Wformat-overflow=2

 meson.build                              |  1 +
 contrib/elf2dmp/main.c                   | 32 +++++++++++++++-----------------
 hw/vfio/pci.c                            |  2 +-
 tests/unit/test-qobject-input-visitor.c  |  8 ++------
 tests/unit/test-qobject-output-visitor.c |  7 ++-----
 5 files changed, 21 insertions(+), 29 deletions(-)
---
base-commit: afe653676dc6dfd49f0390239ff90b2f0052c2b8
change-id: 20260125-nvme-b4661e0a409e

Best regards,
--  
Akihiko Odaki <[email protected]>


Reply via email to