[Libguestfs] [xml] Why does libxml2 limit port numbers to 999, 999, 999?
Stefano Garzarella
sgarzare at redhat.com
Mon Oct 19 07:34:59 UTC 2020
Hi Richard,
On Sat, Oct 17, 2020 at 07:03:22PM +0100, Richard W.M. Jones wrote:
> On Sat, Oct 17, 2020 at 06:32:18PM +0200, Nick Wellnhofer wrote:
> > On Oct 17, 2020, at 12:24 , Richard W.M. Jones via xml <xml at gnome.org> wrote:
> > > It seems like libxml2 chose to do this for convenience rather than
> > > correctness.
> >
> > Yes, this is an arbitrary limit introduced to avoid integer overflow.
> >
> > > I think it should accept port numbers at least up to
> > > signed int (the type used to store port numbers), and give an error if
> > > the port number overflows.
> >
> > This is fixed now: https://gitlab.gnome.org/GNOME/libxml2/-/commit/b46016b8705b041c0678dd45e445dc73674b75d0
>
> Oh that's great thanks. Can confirm it works for me (up to INT_MAX).
>
> > > Also could the uri->port field be changed to unsigned int without
> > > breaking ABI?
> >
> > It’s a public struct member, so strictly speaking, no. But the risk
> > to break stuff seems low.
>
> This would allow us to go to 2^32-1 which is the full range of
> port numbers for AF_VSOCK.
>
> ** Stefano ** Do you think this is worth it for the vsock protocol?
> I'm not sure how often huge port numbers are used - I only hit this
> bug because I was choosing random port numbers in a test case.
In the 99% of cases the remote port is usually chosen by the user and very
often they are similar to TCP/UDP ones, so I guess it's not a problem.
The problem can happen if the remote service is listen on a random port
chosen by the kernel (if the user do bind() with VMADDR_PORT_ANY).
This port is randomly generated in interval [1024, UINT32_MAX].
>From the vsock code seems that in this case 2^32 is the maximum random port
generated, instead in case the port is chosen by the user, the maximum
is 2^32 - 1.
I'll check if the interval for random port is right.
Stefano
More information about the Libguestfs
mailing list