On Tue, Dec 17, 2024 at 7:14 AM Claudio Jeker <[email protected]> wrote: > > 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).
It can be fixed with a simple zeroing of 4 bytes. Why should it remain a "bug"? Regards, Nikolaos Chatzikonstantinou
