Re: [PATCH] rxrpc/proc: size address buffers for %pISpc output

From: Anderson Nascimento

Date: Mon Apr 06 2026 - 00:14:28 EST



On 4/6/26 3:10 AM, Pengpeng Hou wrote:
Hi,

Yes. My original changelog example was too loose, and your quick test is
right for a fully expanded plain IPv6 form such as

[ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff]:65535

That form is only 47 visible characters, so it fits in the current
char[50] buffers.

The reason I still think the bug is real is the current %pISpc
implementation in lib/vsprintf.c.

For AF_INET6, %pISpc goes through ip6_addr_string_sa(), and the compressed
path uses ip6_compressed_string(). That helper switches to a dotted-quad
tail not only for v4mapped addresses, but also for ISATAP addresses:

useIPv4 = ipv6_addr_v4mapped(&in6) || ipv6_addr_is_isatap(&in6);

So a current-tree case such as

[ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535

is possible. That string is 50 visible characters, i.e. 51 bytes
including the trailing NUL, which does not fit in the existing char[50]
buffers used by the rxrpc procfs helpers.

So I agree the example in my changelog should be corrected, but I do not
think the underlying bug goes away. The claim should be framed around the
ISATAP case rather than the plain IPv6 or mapped-v4 examples I used
originally.

If that makes sense, I can resend with the changelog corrected to cite the
actual maximum case explicitly.

Thanks,
Pengpeng

Thanks! I confirm the ISATAP case really triggers the issue. It ends up writing 51 bytes, including the NULL byte.

$ cat /proc/net/rxrpc/locals
Proto Local                                           Use Act RxQ
UDP   [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65   1   1   0
$

Regards,

Anderson Nascimento