CVE-2025-68340
Unknown Unknown - Not Provided
Use-After-Free in Linux Kernel Team Device Header Handling Causes System Hang

Publication date: 2025-12-23

Last updated on: 2026-02-26

Assigner: kernel.org

Description
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
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-23
Last Modified
2026-02-26
Generated
2026-05-06
AI Q&A
2025-12-23
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 12 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 5.16 (inc) to 6.1.162 (exc)
linux linux_kernel 6.18
linux linux_kernel From 3.7 (inc) to 5.15.199 (exc)
linux linux_kernel From 6.13 (inc) to 6.17.11 (exc)
linux linux_kernel From 6.2 (inc) to 6.6.123 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.61 (exc)
linux linux_kernel 6.18
linux linux_kernel 6.18
linux linux_kernel 6.18
linux linux_kernel 6.18
linux linux_kernel 6.18
linux linux_kernel 6.18
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability occurs in the Linux kernel's team device driver. When attempting to add a port device that is already in the UP state to a team device, the operation fails but not before the team device's header operations are incorrectly modified. Specifically, the header_ops->create function changes from eth_header to ipgre_header prematurely. This leads to a situation where the ipgre_header function operates on invalid data because the device's private data still points to a team structure, causing potential system instability or crashes. The issue arises because the device type change check is performed too early, before all validation checks have passed, and the fix involves moving this check to a later stage and preserving the original MTU assignments properly.


How can this vulnerability impact me? :

This vulnerability can cause system instability or crashes (hangs or BUGs) when adding a network port device that is already up to a team device. It can lead to invalid memory references due to incorrect device header operations, potentially disrupting network functionality and causing kernel-level errors.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by attempting to reproduce the issue using the example iproute2 commands provided in the description, which demonstrate the problematic sequence leading to a hang or BUG(). The commands are: 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 Running these commands in sequence on a vulnerable system may reproduce the hang or BUG, indicating the presence of the vulnerability.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include avoiding adding a port device that is already in the UP state as a port device of a team device, as this triggers the vulnerability. Additionally, monitoring for kernel updates or patches that move the team_dev_type_check_change call to after all checks have passed and preserve the original MTU assignment should be applied once available. Until then, refrain from configurations that replicate the problematic sequence involving team and gre devices as described.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart