Re: [Libguestfs] [xml] Why does libxml2 limit port numbers to 999, 999, 999?
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 > > 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 ___ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] [xml] Why does libxml2 limit port numbers to 999, 999, 999?
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 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. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] [xml] Why does libxml2 limit port numbers to 999, 999, 999?
On Oct 17, 2020, at 12:24 , Richard W.M. Jones via xml 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 > 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. Nick ___ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs