valgrind 3.21.0 warns by default on realloc with size zero (I am just about to publish an article about that). From the NEWS file:

  - Performs checks for the use of realloc with a size of zero.
    This is non-portable and a source of errors. If memcheck
    detects such a usage it will generate an error
      realloc() with size 0
    followed by the usual callstacks.
    A switch has been added to allow this to be turned off:
      --show-realloc-size-zero=yes|no [yes]

This was done because in the new C23 standard realloc with size zero in undefined behavior.

Could you try running with --show-realloc-size-zero=no ?

But even if that works then the following
Error:
  unknown error code 14

Memcheck: the 'impossible' happened:
   unknown error code in mc_eq_Error

Might be a real bug in valgrind. It is certainly not supposed to crash.

Thanks, adding `--show-realloc-size-zero=no` helps:

==24812== Memcheck, a memory error detector
==24812== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==24812== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==24812== Command: oscap oval eval rpmverifyfile.oval.xml
==24812== 
Definition oval:x:def:1: true
Evaluation done.
==24812== 
==24812== HEAP SUMMARY:
==24812==     in use at exit: 479 bytes in 14 blocks
==24812==   total heap usage: 270,994 allocs, 270,980 frees, 31,011,496 bytes allocated
==24812== 
==24812== LEAK SUMMARY:
==24812==    definitely lost: 0 bytes in 0 blocks
==24812==    indirectly lost: 0 bytes in 0 blocks
==24812==      possibly lost: 0 bytes in 0 blocks
==24812==    still reachable: 479 bytes in 14 blocks
==24812==         suppressed: 0 bytes in 0 blocks
==24812== Reachable blocks (those to which a pointer was found) are not shown.
==24812== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==24812== 
==24812== For lists of detected and suppressed errors, rerun with: -s
==24812== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Maybe we should change the valgrind default on glibc systems? For backwards compatibility, I think we need to stick to the current realloc behavior indefinitely.

(In reply to Matus Marhefka from comment #3)
> Thanks, adding `--show-realloc-size-zero=no` helps:

Thanks for testing that. I'll keep this bug open till I understand why the error/crash happens with the default --show-realloc-size-zero=yes.

(In reply to Florian Weimer from comment #4)
> Maybe we should change the valgrind default on glibc systems? For backwards
> compatibility, I think we need to stick to the current realloc behavior
> indefinitely.

Note that the actual behavior didn't change, it still defaults to what current glibc systems do (on Fedora/RHEL at least). But it does produce this extra warning by default now because it is likely a bug (or at least unportable code). But 3.21.0 does make it possible to also change the behavior, from NEWS again:

* The behaviour of realloc with a size of zero can now
  be changed for tools that intercept malloc. Those
  tools are memcheck, helgrind, drd, massif and dhat.
  Realloc implementations generally do one of two things
     - free the memory like free() and return NULL
       (GNU libc and ptmalloc).
     - either free the memory and then allocate a
       minimum sized block or just return the
       original pointer. Return NULL if the
       allocation of the minimum sized block fails
       (jemalloc, musl, snmalloc, Solaris, macOS).
  When Valgrind is configured and built it will
  try to match the OS and libc behaviour. However
  if you are using a non-default library to replace
  malloc and family (e.g., musl on a glibc Linux or
  tcmalloc on FreeBSD) then you can use a command line
  option to change the behaviour of Valgrind:
    --realloc-zero-bytes-frees=yes|no [yes on Linux glibc, no otherwise]

Found the bug in valgrind, the MC_(eq_Error) function didn't handle the new Err_ReallocSizeZero error (that function looks to see if an error is similar to a previous encountered one):

diff --git a/memcheck/mc_errors.c b/memcheck/mc_errors.c
index 00d6ec301..65210a220 100644
--- a/memcheck/mc_errors.c
+++ b/memcheck/mc_errors.c
@@ -1041,6 +1041,7 @@ Bool MC_(eq_Error) ( VgRes res, const Error* e1, const Error* e2 )
       case Err_IllegalMempool:
       case Err_Overlap:
       case Err_Cond:
+      case Err_ReallocSizeZero:
          return True;
 
       case Err_FishyValue:

Will discuss upstream and probably backport this fix if approved.

BTW. I think the code in openscap-scanner that valgrind now warns against should be rewritten as follows:

--- ./src/OVAL/probes/SEAP/seap-packet.c	2023-01-26 14:13:08.000000000 +0100
+++ ./src/OVAL/probes/SEAP/seap-packet.c	2023-06-01 13:09:35.458020809 +0200
@@ -206,9 +206,19 @@
         _A(attr_i >= (SEXP_list_length (sexp_msg) - 4)/2);
 
         seap_msg->attrs_cnt = attr_i;
-        void *new_attrs = realloc(seap_msg->attrs, sizeof(SEAP_attr_t) * seap_msg->attrs_cnt);
-        if (new_attrs != NULL || seap_msg->attrs_cnt == 0)
-                seap_msg->attrs = new_attrs;
+        if (seap_msg->attrs_cnt == 0) {
+                free (seap_msg->attrs);
+                seap_msg->attrs = NULL;
+        } else {
+                void *new_attrs = realloc(seap_msg->attrs, sizeof(SEAP_attr_t) * seap_msg->attrs_cnt);
+                if (new_attrs != NULL) {
+                        seap_msg->attrs = new_attrs;
+                } else {
+                        free (seap_msg->attrs);
+                        seap_msg->attrs = NULL;
+                        return (SEAP_ENOMEM);
+                }
+        }
         seap_msg->sexp = SEXP_list_last (sexp_msg);
 
         return (0);

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (valgrind bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:6395