CVE-2025-68340High· 7.8▾ TwilightIn 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 te…
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 42.9 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake. The CVSS score shown above comes from the assigning CNA record, not NVD.
Exploit-prediction probability, daily snapshots since Oct 16.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via CVEORG
Last analysed / modified upstream
0.1%
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:
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:
Linux >= 1d76efe1577b4323609b1bcbfafa8b731eda071a < f82d1fb65549de241fe312fcb2bcb8e0ad7b424dLinux >= 1d76efe1577b4323609b1bcbfafa8b731eda071a < c8b15b0d2eec3b5c7f585e5a53dfc8d36c818283Linux >= 1d76efe1577b4323609b1bcbfafa8b731eda071a < a74ab1b532ecc5f9106621a8f75b4c3d04466b35Linux >= 1d76efe1577b4323609b1bcbfafa8b731eda071a < e26235840fd961e4ebe5568f11a2a078cf726663Linux >= 1d76efe1577b4323609b1bcbfafa8b731eda071a < 4040b5e8963982a00aa821300cb746efc9f2947eLinux >= 1d76efe1577b4323609b1bcbfafa8b731eda071a < e3eed4f038214494af62c7d2d64749e5108ce6caLinux >= 1d76efe1577b4323609b1bcbfafa8b731eda071a < 0ae9cfc454ea5ead5f3ddbdfe2e70270d8e2c8efLinux 3.7Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-99118Nonedrm/i915/dmc: Harden DMC firmware payload parsing
CVE-2026-99117Nonenet: bridge: mcast: don't truncate the port group walk on teardown
CVE-2026-99121Noneipv4: avoid divide by zero in fib_rebalance
CVE-2026-99120NoneKVM: x86/mmu: Cope with the SS bit being set in #NPF exit codes
CVE-2026-99119Nonedrm/amdgpu/userq: actually validate userq BOs
CVE-2026-99123Nonevsock/virtio: validate packet source for connected sockets