The parameter `max_pkts` was not checked in the recvmsg() implementation
of vquic_recv_packets() as the packter counter was never increased. This
led to the loop running until an EAGAIN was encountered. Which, in any
real case scenario, does no harm as long as libcurl is ingesting packets
faster than a server is able to send them.
However on a slow device and a fast network this could happen and allow
a denial of serice.
Not a real regression as the vulnerable code has never been released.
libcurl 8.16.0 does not have this bug.
Closes #19186
msg.msg_name, msg.msg_namelen, 0, userp);
if(result)
goto out;
+ pkts += (nread + gso_size - 1) / gso_size;
}
out: