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