Altering use_tempaddr drops all IPv6 addresses

[Malcolm Scott]

$ uname -a
Linux expvr-alnilam 3.2.0-24-generic-pae #37-Ubuntu SMP Wed Apr 25 10:47:59 UTC 2012 i686 i686 i386 GNU/Linux

$ sysctl net.ipv6.conf.eth2.use_tempaddr
net.ipv6.conf.eth2.use_tempaddr = 2
# (as per the default /etc/sysctl.d/10-ipv6-privacy.conf in 12.04)

# Add a static IPv6 address:
$ sudo ip addr add 2001:470:9321:f003::1122/64 dev eth2

# Verify that it has been set up, and that a temporary address and a SLAAC address also exist:
$ ip -6 addr list dev eth2
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:470:9321:f003:74e3:aa2b:7ee5:c002/64 scope global temporary dynamic
       valid_lft 86393sec preferred_lft 14393sec
    inet6 2001:470:9321:f003:6c97:24ff:fe3f:263b/64 scope global dynamic
       valid_lft 86393sec preferred_lft 14393sec
    inet6 2001:470:9321:f003::1122/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::6c97:24ff:fe3f:263b/64 scope link
       valid_lft forever preferred_lft forever

# Disable RFC 4941 temporary addresses:
$ sudo sysctl net.ipv6.conf.eth2.use_tempaddr=0
net.ipv6.conf.eth2.use_tempaddr = 0

$ ip -6 addr list dev eth2
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 fe80::6c97:24ff:fe3f:263b/64 scope link tentative
       valid_lft forever preferred_lft forever

I.e. on setting use_tempaddr=0, _all_ IPv6 addresses are removed, including statically-configured and non-temporary SLAAC-configured addresses. (The link-local address reappears quickly but the 'tentative' flag indicates that it has been newly re-added. The SLAAC address reappears after a slightly longer interval as the kernel continues to undergo SLAAC, but the static address is gone forever unless manually reinstated.)

The same happens if use_tempaddr is changed from 0 back to 2.

The expected outcome is that only temporary addresses are affected by a change to use_tempaddr.
---
AcpiTables:

AlsaDevices:
 total 0
 crw-rw---T 1 root audio 116, 1 May 5 03:53 seq
 crw-rw---T 1 root audio 116, 33 May 5 03:53 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.0.1-0ubuntu7
Architecture: i386
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
CurrentDmesg:

DistroRelease: Ubuntu 12.04
IwConfig: Error: [Errno 2] No such file or directory
Lspci: Error: [Errno 2] No such file or directory
Lsusb: Error: [Errno 2] No such file or directory
Package: linux (not installed)
PciMultimedia:

ProcEnviron:
 TERM=screen.linux
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcFB:

ProcKernelCmdLine: root=UUID=b16ffd9c-a54a-4dd3-a839-16c382ea8787 ro console=hvc0
ProcModules:
 lp 17455 0 - Live 0x00000000
 parport 40930 1 lp, Live 0x00000000
 xenfs 17877 1 - Live 0x00000000
ProcVersionSignature: Ubuntu 3.2.0-24.37-generic-pae 3.2.14
RelatedPackageVersions:
 linux-restricted-modules-3.2.0-24-generic-pae N/A
 linux-backports-modules-3.2.0-24-generic-pae N/A
 linux-firmware 1.79
RfKill: Error: [Errno 2] No such file or directory
Tags: precise
Uname: Linux 3.2.0-24-generic-pae i686
UpgradeStatus: Upgraded to precise on 2012-05-05 (0 days ago)
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 994931

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Malcolm Scott (malcscott)]

The cuplrit is likely to be lines 4355..4359 of net/ipv6/addrconf.c, "try to bring down and back up the interface to get new temporary addresses created" -- this has unwanted side-effects. This seems to be Ubuntu-specific code introduced in http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=commitdiff;h=d1852a54eef5c7b7dd2d026535b4c4d6466664cd .

I have verified that this bug does *not* occur on a mainline build of Linux 3.4rc5.

[Malcolm Scott (malcscott)]

apport information

[Malcolm Scott (malcscott)]

apport information

[Malcolm Scott (malcscott)]

apport information

[Malcolm Scott (malcscott)]

apport information

[Malcolm Scott (malcscott)]

apport information

[Malcolm Scott (malcscott)]

apport information

[Joseph Salisbury (jsalisbury)]

