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@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/b46016b8705b041c0678dd45e445...
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