[Libguestfs] [PATCH nbdkit] tls-fallback: Always call next open function

Richard W.M. Jones rjones at redhat.com
Wed Feb 16 21:25:51 UTC 2022


$ NBDKIT_GDB=1 ./nbdkit -fv --filter=tls-fallback memory 1m
(gdb) run

In a second window:

$ nbdinfo nbd://localhost

nbdkit crashes:

Thread 2 "nbdkit" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7584640 (LWP 1129108)]
0x000000000040625d in backend_block_size (c=0x0, minimum=0x7ffff7583944, preferred=0x7ffff7583940, maximum=0x7ffff758393c) at backend.c:428
428	  struct backend *b = c->b;

It turns out this is because the filter + plugin context chain is
incorrectly constructed.  There is only a single layer (for the
tls-fallback filter), and this has c->c_next == NULL.

We end up calling backend_block_size (c=NULL, ...) which causes the
crash above.

This is because the filter doesn't always call the next open function.
Changing the filter so it always calls it fixes the issue.
---
 filters/tls-fallback/tls-fallback.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/filters/tls-fallback/tls-fallback.c b/filters/tls-fallback/tls-fallback.c
index fab9e58b..4ea48d09 100644
--- a/filters/tls-fallback/tls-fallback.c
+++ b/filters/tls-fallback/tls-fallback.c
@@ -106,13 +106,10 @@ tls_fallback_open (nbdkit_next_open *next, nbdkit_context *nxdata,
                    int readonly,
                    const char *exportname, int is_tls)
 {
-  /* We do NOT want to call next() when insecure, because we don't
-   * know how long it will take.
-   */
-  if (!is_tls)
-    return &message; /* See NOT_TLS for this choice of handle */
   if (next (nxdata, readonly, exportname) == -1)
     return NULL;
+  if (!is_tls)
+    return &message; /* See NOT_TLS for this choice of handle */
   return NBDKIT_HANDLE_NOT_NEEDED;
 }
 
-- 
2.35.1




More information about the Libguestfs mailing list