@Malcolm

I'll build a test kernel with the commit mentioned in comment #2 reverted. I'll post a link to the test kernel shortly.

[Joseph Salisbury (jsalisbury)]

I built a test kernel with commit 4bbefb4b1186b13d0d6100bd71d348a1efba017d reverted. The test kernel is located at:

http://people.canonical.com/~jsalisbury/lp994931

Can you test that kernel and report back if it resolves this bug?

[Malcolm Scott (malcscott)]

Alternatively: here's my attempt at fixing the IPv6 Privacy implementation. It could do with code review as I'm not absolutely sure I've got the locking right (although I think I have!).

[Malcolm Scott (malcscott)]

jsalisbury: problem is, simply reverting that commit leaves us with IPv6 Privacy not working at all, and it's on by default now. (There is at least one upstream bug: e.g. https://bugzilla.kernel.org/show_bug.cgi?id=42855)

I should add that I've tested my patch for a few days and it seems to work fine.

[Joseph Salisbury (jsalisbury)]

@Malcolm

Just curious if you sent your patch upstream as of yet? If you have, what sort of feedback has it received, is it getting applied to a subsystem maintainer's tree, etc?

People affected by this bug are probably wondering why the kernel team doesn't just apply the patch and fix it. The reason is that the kernel team is reluctant (not opposed) to apply any patch to a stable kernel that is not from upstream. Applying patches that don't come from upstream add greatly to the support of the kernel as other upstream patches may touch the same area as the non-upstream patch and may prevent them from applying cleanly.

[Malcolm Scott (malcscott)]

@jsalisbury

I would like to submit this upstream, although my patch is just fixing the previous Ubuntu-specific commit I linked above. Do you know whether that has already been sent upstream?

[Joseph Salisbury (jsalisbury)]

@Malcolm

I'm not sure if this has been addressed upstream as of yet. I can do some investigation.

[Malcolm Scott (malcscott)]

Kernel packages with my patch applied are available in this PPA: https://launchpad.net/~malcscott/+archive/lp994931

[Malcolm Scott (malcscott)]

I've been in touch with Mathieu Trudel-Lapierre, the original author of the Ubuntu patch I linked above, who tells me that his patch was rejected upstream as Dave Miller does not want these semantics for 'all' sysctls (and apparently the documentation, rather than the implementation, is wrong): http://lists.openwall.net/netdev/2011/12/19/103

Personally, I disagree with Dave as this makes the 'all' sysctl no different to the 'default' one, and does not match the behaviour of what I believe to be the majority of other 'all' sysctls.

More discussion here: http://ubuntu.5.n6.nabble.com/PATCH-ipv6-make-the-net-ipv6-conf-all-use-tempaddr-sysctl-propagate-to-interface-settings-td1728056.html

Anyway, perhaps the best way to continue for now will be to apply my patch (once reviewed) to the Ubuntu kernel tree as it fixes a regression caused by what is for now an Ubuntu-specific feature.

I will try to reopen discussion of this issue upstream but I think it's pretty unlikely that I'll change Dave Miller's mind!

[Trent Lloyd (lathiat)]

Just ran into this here. I set use_tempaddr=0 in my sysctl.conf, and was very confused why my IPv6 wasn't coming up on boot. Can confirm this is why.

This really needs to be fixed as it breaks IPv6 on boot.

[Andy Whitcroft (apw)]

The patch for this is currently stalled waiting on feedback on the locking model in the patch.

[Scott Moser (smoser)]

verified this works as expected in utopic.
  $ vals() { for i in net.ipv6.conf.all.use_tempaddr net.ipv6.conf.default.use_tempaddr; do
                  [ -n "$1" ] && { sudo sysctl $i=$1 || return; } || sysctl $i; done; }
  $ vals 0
  net.ipv6.conf.all.use_tempaddr = 0
  net.ipv6.conf.default.use_tempaddr = 0

  $ sudo ip -6 addr del 2001:db8::1:3/64 dev eth0 &>/dev/null;
  $ sudo ip -6 addr add 2001:db8::1:3/64 dev eth0

  $ vals 2
  net.ipv6.conf.all.use_tempaddr = 2
  net.ipv6.conf.default.use_tempaddr = 2
  $ ip -6 addr show dev eth0
  2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:db8::1:3/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fefd:d570/64 scope link
       valid_lft forever preferred_lft forever
  $ vals 0
  net.ipv6.conf.all.use_tempaddr = 0
  net.ipv6.conf.default.use_tempaddr = 0

  $ ip -6 addr show dev eth0
  2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:db8::1:3/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fefd:d570/64 scope link
       valid_lft forever preferred_lft forever

  $ uname -r
  3.16.0-21-generic

