CVE-2026-98569: ip_gre: Reject enabling collect metadata through changelink

Published Oct 18, 2026

Updated

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

ipgre: Reject enabling collect metadata through changelink

ipgrenetlinkparms() can enable collectmd on an existing GRE, GRETAP or ERSPAN device. Unlike newlink, changelink does not enforce metadata tunnel uniqueness. Converting a non-metadata device can therefore replace the metadata receive entry for another device of the same type in the same netns. Deleting either device then clears the shared entry, breaking metadata receive lookup for the surviving device.

If parameter validation fails after collectmd is set, deleting the modified device can also clear an entry it never owned.

Reject enabling metadata mode in both changelink callbacks before any encapsulation or tunnel parameters are modified. Allow requests that repeat the metadata attribute on an existing metadata device.

Affected Software

1 affected component

Linux Linux kernel

Event History

Oct 18, 2026

CVE Published

via MITRE·03:18 PM

Data Sourced

via MITRE·03:18 PM

Description

Data Sourced

via NVD·04:17 PM

Description

Frequently Asked Questions

Which systems are exposed to this issue?

Systems are exposed if they have existing GRE, GRETAP, or ERSPAN devices and allow a changelink operation that enables collect metadata mode. The conflict occurs between devices of the same tunnel type within the same network namespace.

What must happen for the issue to be triggered?

A changelink request must convert an existing non-metadata tunnel device to collect metadata mode when another metadata tunnel of the same type already exists in that network namespace. Deleting either device afterward can remove the shared metadata receive entry and break receive lookup for the remaining device.

Are already-metadata tunnel devices affected by requests that include the metadata attribute?

Repeating the metadata attribute for a device that is already in metadata mode is allowed. The fix specifically rejects attempts to enable metadata mode through changelink on a non-metadata device.

What can happen if parameter validation fails during the change?

If collect metadata is set before later parameter validation fails, deleting the modified device can clear a metadata receive entry that the device did not own. This can disrupt metadata receive lookup for another tunnel device.

CVE-2026-98569: ip_gre: Reject enabling collect metadata through changelink

Affected Software

Event History

Frequently Asked Questions

Which systems are exposed to this issue?

What must happen for the issue to be triggered?

Are already-metadata tunnel devices affected by requests that include the metadata attribute?

What can happen if parameter validation fails during the change?

Company

Resources

Contact

Frequently Asked Questions

Which systems are exposed to this issue?

What must happen for the issue to be triggered?

Are already-metadata tunnel devices affected by requests that include the metadata attribute?

What can happen if parameter validation fails during the change?