Skip to main content

Linux Kernel CVE-2025-68340

MEDIUM
2025-12-23 416baaa9-dc9f-4396-8d5f-8c081fb06d67
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
5.5 MEDIUM

Local access with low privileges (user namespace on default distros); no confidentiality or integrity impact, only kernel availability loss.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
6.6 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H
Red Hat
4.7 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

2
Analysis Generated
Jun 19, 2026 - 14:01 vuln.today
CVE Published
Dec 23, 2025 - 14:16 nvd
MEDIUM 5.5

DescriptionNVD

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

AnalysisAI

Type confusion in the Linux kernel's team network driver (team_port_add) allows a local user with CAP_NET_ADMIN to corrupt a team device's header_ops state, leading to a kernel hang or BUG(). When an already-UP GRE device is added as a team port, the operation fails but not before team_dev_type_check_change irreversibly replaces eth_header with ipgre_header on the team device; subsequent packet transmission causes ipgre_header() to dereference struct team private data as struct ip_tunnel, triggering a local denial-of-service. No active exploitation has been confirmed (not in CISA KEV), though a syzbot reproducer demonstrates the issue reliably.

Technical ContextAI

The affected component is the team bonding/aggregation network driver in the Linux kernel (drivers/net/team/team_core.c). The root cause is an ordering defect in team_port_add(): team_dev_type_check_change() was called before all port-addition prerequisite checks passed. This function overwrites the team netdevice's header_ops pointer (e.g., from eth_header to ipgre_header) to match the port device's type, with no rollback path if a subsequent check fails. When an already-UP GRE device is offered as a port, the UP-state check rejects it, but header_ops has already been mutated. The device's private data (netdev_priv) still holds struct team, yet ipgre_header() subsequently dereferences it as struct ip_tunnel - a classic type confusion resulting in kernel memory corruption and crash. CPE data confirms impact across multiple stable Linux kernel branches including 6.18-rc1 through rc5. The fix relocates team_dev_type_check_change to after all checks have passed and adds a conditional to preserve correct MTU assignment semantics.

RemediationAI

Update to a patched Linux kernel version containing any of the upstream fix commits: 0ae9cfc454ea5ead5f3ddbdfe2e70270d8e2c8ef, 4040b5e8963982a00aa821300cb746efc9f2947e, a74ab1b532ecc5f9106621a8f75b4c3d04466b35, c8b15b0d2eec3b5c7f585e5a53dfc8d36c818283, e26235840fd961e4ebe5568f11a2a078cf726663, or e3eed4f038214494af62c7d2d64749e5108ce6ca (all at git.kernel.org/stable). Distribution-specific patched versions should be obtained via the relevant vendor security channel (e.g., RHEL errata, Ubuntu USN, SUSE SA). As a compensating control where immediate kernel patching is not feasible, restrict CAP_NET_ADMIN to trusted users only by disabling unprivileged user namespace creation (sysctl kernel.unprivileged_userns_clone=0 on supported distros) - note this trade-off breaks container runtimes and tools relying on user namespaces. Alternatively, use seccomp, AppArmor, or SELinux policies to restrict the ip link set master operation to privileged processes only.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
Container suse/sl-micro/6.0/baremetal-os-container:latest Affected
Container suse/sl-micro/6.0/base-os-container:2.1.3-7.95 Image SL-Micro Affected
Container suse/sl-micro/6.0/kvm-os-container:2.1.3-6.115 Affected
Container suse/sl-micro/6.0/rt-os-container:2.1.3-7.146 Affected
Container suse/sl-micro/6.0/toolbox:latest Affected

Share

CVE-2025-68340 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy