Bug 219250 - panic: in6_ifattach_linklocal: ia == NULL (assigning ipv6 addresses)
Summary: panic: in6_ifattach_linklocal: ia == NULL (assigning ipv6 addresses)
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: Eric van Gyzen
URL: https://reviews.freebsd.org/D17898
Keywords: crash, ipv6
Depends on:
Blocks:
 
Reported: 2017-05-13 06:50 UTC by Reshad Patuck
Modified: 2018-11-28 04:08 UTC (History)
3 users (show)

See Also:
koobs: mfc-stable12+
koobs: mfc-stable11+


Attachments
core.txt file for the panic (197.44 KB, text/plain)
2017-05-13 06:50 UTC, Reshad Patuck
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Reshad Patuck 2017-05-13 06:50:13 UTC
Created attachment 182557 [details]
core.txt file for the panic

Hey,

While ruining some tests with about 20 vnet jails with pf and netgraph I get this panic.

I have attached the core.txt for the panic to this post.

From what I can understand there sees to be some issue assigning ipv6 addresses to epairs in the vnet jail.

Please let me know if there is any other information or something else I can help with.

Kernel version r318025

---

panic: in6_ifattach_linklocal: ia == NULL, ifp=0xfffff801b9828000

---

(kgdb) backtrace 
#0  __curthread () at ./machine/pcpu.h:232
#1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:318
#2  0xffffffff803a308b in db_dump (dummy=<optimized out>, dummy2=<error reading variable: access outside bounds of object referenced via synthetic pointer>, dummy3=<unavailable>, dummy4=<unavailable>) at /usr/src/sys/ddb/db_command.c:546
#3  0xffffffff803a2e7f in db_command (last_cmdp=<optimized out>, cmd_table=<optimized out>, dopager=<optimized out>) at /usr/src/sys/ddb/db_command.c:453
#4  0xffffffff803a2bb4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:506
#5  0xffffffff803a5c7f in db_trap (type=<optimized out>, code=<optimized out>) at /usr/src/sys/ddb/db_main.c:248
#6  0xffffffff80a95673 in kdb_trap (type=3, code=-61456, tf=<optimized out>) at /usr/src/sys/kern/subr_kdb.c:654
#7  0xffffffff80ef0de6 in trap (frame=0xfffffe1043e13310) at /usr/src/sys/amd64/amd64/trap.c:537
#8  <signal handler called>
#9  kdb_enter (why=0xffffffff8145adfd "panic", msg=<optimized out>) at /usr/src/sys/kern/subr_kdb.c:444
#10 0xffffffff80a533f9 in vpanic (fmt=<optimized out>, ap=0xfffffe1043e134a0) at /usr/src/sys/kern/kern_shutdown.c:772
#11 0xffffffff80a53236 in kassert_panic (fmt=0xffffffff8149b825 "%s: ia == NULL, ifp=%p") at /usr/src/sys/kern/kern_shutdown.c:669
#12 0xffffffff80c7805b in in6_ifattach_linklocal (ifp=<optimized out>, altifp=<optimized out>) at /usr/src/sys/netinet6/in6_ifattach.c:505
#13 in6_ifattach (ifp=0xfffff801b9828000, altifp=<optimized out>) at /usr/src/sys/netinet6/in6_ifattach.c:747
#14 0xffffffff80b462ea in if_route (flag=1, fam=0, ifp=<optimized out>) at /usr/src/sys/net/if.c:2148
#15 if_up (ifp=0xfffff801b9828000) at /usr/src/sys/net/if.c:2233
#16 0xffffffff80b47f93 in ifhwioctl (cmd=<optimized out>, ifp=<optimized out>, td=0xfffff8002d117000, data=<optimized out>) at /usr/src/sys/net/if.c:2452
#17 ifioctl (so=<optimized out>, cmd=<optimized out>, data=<optimized out>, td=<optimized out>) at /usr/src/sys/net/if.c:2821
#18 0xffffffff80aba11d in fo_ioctl (fp=<optimized out>, com=2149607696, active_cred=<optimized out>, td=<optimized out>, data=<optimized out>) at /usr/src/sys/sys/file.h:323
#19 kern_ioctl (td=<optimized out>, fd=<optimized out>, com=<optimized out>, data=0xfffffe1043e132d0 "") at /usr/src/sys/kern/sys_generic.c:836
#20 0xffffffff80ab9ddf in sys_ioctl (td=<optimized out>, uap=0xfffffe1043e13930) at /usr/src/sys/kern/sys_generic.c:745
#21 0xffffffff80ef2059 in syscallenter (td=0xfffff8002d117000, sa=<optimized out>) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:136
#22 amd64_syscall (td=0xfffff8002d117000, traced=0) at /usr/src/sys/amd64/amd64/trap.c:902
#23 <signal handler called>
#24 0x0000000800fd9dfa in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffffffdd88

