Bug 205194 - Changing MTU higher than 1500 on the interface pfsync0 causes panic
Summary: Changing MTU higher than 1500 on the interface pfsync0 causes panic
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 10.1-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Kristof Provost
URL: https://reviews.freebsd.org/D4522
Keywords: crash, needs-qa, patch
Depends on:
Blocks:
 
Reported: 2015-12-10 15:24 UTC by Vladyslav V. Prodan
Modified: 2015-12-29 15:17 UTC (History)
2 users (show)

See Also:
kp: mfc-stable10+
kp: mfc-stable9-


Attachments
Here is a screenshot with IPMI (38.80 KB, image/gif)
2015-12-10 15:24 UTC, Vladyslav V. Prodan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vladyslav V. Prodan 2015-12-10 15:24:36 UTC
Created attachment 164048 [details]
Here is a screenshot with IPMI

# ifconfig pfsync0
pfsync0: flags=0<> metric 0 mtu 1500
        syncpeer: 0.0.0.0 maxupd: 128 defer: off
# ifconfig pfsync0 syncdev em1.201 mtu 1500 up
# ifconfig pfsync0
pfsync0: flags=41<UP,RUNNING> metric 0 mtu 1500
        pfsync: syncdev: em1.201 syncpeer: 224.0.0.240 maxupd: 128 defer: off

# ifconfig pfsync0 syncdev em1.201 mtu 1600 up
and panic...

Current process - ifconfig.
Comment 1 Kristof Provost freebsd_committer freebsd_triage 2015-12-11 19:58:06 UTC
I've had a quick look at this, and imagine my surprise when it turned out to not actually be a PF bug.

Briefly, the pfsync interface doesn't have any ip6 data associated with it, while the netinet6 code assumes it to be present.
We panic because of the call to nd6_setmtu(ifp); in the SIOCSIFMTU ioctl() handler.

We just need to check if ip6 is active on the interface before we try to do anything with it.

There's an open review in: https://reviews.freebsd.org/D4522
Comment 2 commit-hook freebsd_committer freebsd_triage 2015-12-14 19:44:57 UTC
A commit references this bug:

Author: kp
Date: Mon Dec 14 19:44:49 UTC 2015
New revision: 292219
URL: https://svnweb.freebsd.org/changeset/base/292219

Log:
  inet6: Do not assume every interface has ip6 enabled.

  Certain interfaces (e.g. pfsync0) do not have ip6 addresses (in other words,
  ifp->if_afdata[AF_INET6] is NULL). Ensure we don't panic when the MTU is
  updated.

  pfsync interfaces will never have ip6 support, because it's explicitly disabled
  in in6_domifattach().

  PR:		205194
  Reviewed by:	melifaro, hrs
  Differential Revision:	https://reviews.freebsd.org/D4522

Changes:
  head/sys/netinet6/in6.c
  head/sys/netinet6/nd6.c
Comment 3 Renato Botelho freebsd_committer freebsd_triage 2015-12-15 01:12:51 UTC
Could you please MFC it to stable/10?
Comment 4 Kristof Provost freebsd_committer freebsd_triage 2015-12-16 15:30:24 UTC
(In reply to Renato Botelho from comment #3)
Yes, that's now on my todo list. Expect it sometime next week.
Comment 5 commit-hook freebsd_committer freebsd_triage 2015-12-21 20:30:18 UTC
A commit references this bug:

Author: kp
Date: Mon Dec 21 20:29:56 UTC 2015
New revision: 292566
URL: https://svnweb.freebsd.org/changeset/base/292566

Log:
  MFC r292219:

  inet6: Do not assume every interface has ip6 enabled.

  Certain interfaces (e.g. pfsync0) do not have ip6 addresses (in other words,
  ifp->if_afdata[AF_INET6] is NULL). Ensure we don't panic when the MTU is
  updated.

  pfsync interfaces will never have ip6 support, because it's explicitly disabled
  in in6_domifattach().

  PR:         205194

Changes:
  stable/10/sys/netinet6/nd6.c
Comment 6 Kristof Provost freebsd_committer freebsd_triage 2015-12-29 15:17:27 UTC
stable/9 does not have this problem, so not MFCing there.

In stable/9 in6_domifattach() does not explicitly reject pfsync interfaces, unlike in stable/10 and current.

As it's fixed in stable/10 and current and does not affect stable/9 I'm closing this bug.