[James Troup (elmo)]

We just had this bug take out two v6 environments (Canonical UK office and Canonical VPN) after a procps package upgrade; it'd be wonderful if we could get whatever is in utopic SRUed to the LTSes.

[Kamal Mostafa (kamalmostafa)]

Just clarifying: This wasn't "Fix Released" for Utopic; it just was never an issue in Utopic (because only Precise and Trusty carry the Ubuntu-specific patch that triggers it).

[Kamal Mostafa (kamalmostafa)]

I have prepared a test 3.13 kernel (for Trusty) which reverts the Ubuntu-specific patch and adds the set of mainline patches that obviate these issues in Utopic and newer versions. My cursory testing suggests that it resolves both this bug ("drops all IPv6 addresses") and the problem that the Ubuntu-specific patch addressed ("make use_tempaddr work as documented").

The test kernel package, for Trusty amd64 systems only, is here (install with "dpkg -i thisfile.deb"):
http://kernel.ubuntu.com/~kamal/lp994931-ipv6/linux-image-3.13.0-46-generic_3.13.0-46.75+lp994931_amd64.deb

We'd like feedback from affected parties who can test this on Trusty. Does that kernel resolve your issue, and do you observe any obvious IP-related trouble with it?

For reference, the source code branch for that Trusty test kernel is here:
http://kernel.ubuntu.com/git?p=kamal/ubuntu-trusty.git;a=shortlog;h=refs/heads/lp994931-ipv6

A resolution of this issue for 3.2-based Precise is still being investigated.

[Kamal Mostafa (kamalmostafa)]

