lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZQA0VxB1hVqH2o/9@debian>
Date: Tue, 12 Sep 2023 11:50:15 +0200
From: Guillaume Nault <gnault@...hat.com>
To: Tj <linux@....tj>
Cc: netdev@...r.kernel.org, David Ahern <dsahern@...nel.org>
Subject: Re: IPv6 address scope not set to operator-configured value

[ Cc: David Ahern, who might have an opinion on this]

On Fri, Sep 08, 2023 at 06:02:00PM +0100, Tj wrote:
> Using iproute2 and kernel v6.5.0 with Debian 12 Bookworm amd64
> (tested also with v6.136 nixos) setting scope on an IPv6 fails
> silently with no indications as to why and the address is configured
> with what appears to be a scope based on the prefix (usually 0 but
> for fe80::/16 addresses scope is set to 253). Doesn't matter whether
> using scope names (from /etc/iproute2/rt_scopes) or numbers. Similar
> command for IPv4 succeeds.

I don't think we could let the user manually set the scope of IPv6
addresses. As you realised, with IPv6, the scope is automatically
derived from the address.

I had a patch to reject IPv6 netlink commands that have a scope
attribute. I've never sent it though, as I was affraid to break
existing users. But now that I read your message, I feel that maybe
we'd better explicitely reject such commands instead of silently
ignoring the scope. That'd avoid this kind of misunderstanding.

If anyone feels we should reject the scope attribute when adding
IPv6 routes or addresses, just let me know and I'll send this patch.

> ip address add fddc::2/64 scope 200 dev PUBLIC
> ip -N -6 address show dev PUBLIC
> ...
> inet6 fddc::2/64 scope 0
> 
> I used `gdb` to trace this expecting somehow the scope was not being read correctly but it is:
> 
> 2577            if (!scoped && cmd != RTM_DELADDR)
> (gdb) p scoped
> $22 = <optimized out>
> (gdb) p cmd
> $23 = <optimized out>
> (gdb) n
> 2580            req.ifa.ifa_index = ll_name_to_index(d);
> (gdb) p req.ifa.ifa_scope
> $24 = 200 '\310'
> ...
> 2607            if (echo_request)
> (gdb) n
> 2610                    ret = rtnl_talk(&rth, &req.n, NULL);
> (gdb) p req.n
> $25 = {nlmsg_len = 64, nlmsg_type = 20, nlmsg_flags = 1537, nlmsg_seq = 0, nlmsg_pid = 0}
> (gdb) p rth
> $26 = {fd = 3, local = {nl_family = 16, nl_pad = 0, nl_pid = 2381950, nl_groups = 0}, peer = {nl_family = 0, nl_pad = 0, nl_pid = 0, nl_groups = 0}, seq = 1694191286,
>   dump = 0, proto = 0, dump_fp = 0x0, flags = 4}
> (gdb) s
> rtnl_talk (rtnl=0x5555555f7020 <rth>, n=n@...ry=0x7fffffffe140, answer=answer@...ry=0x0) at ./lib/libnetlink.c:1170
> 1170    {
> ...
> ipaddr_modify (cmd=<optimized out>, flags=<optimized out>, argc=<optimized out>, argv=0x7fffffffe478) at ./ip/ipaddress.c:2612
> 2612            if (ret)
> (gdb) p ret
> $27 = 0
> 
> 
> 
> 
> 
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