Bug 218895

Summary:	ifconfig name with same group name will crash the system
Product:	Base System	Reporter:	luizgustavo
Component:	kern	Assignee:	freebsd-net (Nobody) <net>
Status:	Open ---
Severity:	Affects Many People	CC:	emaste, jcaplan, kp, ultima, universite
Priority:	---
Version:	11.0-STABLE
Hardware:	amd64
OS:	Any
See Also:	https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247746

Description luizgustavo 2017-04-26 17:22:00 UTC

When i will set a name of the interface with same name of group the system will
crash immmediatetly.

Example:

ifconfig tap0 create
ifconfig tap0 name test group test

11-STABLE but, also tested on 11-RELEASE-p9

Comment 1 Kristof Provost freebsd_committer

2017-04-26 18:13:38 UTC

I can't reproduce this on current.

Do you happen to have pf loaded? I'm aware that pf doesn't handle this. The basic problem is that pf assumes that interfaces and groups live in the same namespace. That's not the case, and this mistaken assumption causes pf to panic the system.

It's a nontrivial fix, because the best way (in my view at least) to fix this is to actually make groups and interfaces share a namespace. It's downright silly to have a group foo and an interface foo at the same time, especially because there's no obligation for interface foo to be a member of group foo.

I suspect this became a problem when the ability to change interface names was introduced. It used to be the case that interfaces were always foo0 or bar1. In fact, groups still refuse to be named baz3 ("ifconfig: setifgroup: group names may not end in a digit").

Comment 2 luizgustavo 2017-04-26 20:29:08 UTC

Yes, with pf loaded:

root@fbsd:~ # uname -a
FreeBSD fbsd.lab.local 11.0-RELEASE-p9 FreeBSD 11.0-RELEASE-p9 #0: Tue Apr 11 08:48:40 UTC 2017     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
root@fbsd:~ # kldload pf
root@fbsd:~ # ifconfig lagg0 create
root@fbsd:~ # ifconfig lagg0 name test group test

<6>lagg0: changing name to 'test'

Fatal double fault
rip = 0xffffffff80ad4d34
rsp = 0xfffffe0000218fe0
rbp = 0xfffffe0000219070
cpuid = 0; apic id = 00
panic: double fault
cpuid = 0
KDB: stack backtrace:
#0 0xffffffff80b24477 at kdb_backtrace+0x67
Uptime: 3m23s
Dumping 103 out of 991 MB:


without pf, everything works normally

Comment 3 Richard Gallamore freebsd_committer

2017-08-15 21:37:58 UTC

*** Bug 221492 has been marked as a duplicate of this bug. ***

Comment 4 Eugene Grosbein freebsd_committer

2018-01-03 09:55:07 UTC

*** Bug 154214 has been marked as a duplicate of this bug. ***

Comment 5 jcaplan 2021-06-24 17:56:18 UTC

*** Bug 256815 has been marked as a duplicate of this bug. ***

Comment 6 Kristof Provost freebsd_committer

2022-11-28 20:33:25 UTC

Note that this no longer causes pf to panic. See b2e0b24f76066fc52abe4330772c41996eca8bf8 (from Sat Dec 1 09:58:21 2018).

The underlying problem is still there, and if you do this you're going to have some very unexpected and difficult to understand behaviour in pf, but at least it doesn't panic any more.

I've looked at fixing this, but there's no error handling in many of the group/interface name assignment paths and the locking .. well, either I completely fail to understand it, or it's mostly wrong.