Test kernels for this issue (as explained in comment #23) are now available for Precise (3.2-based) and Trusty (3.13-based), for both amd64 and i386 systems. To test, download *one* of these then install with "dpkg -i thatfile.deb":

http://kernel.ubuntu.com/~kamal/lp994931-ipv6/precise_amd64/linux-image-3.2.0-77-generic_3.2.0-77.112+lp994931_amd64.deb
http://kernel.ubuntu.com/~kamal/lp994931-ipv6/precise_i386/linux-image-3.2.0-77-generic_3.2.0-77.112+lp994931_i386.deb
http://kernel.ubuntu.com/~kamal/lp994931-ipv6/trusty_amd64/linux-image-3.13.0-46-generic_3.13.0-46.75+lp994931_amd64.deb
http://kernel.ubuntu.com/~kamal/lp994931-ipv6/trusty_i386/linux-image-3.13.0-46-generic_3.13.0-46.75+lp994931_i386.deb

We'd like feedback from affected parties who can test this on Trusty 3.13 and Precise 3.2 systems. Does this kernel resolve your issue, and do you observe any obvious IP-related trouble with it?

For reference, the source code branches for those are here:

http://kernel.ubuntu.com/git?p=kamal/ubuntu-trusty.git;a=shortlog;h=refs/heads/lp994931-ipv6
http://kernel.ubuntu.com/git?p=kamal/ubuntu-precise.git;a=shortlog;h=refs/heads/lp994931-ipv6

[Mathieu Trudel-Lapierre (cyphermox)]

I can't exactly test that IPv6 is fine in general with this, but it doesn't appear to have regressed on Trusty.

[David Lawson (deej)]

The test kernel works (and fixes the problem) on precise, on our trusty test server we don't have any network devices (other than lo0) with the test kernel booted, so we can't really test the IPv6 aspect.

[Sven Mueller (smu-u)]

Any chance this could be fixed in Trusty?

[Sven Mueller (smu-u)]

Ping.
The test kernel seems to fix this. Could it be pushed to Trusty?

[Philipp Kern (pkern)]

Where did this get stuck?

[Kamal Mostafa (kamalmostafa)]

I'm not sure how/why this issue fell by the wayside, but the tested patch sets have (just now) been submitted for review and inclusion in both Precise and Trusty:

https://lists.ubuntu.com/archives/kernel-team/2016-September/080007.html

[Philipp Kern (pkern)]

Thanks, Kamal!

[Brad Figg (brad-figg)]

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-precise' to 'verification-done-precise'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Brad Figg (brad-figg)]

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-trusty' to 'verification-done-trusty'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Philipp Kern (pkern)]

Verified on trusty. Unfortunately I don't have a precise machine anymore. After toggling use_tempaddr not all public addresses disappeared with the new kernel while it happened with the old pre-reboot.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 3.13.0-98.145

---------------
linux (3.13.0-98.145) trusty; urgency=low

  * Fix GRO recursion overflow for tunneling protocols (LP: #1631287)
    - tunnels: Don't apply GRO to multiple layers of encapsulation.

  * CVE-2016-7039
    - SAUCE: net: add recursion limit to GRO

linux (3.13.0-97.144) trusty; urgency=low

  [ Joseph Salisbury ]

  * Release Tracking Bug
    - LP: #1626604

  * Altering use_tempaddr drops all IPv6 addresses (LP: #994931)
    - Revert "UBUNTU: SAUCE: (no-up) ipv6: Fix net.ipv6.conf.all.use_tempaddr
      sysctl"
    - Revert "UBUNTU: SAUCE: (no-up) ipv6: make the net.ipv6.conf.all.use_tempaddr
      sysctl propagate to interface settings"
    - neigh: convert parms to an array
    - neigh: wrap proc dointvec functions
    - neigh: use tbl->family to distinguish ipv4 from ipv6
    - neigh: restore old behaviour of default parms values
    - neigh: ipv6: respect default values set before an address is assigned to
      device

  * PCI quirk required for correct access to configuration space of NFP
    4000/6000 (LP: #1624267)
    - PCI: Support PCIe devices with short cfg_size
    - PCI: Add Netronome vendor and device IDs
    - PCI: Limit config space size for Netronome NFP6000 family
    - PCI: Add Netronome NFP4000 PF device ID
    - PCI: Limit config space size for Netronome NFP4000

  * CVE-2016-6136
    - audit: fix a double fetch in audit_log_single_execve_arg()

  * CVE-2016-6480
    - aacraid: Check size values after double-fetch from user

  * CVE-2016-6828
    - tcp: fix use after free in tcp_xmit_retransmit_queue()

  * IPv6 with LVS Performance issue in latest 3.13LTS kernels (LP: #1618299)
    - ipv6: remove prune parameter for fib6_clean_all
    - ipv6: remove rt6i_genid

  * lsattr 32bit does not work on 64bit kernel (Inappropriate ioctl error)
    (LP: #1619918)
    - btrfs: bugfix: handle FS_IOC32_{GETFLAGS, SETFLAGS, GETVERSION} in
      btrfs_ioctl

  * Miscellaneous upstream changes
    - powerpc/pseries: use pci_host_bridge.release_fn() to kfree(phb)

 -- Seth Forshee <email address hidden> Fri, 07 Oct 2016 20:08:32 -0500

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 3.2.0-111.153

---------------
linux (3.2.0-111.153) precise; urgency=low

  [ Kamal Mostafa ]

  * Release Tracking Bug
    - LP: #1626151

  * Altering use_tempaddr drops all IPv6 addresses (LP: #994931)
    - Revert "UBUNTU: SAUCE: ipv6: make the net.ipv6.conf.all.use_tempaddr sysctl
      propagate to interface settings"
    - neigh: new unresolved queue limits
    - neigh: Add device constructor/destructor capability.
    - atm: clip: Use device neigh support on top of "arp_tbl".
    - atm: clip: remove clip_tbl
    - neigh: convert parms to an array
    - neigh: wrap proc dointvec functions
    - neigh: use tbl->family to distinguish ipv4 from ipv6
    - neigh: restore old behaviour of default parms values
    - neigh: ipv6: respect default values set before an address is assigned to
      device

  * Xen guest total memory size smaller than specified in virtual configuration
    due to Xen balloon driver (LP: #1622567)
    - mm: introduce helper function mem_init_print_info() to simplify mem_init()
    - xen/balloon: Set balloon's initial state to number of existing RAM pages

  * CVE-2016-6136
    - audit: fix a double fetch in audit_log_single_execve_arg()

  * CVE-2016-6480
    - aacraid: Check size values after double-fetch from user

  * CVE-2016-6828
    - tcp: fix use after free in tcp_xmit_retransmit_queue()

 -- Kamal Mostafa <email address hidden> Wed, 21 Sep 2016 14:07:18 -0700