File e6f96bd1-CVE-2025-47711.patch of Package nbdkit.38731

commit e6f96bd1b77c0cc927ce6aeff650b52238304f39
Author: Eric Blake <eblake@redhat.com>
Date:   Tue Apr 22 17:01:12 2025 -0500

    server: Fix off-by-one for maximum block_status length [CVE-2025-47711]
    
    There has been an off-by-one bug in the code for .extents since the
    introduction of that callback.  Remember, internally the code allows
    plugins to report on extents with 64-bit lengths, but the protocol
    only supports 32-bit block status calls (nbdkit will need to create
    plugin version 3 before it can support NBD's newer 64-bit block
    status).  As such, the server loop intentionally truncates a plugin's
    large extent to 2**32-1 bytes.  But in the process of checking whether
    the loop should exit early, or if any additional extents should be
    reported to the client, the server used 'pos > offset+count' instead
    of >=, which is one byte too far.  If the client has requested exactly
    2**32-1 bytes, and the plugin's first extent has that same length, the
    code erroneously proceeds on to the plugin's second extent.  Worse, if
    the plugin's first extent has 2**32 bytes or more, it was truncated to
    2**31-1 bytes, but not completely handled, and the failure to exit the
    loop early means that the server then fails the assertion:
    
    nbdkit: ../../server/protocol.c:505: extents_to_block_descriptors:
    Assertion `e.length <= length' failed.
    
    The single-byte fix addresses both symptoms, while the added test
    demonstrates both when run on older nbdkit (the protocol violation
    when the plugin returns 2**32-1 bytes in the first extent, and the
    assertion failure when the plugin returns 2**32 or more bytes in the
    first extent).
    
    The problem can only be triggered by a client request for 2**32-1
    bytes; anything smaller is immune.  The problem also does not occur
    for plugins that do not return extents information beyond the client's
    request, or if the first extent is smaller than the client's request.
    
    The ability to cause the server to die from an assertion failure can
    be used as a denial of service attack against other clients.
    Mitigations: if you require the use of TLS, then you can ensure that
    you only have trusted clients that won't trigger a block status call
    of length 2**32-1 bytes.  Also, you can use "--filter=blocksize-policy
    blocksize-minimum=512" to reject block status attempts from clients
    that are not sector-aligned.
    
    Fixes: 26455d45 ('server: protocol: Implement Block Status "base:allocation".', v1.11.10)
    Reported-by: Nikolay Ivanets <stenavin@gmail.com>
    Signed-off-by: Eric Blake <eblake@redhat.com>
    Message-ID: <20250423211953.GR1450@redhat.com>
    Reviewed-by: Richard W.M. Jones <rjones@redhat.com>

Index: nbdkit-1.36.5/server/protocol.c
===================================================================
--- nbdkit-1.36.5.orig/server/protocol.c
+++ nbdkit-1.36.5/server/protocol.c
@@ -493,7 +493,7 @@ extents_to_block_descriptors (struct nbd
       (*nr_blocks)++;
 
       pos += length;
-      if (pos > offset + count) /* this must be the last block */
+      if (pos >= offset + count) /* this must be the last block */
         break;
 
       /* If we reach here then we must have consumed this whole