[PATCH net] net: xt_recent: fix (increase) ipv6 literal buffer length

[PATCH net] net: xt_recent: fix (increase) ipv6 literal buffer length

[Maciej Żenczykowski]

From: Maciej Żenczykowski <zenczykowski@gmail.com>

IPv4 in IPv6 is supported by in6_pton
(this is useful with DNS64/NAT64 networks for example):

  # echo +aaaa:bbbb:cccc:dddd:eeee:ffff:1.2.3.4 > /proc/self/net/xt_recent/DEFAULT
  # cat /proc/self/net/xt_recent/DEFAULT
  src=aaaa:bbbb:cccc:dddd:eeee:ffff:0102:0304 ttl: 0 last_seen: 9733848829 oldest_pkt: 1 9733848829

but the provided buffer is too short:

  # echo +aaaa:bbbb:cccc:dddd:eeee:ffff:255.255.255.255 > /proc/self/net/xt_recent/DEFAULT
  -bash: echo: write error: Invalid argument

Cc: Jan Engelhardt <jengelh@medozas.de>
Cc: Patrick McHardy <kaber@trash.net>
Fixes: 079aa88fe717 ("netfilter: xt_recent: IPv6 support")
Signed-off-by: Maciej Żenczykowski <zenczykowski@gmail.com>
---
 net/netfilter/xt_recent.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/netfilter/xt_recent.c b/net/netfilter/xt_recent.c
index 7ddb9a78e3fc..ef93e0d3bee0 100644
--- a/net/netfilter/xt_recent.c
+++ b/net/netfilter/xt_recent.c
@@ -561,7 +561,7 @@ recent_mt_proc_write(struct file *file, const char __user *input,
 {
 	struct recent_table *t = pde_data(file_inode(file));
 	struct recent_entry *e;
-	char buf[sizeof("+b335:1d35:1e55:dead:c0de:1715:5afe:c0de")];
+	char buf[sizeof("+b335:1d35:1e55:dead:c0de:1715:255.255.255.255")];
 	const char *c = buf;
 	union nf_inet_addr addr = {};
 	u_int16_t family;
-- 
2.42.0.869.gea05f2083d-goog

Re: [PATCH net] net: xt_recent: fix (increase) ipv6 literal buffer length

[Jan Engelhardt]

On Saturday 2023-11-04 22:00, Maciej Żenczykowski wrote:
>
>IPv4 in IPv6 is supported by in6_pton [...]
>but the provided buffer is too short:

If in6_pton were to support tunnel traffic.. wait that sounds
unusual, and would require dst to be at least 20 bytes, which the 
function documentation contradicts.

As the RFCs make no precise name proposition

	(IPv6 Text Representation, third alternative,
	IPv4 "decimal value" of the "four low-order 8-bit pieces")

so let's just call it

	"low-32-bit dot-decimal representation"

which should avoid the tunnel term.

Re: [PATCH net] net: xt_recent: fix (increase) ipv6 literal buffer length

[Maciej Żenczykowski]

On Sun, Nov 5, 2023 at 12:08 AM Jan Engelhardt <jengelh@inai.de> wrote:
>
>
> On Saturday 2023-11-04 22:00, Maciej Żenczykowski wrote:
> >
> >IPv4 in IPv6 is supported by in6_pton [...]
> >but the provided buffer is too short:
>
> If in6_pton were to support tunnel traffic.. wait that sounds
> unusual, and would require dst to be at least 20 bytes, which the
> function documentation contradicts.
>
> As the RFCs make no precise name proposition
>
>         (IPv6 Text Representation, third alternative,
>         IPv4 "decimal value" of the "four low-order 8-bit pieces")
>
> so let's just call it
>
>         "low-32-bit dot-decimal representation"
>
> which should avoid the tunnel term.

Resent [ https://patchwork.kernel.org/project/netdevbpf/patch/20231105195600.522779-1-maze@google.com/
], hopefully this is better.
Also:
- used your (Jan's) new email in the CC.
- changed net to netfilter in the commit title
(but as it is such a trivial bug fix, it does still feel like it
should go straight into net/main... rather than via netfilter repos)

Cheers,
Maciej