]> git.ipfire.org Git - thirdparty/haproxy.git/commitdiff
BUG/MEDIUM: quic: fix datagram dropping on queueing failed
authorAmaury Denoyelle <adenoyelle@haproxy.com>
Thu, 24 Nov 2022 14:24:38 +0000 (15:24 +0100)
committerAmaury Denoyelle <adenoyelle@haproxy.com>
Thu, 24 Nov 2022 15:45:02 +0000 (16:45 +0100)
After reading a datagram, it is enqueud for the thread attached to the
DCID. This is done via quic_lstnr_dgram_dispatch() function. If this
step fails, we remove the datagram from the buffer of quic_receiver_buf.

This step is faulty because we use b_del() instead of b_sub(). If
quic_receiver_buf was not empty, we will remove content from another
datagram while leaving the content of the last read datagram. This
probably produces valid datagram dropping and may even result in crash.

As stated, this bug can only happen if qc_lstnr_dgram_dispatch() fails
which happen on two occaions :
* on quic_dgram allocation failure, which should be pretty rare
* on datagram labelled as invalid for QUIC protocol. This may happen
  more frequently depending on the network conditions. Thus, this bug
  has been labelled as a medium one.

This should be backported up to 2.6.

src/quic_sock.c

index a8da3cb7b1f6abb9fc3d6f8fd626f96672537bdc..2ac60eac715e889d99e0208b8de9e632887163bb 100644 (file)
@@ -436,7 +436,7 @@ void quic_sock_fd_iocb(int fd)
        if (!quic_lstnr_dgram_dispatch(dgram_buf, ret, l, &saddr, &daddr,
                                       new_dgram, &rxbuf->dgram_list)) {
                /* If wrong, consume this datagram */
-               b_del(buf, ret);
+               b_sub(buf, ret);
        }
        new_dgram = NULL;
        if (--max_dgrams > 0)