On Mon, Dec 16, 2024 at 09:32:56AM -0500, Nikolaos Chatzikonstantinou wrote: > Hello list, > > In src/lib/libc/net/inet_net_pton.c:inet_net_pton_ipv4 on branch > master, there appears to be an issue of underwriting the buffer. Let > me explain. > > The IPv4 format allows for addresses such as 10/8, which is shorthand > for the IP 10.0.0.0 with 16777216 addresses in 256 blocks (e.g. > RFC4632 table in 3.1). > > The outputs are as follows: > > 1) A buffer 'dst' with the 4 IPv4 octets in network order. > 2) The number of bits of the subnet mask (return value of function). > > The issue is that it will not write past the subnet mask. Thus src = > "10/8" becomes dst = [0A] [??] [??] [??], and src = "10/9" becomes > dst = [0A] [00] [??] [??] where ?? means that the dst octet retains > its original value before calling inet_net_pton_ipv4. > > It seems then that the semantics of the function are such that to know > which octets were written to, one must calculate n = ceil(bits/8.0), > which means that octet index 0 to n-1 were written to. > > This appears problematic to me. While the function can be used > correctly if a user remembers to calculate n = ceil(bits/8.0), it is > not documented in the function (but see below for the man page > comment). The fix that I suggest is that a memset(dst, 0, size); is > done before anything else. > > In the man page inet_net_pton(3) the following caution is found: > > >Caution: The dst field should be zeroed before calling inet_net_pton() as > >the function will only fill the number of bytes necessary to encode the > >network number in network byte order. > > I think it is better if the caution is removed, and instead the memset > is done regardless.
inet_net_pton is a somewhat standardized API. It behaves like this since the dark ages and it is something that wont get fixed unless you fix it in all OS (which I doubt will happen). -- :wq Claudio
