[Bug 287369] Surprise removal of network device can cause crash in IPv6 network stack

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287369

            Bug ID: 287369
           Summary: Surprise removal of network device can cause crash in
                    IPv6 network stack
           Product: Base System
           Version: 14.2-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: noisetube@gmail.com

Created attachment 261075
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=261075&action=edit
Crash dump summary

I often use USB tethering via my Google Pixel 7a phone. My carrier is T-Mobile.
For a long time I was simply using IPv4 with DHCP. This has worked seamlessly
with FreeBSD for as long as I can recall. When set to tethering mode the phone
is detected by FreeBSD as a cdce(4) USB network device. I can simply use
dhclient(8) to obtain an IP address.

A while back I found out that Android can do IPv6 tethering if your carrier
supports it, which T-Mobile does, so I decided to try that with FreeBSD too.
The strategy I use is to simply add this line to my /etc/rc.conf file:

ifconfig_ue0_ipv6="inet6 accept_rtadv"

Now, when I plug my phone and enable tethering, FreeBSD receives an IPv6 router
advertisement and is automatically assigned an IPv6 address. From here, things
Just Work (tm) as expected.

The problem is, since the phone is a USB device it can be surprise-removed.
This leads to the ue0 network interface being destroyed. I have never had a
problem with this with IPv4: the interface goes a way, dhclient(8) exits, and
the system keeps going.

This works *mostly* with IPv6, but not always. Sometimes it causes the kernel
to panic shortly after I unplug the phone. I first noticed this with FreeBSD
14.1 and it still happens in FreeBSD 14.2.

Based on the latest crash dump info (which I will include as an attachment), it
looks like there is a TCP timeout that triggers for a stream socket that was
opened while the interface was active which is now resulting in the TCP stack
trying to send a reply, even though the interface is now no longer there to
send it. Eventually in6_selecthlim() is called, but it explodes, likely because
it's being provided an invalid interface handle.

The crash dump summary shows the dmesg output with my complete system info, but
briefly my configuration is:

OS: FreeBSD/amd64 14.2-RELEASE
System: Dell OptiPlex 9010 (all-in-one desktop)
CPU: Intel(R) Core(TM) i7-3770S CPU @ 3.10GHz
Cores: 4 physical, 8 logical (hyperthreading is enabled)
RAM: 16GB
Chipset: Intel Panther Point

Steps to reproduce:

1) Get a phone with tethering support with a carrier that supports IPv6 (which
hopefully should be most of them), or a USB ethernet adapter. If using an
ethernet adapter, you will need to set up a test machine that supports IPv6
with router advertisements.
2) Install FreeBSD/amd64 14.2-RELEASE on an Intel system, with your favorite
graphical desktop environment and web browser
3) Edit /etc/rc.conf and add the line:

ifconfig_ue0_ipv6="inet6 accept_rtadv"

(If necessary, change ue0 to whatever the interface name is for your device.)

4) Plug the phone/adapter into a free USB port. If using a phone, enable
tethering over USB. For Android this would be under Settings->Network &
Internet->Hotspot & tethering.
5) Use ifconfig -a to verify that the device has been detected and that it has
an IPv6 address assigned
6) Generate some network traffic over the port: browse the web for a while.
7) At a randomly selected time, unplug the phone/adapter from its USB port

If you do this often enough, you should eventually encounter a panic.

-Bill

-- 
You are receiving this mail because:
You are the assignee for the bug.