CVE-2025-68340: team: Move team device type change at the end of team_port_add

In the Linux kernel, the following vulnerability has been resolved:

team: Move team device type change at the end of teamportadd

Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device headerops.

In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that headerops->create of team0 is changed from ethheader to ipgreheader in the call to teamdevtypecheckchange.

Later when we end up in ipgreheader() struct iptunnel points to nonsense as the private data of the device still holds a struct team.

Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1

Move teamdevtypecheckchange down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail.

Also make sure to preserve the origial mtu assignment: - If portdev is not the same type as dev, dev takes mtu from portdev - If portdev is the same type as dev, portdev takes mtu from dev

This is done by adding a conditional before the call to devsetmtu to prevent it from assigning portdev->mtu = dev->mtu and instead letting teamdevtypecheckchange assign dev->mtu = portdev->mtu. The conditional is needed because the patch moves the call to teamdevtypecheckchange past devsetmtu.

Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot