netdev - Re: [PATCH net] ipv6 addrconf: fix bug where deleting a mngtmpaddr can create a new temporary address

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]

Date: Thu, 20 Jul 2023 09:35:20 -0600
From: David Ahern <dsahern@...nel.org>
To: Maciej Żenczykowski <maze@...gle.com>,
 Jiri Pirko <jiri@...nulli.us>
Cc: Jakub Kicinski <kuba@...nel.org>,
 Linux Network Development Mailing List <netdev@...r.kernel.org>,
 "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net] ipv6 addrconf: fix bug where deleting a mngtmpaddr
 can create a new temporary address

On 7/19/23 6:50 AM, Maciej Żenczykowski wrote:
> On Wed, Jul 19, 2023 at 8:47 AM Jiri Pirko <jiri@...nulli.us> wrote:
>> Wed, Jul 19, 2023 at 01:08:32AM CEST, kuba@...nel.org wrote:
>>> On Fri, 14 Jul 2023 08:49:55 -0600 David Ahern wrote:
>>>>> I did consider that and I couldn't quite convince myself that simply
>>>>> removing "|| list_empty()" from the if statement is necessarily correct
>>>>> (thus I went with the more obviously correct change).
>>>>>
>>>>> Are you convinced dropping the || list_empty would work?
>>>>> I assume it's there for some reason...
>>>>
>>>> I am hoping Jiri can recall why that part was added since it has the
>>>> side effect of adding an address on a delete which should not happen.
>>>
>>> Did we get stuck here? Jiri are you around to answer?
>>
>> Most probably a bug. But, this is 10 years since the change, I don't
>> remember much after this period. I didn't touch the code since :/
> 
> I *think* there might be cases where we want
>   addrconf_prefix_rcv_add_addr() -> manage_tempaddrs(create=false)
> to result in the creation of a new temporary address.
> 
> Basically the 'create' argument is a boolean with interpretation
> "was managetmpaddr added/created" as opposed to "should a temporary
> address be created"
> 
> Think:
> - RA comes in, we create the managetmpaddr, we call
> manage_tempaddrs(create=true), a temporary address gets created
> - someone comes in and deletes the temporary address (perhaps by hand?
> or it expires?)
> - another RA comes in, we don't create the managetmpaddr, since it
> already exists, we call manage_tempaddrs(create=false),
>   it notices there are no temporary addresses (by virtue of the ||
> list_empty check), and creates a new one.
> 
> Note that:
>   #define TEMP_VALID_LIFETIME (7*86400)
>   #define TEMP_PREFERRED_LIFETIME (86400)
> but these are tweakable...
>   $ cat /proc/sys/net/ipv6/conf/*/temp_valid_lft | uniq -c
>      37 604800
>   $ cat /proc/sys/net/ipv6/conf/*/temp_prefered_lft | uniq -c
>      37 86400
> so we could have these be < unsolicited RA frequency.
> (that's probably a bad idea for other reasons... but that's besides the point)
> 
> I have similar misgivings about  inet6_addr_modify() -> manage_tempaddrs()
> 
> if (was_managetempaddr || ifp->flags & IFA_F_MANAGETEMPADDR) {
> if (was_managetempaddr &&
> !(ifp->flags & IFA_F_MANAGETEMPADDR)) {
> cfg->valid_lft = 0;
> cfg->preferred_lft = 0;
> }
> manage_tempaddrs(ifp->idev, ifp, cfg->valid_lft,
> cfg->preferred_lft, !was_managetempaddr,
> jiffies);
> }
> 
> Here create == !was_managetempaddr,
> but technically we can have create == false, and yet valid/prefered != 0.
> 
> This will be the case if we have inet6_addr_modify() called where
> *both* the before and after state is a managetempaddr.
> Perhaps because the expiration was updated?
> 
> Anyway... because of the above I remain unconvinced that just removing
> '|| list_empty' is safe...

ok, want to resend this patch?