netdev - Regression in IPv6 autoconf, maybe "ipv6/addrconf: fix timing bug in tempaddr regen"

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-next>] [day] [month] [year] [list]

Message-ID: <4n64q633-94rr-401n-s779-pqp2q0599438@vanv.qr>
Date: Wed, 31 May 2023 11:20:44 +0200 (CEST)
From: Jan Engelhardt <jengelh@...i.de>
To: Sam Edwards <cfsworks@...il.com>
cc: Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, 
    "David S. Miller" <davem@...emloft.net>
Subject: Regression in IPv6 autoconf, maybe "ipv6/addrconf: fix timing bug
 in tempaddr regen"

Greetings.

I am observing that between kernel 5.19 and 6.0, a change was introduced 
that makes the system just stop generating IPv6 Privacy Addresses after 
some time. With regeneration parameters in sysctl (see below) reduced to 
almost the minimum supported by Linux (that would be 900s), the 
timeframe to reproduction is somewhat elongated but managable (7 hours), 
so I have not completely bisected it down yet. Based on the shortlog for 
inbetween those two kernel versions, a glance at the shortlog leads me 
to a hypothesis that this commit could be the culprit:

commit 778964f2fdf05e5d2e6ca9bc3f450b3db454ba9c
Author: Sam Edwards <cfsworks@...il.com>
Date:   Thu Jun 23 12:11:04 2022 -0600

    ipv6/addrconf: fix timing bug in tempaddr regen
    
    The addrconf_verify_rtnl() function uses a big if/elseif/elseif/... block
    to categorize each address by what type of attention it needs.  An
    about-to-expire (RFC 4941) temporary address is one such category, but the
    previous elseif branch catches addresses that have already run out their
    prefered_lft.  This means that if addrconf_verify_rtnl() fails to run in
    the necessary time window (i.e. REGEN_ADVANCE time units before the end of
    the prefered_lft), the temporary address will never be regenerated, and no
    temporary addresses will be available until each one's valid_lft runs out
    and manage_tempaddrs() begins anew.
    [...]

sysctl config:
net.ipv4.conf.default.forwarding=1
net.ipv6.conf.default.use_tempaddr=2
net.ipv6.conf.default.router_solicitation_interval=60
net.ipv6.conf.default.max_addresses=1500
net.ipv4.conf.all.forwarding=1
net.ipv6.conf.all.use_tempaddr=2
net.ipv6.conf.all.router_solicitation_interval=60
net.ipv6.conf.all.max_addresses=1600
net.ipv6.conf.all.temp_prefered_lft=1500
net.ipv6.conf.ge0.max_addresses=1600
net.ipv6.conf.ge0.temp_prefered_lft=1500