---
Comment 1 Reshad Patuck 2017-05-13 07:54:57 UTC
As an attempt for a workaround I disabled automatically adding IPv6 addresses to epairs when they come up in the jails.

I did this by setting the sysctl net.inet6.ip6.auto_linklocal=0

This time when I did ifconfig epair0b up in the jail, it did not automatically assign an IPv6 address.

Running the same test crashed with a new panic possibly with pf state teardown.

I have submitted bug #219251 for that panic.
Comment 2 Eric van Gyzen freebsd_committer freebsd_triage 2018-11-07 19:10:49 UTC
Something removed an IPv6 link-local interface address immediately after it was added.  I don't know how this happened.  However, it is clear that there is no thread synchronization to prevent this scenario and guarantee the assertion.  This function (or its caller) really needs some kind of synchronization.  
Write-locking the if_addr_lock, which protects the interface's list of 
addresses, seems like a good choice, but I haven't tested that.

I'm removing [VIMAGE] from the title, since this can be triggered without VIMAGE.
Comment 3 Eric van Gyzen freebsd_committer freebsd_triage 2018-11-08 15:00:07 UTC
https://reviews.freebsd.org/D17898
Comment 4 commit-hook freebsd_committer freebsd_triage 2018-11-08 19:51:14 UTC
A commit references this bug:

Author: vangyzen
Date: Thu Nov  8 19:50:23 UTC 2018
New revision: 340257
URL: https://svnweb.freebsd.org/changeset/base/340257

Log:
  in6_ifattach_linklocal: handle immediate removal of the new LLA

  If another thread immediately removes the link-local address
  added by in6_update_ifa(), in6ifa_ifpforlinklocal() can return NULL,
  so the following assertion (or dereference) is wrong.
  Remove the assertion, and handle NULL somewhat better than panicking.
  This matches all of the other callers of in6_update_ifa().

  PR:		219250
  Reviewed by:	bz, dab (both an earlier version)
  MFC after:	1 week
  Sponsored by:	Dell EMC Isilon
  Differential Revision:	https://reviews.freebsd.org/D17898

Changes:
  head/sys/netinet6/in6_ifattach.c
Comment 5 commit-hook freebsd_committer freebsd_triage 2018-11-27 19:40:39 UTC
A commit references this bug:

Author: vangyzen
Date: Tue Nov 27 19:40:07 UTC 2018
New revision: 341086
URL: https://svnweb.freebsd.org/changeset/base/341086

Log:
  MFC r340257

  in6_ifattach_linklocal: handle immediate removal of the new LLA

  If another thread immediately removes the link-local address
  added by in6_update_ifa(), in6ifa_ifpforlinklocal() can return NULL,
  so the following assertion (or dereference) is wrong.
  Remove the assertion, and handle NULL somewhat better than panicking.
  This matches all of the other callers of in6_update_ifa().

  PR:		219250
  Reviewed by:	bz, dab (both an earlier version)
  Sponsored by:	Dell EMC Isilon
  Differential Revision:	https://reviews.freebsd.org/D17898

Changes:
_U  stable/12/
  stable/12/sys/netinet6/in6_ifattach.c
Comment 6 commit-hook freebsd_committer freebsd_triage 2018-11-27 19:40:42 UTC
A commit references this bug:

Author: vangyzen
Date: Tue Nov 27 19:40:18 UTC 2018
New revision: 341087
URL: https://svnweb.freebsd.org/changeset/base/341087

Log:
  MFC r340257

  in6_ifattach_linklocal: handle immediate removal of the new LLA

  If another thread immediately removes the link-local address
  added by in6_update_ifa(), in6ifa_ifpforlinklocal() can return NULL,
  so the following assertion (or dereference) is wrong.
  Remove the assertion, and handle NULL somewhat better than panicking.
  This matches all of the other callers of in6_update_ifa().

  PR:		219250
  Reviewed by:	bz, dab (both an earlier version)
  Sponsored by:	Dell EMC Isilon
  Differential Revision:	https://reviews.freebsd.org/D17898

Changes:
_U  stable/11/
  stable/11/sys/netinet6/in6_ifattach.c