cbcvebase.
CVE-2025-68340
published 2025-12-23

CVE-2025-68340: In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port…

PriorityP421medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.13%
3.0th percentile
In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. 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 header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* 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 team_dev_type_check_change 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 port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot

Affected

50 ranges· showing 25
VendorProductVersion rangeFixed in
debianlinux< linux 6.1.162-1 (bookworm)linux 6.1.162-1 (bookworm)
debianlinux-6.1< linux 6.1.162-1 (bookworm)linux 6.1.162-1 (bookworm)
linuxlinux
linuxlinux>= 1d76efe1577b4323609b1bcbfafa8b731eda071a < f82d1fb65549de241fe312fcb2bcb8e0ad7b424df82d1fb65549de241fe312fcb2bcb8e0ad7b424d
linuxlinux>= 1d76efe1577b4323609b1bcbfafa8b731eda071a < c8b15b0d2eec3b5c7f585e5a53dfc8d36c818283c8b15b0d2eec3b5c7f585e5a53dfc8d36c818283
linuxlinux>= 1d76efe1577b4323609b1bcbfafa8b731eda071a < a74ab1b532ecc5f9106621a8f75b4c3d04466b35a74ab1b532ecc5f9106621a8f75b4c3d04466b35
linuxlinux>= 1d76efe1577b4323609b1bcbfafa8b731eda071a < e26235840fd961e4ebe5568f11a2a078cf726663e26235840fd961e4ebe5568f11a2a078cf726663
linuxlinux>= 1d76efe1577b4323609b1bcbfafa8b731eda071a < 4040b5e8963982a00aa821300cb746efc9f2947e4040b5e8963982a00aa821300cb746efc9f2947e
linuxlinux>= 1d76efe1577b4323609b1bcbfafa8b731eda071a < e3eed4f038214494af62c7d2d64749e5108ce6cae3eed4f038214494af62c7d2d64749e5108ce6ca
linuxlinux>= 1d76efe1577b4323609b1bcbfafa8b731eda071a < 0ae9cfc454ea5ead5f3ddbdfe2e70270d8e2c8ef0ae9cfc454ea5ead5f3ddbdfe2e70270d8e2c8ef
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.1.162-16.1.162-1
linuxlinux_kernel>= 0 < 6.12.63-16.12.63-1
linuxlinux_kernel>= 0 < 6.17.11-16.17.11-1
linuxlinux_kernel>= 0 < 6.8.0-106.1066.8.0-106.106
linuxlinux_kernel>= 0 < 6.17.0-19.196.17.0-19.19
linuxlinux_kernel>= 3.7 < 5.15.1995.15.199
linuxlinux_kernel>= 5.16 < 6.1.1626.1.162
linuxlinux_kernel>= 6.13 < 6.17.116.17.11

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv7.2HIGH
vendor_ubuntu7.8HIGH
vendor_debian5.5MEDIUM
vendor_msrc5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.