CVE-2026-90248 in Linuxinfo

Summary

by MITRE • 09/17/2026

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

net/sched: cls_api: fix teardown of an adopted proto on insert-race loss

In tc_new_tfilter() the create branch sets tp_created = 1 before calling tcf_chain_tp_insert_unique(). When the caller loses the race (another request inserted a proto at the same chain/prio first), insert_unique() destroys the caller's own tp_new and returns the winner's proto with an extra reference. tp_created was never cleared, so the loser's errout path treated the winner's live proto as its own and called tcf_chain_tp_delete_empty() on it, silently unlinking an active classifier that the winning request already advertised via RTM_NEWTFILTER.

Track the outcome of the insert step in a single tri-state variable so each errout path reacts correctly:

- TP_NOT_CREATED: no proto created; pursue the old path. - TP_CREATED: proto inserted successfully; same code path as before. - TP_NOT_OWNED: New - lost the insert race; tp is another request's proto (chain ref already released by tp_new's destroy)

Both errout reactions are single expressions derived from the state.

This fix is motivated by the Sashiko's automated review of Patch (net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers) [1][2]. The review identified the silent-unlink behaviour of
an adopted proto's teardown when a request loses the tcf_chain_tp_insert_unique() race.

[1] https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com
[2] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 09/17/2026

The Linux kernel networking subsystem contains a race condition vulnerability within the traffic control classifier API, specifically in the net/sched/cls_api.c module during the handling of filter insertion requests. This flaw arises from an improper state management mechanism when multiple concurrent processes attempt to insert classifiers into the same chain and priority level simultaneously. The core issue is located in the tc_new_tfilter function, which manages the lifecycle of classifier instances (tcf_proto). When a new request initiates the creation of a classifier prototype, it sets a flag indicating that a new object was created before attempting to insert this object into the global hash table via tcf_chain_tp_insert_unique. This insertion process is not atomic with respect to race detection; if another concurrent request successfully inserts its own classifier at the same location first, the kernel's internal logic returns the winner's existing prototype pointer while destroying the loser's newly allocated but uninserted prototype structure.

The critical technical flaw lies in the failure to update the state variable tracking whether the current process owns the returned prototype after a race loss. Although the losing request's temporary prototype is correctly destroyed, the flag indicating that a new object was created remains set to true. Consequently, when the error handling or cleanup path for this specific operation executes, it incorrectly assumes ownership of the winner's live classifier instance. This leads to an erroneous call to tcf_chain_tp_delete_empty, which silently unlinks and destroys the active classifier belonging to the winning request. Since the winning request has already advertised its new filter via RTM_NEWTFILTER netlink messages, this silent deletion results in a state inconsistency where userspace believes the filter exists while the kernel's internal data structures have removed it without notification.

From an operational impact perspective, this vulnerability can lead to unexpected network configuration failures and potential denial of service conditions for traffic control policies. Administrators relying on automated scripts or high-concurrency applications to manage network filters may experience intermittent loss of critical classification rules. This undermines the reliability of packet filtering, shaping, and policing mechanisms that depend on precise classifier placement. The silent nature of the bug makes it particularly difficult to diagnose through standard logging, as no explicit error is returned to the application; instead, the filter simply disappears from active operation while appearing present in configuration dumps.

This vulnerability aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization Race Conditions, as the root cause is a failure to properly synchronize access and state updates during concurrent insertion attempts into shared kernel data structures. Furthermore, it relates to CWE-459, Incomplete Cleanup, because resources are not correctly released or tracked when an operation fails due to concurrency issues. The behavior also reflects aspects of CWE-823, Use of Lock Object in a Way Inconsistent with Operations Performed on It, as the lock state and object ownership tracking were misaligned during the teardown process.

The mitigation implemented involves refactoring the state tracking logic to use a tri-state variable that accurately reflects three distinct outcomes: TP_NOT_CREATED for cases where no prototype was allocated, TP_CREATED for successful insertion by the current request, and TP_NOT_OWNED for scenarios where the race is lost and another request owns the resulting prototype. This ensures that error paths correctly identify when they do not own the returned object and refrain from deleting it. To prevent similar issues in related areas, this fix was motivated by broader reviews of classifier destruction logic under lock contention, highlighting the need for rigorous synchronization checks across all code paths involving locked classifiers. System administrators should ensure their Linux kernels are updated to versions containing this patch to maintain the integrity of network traffic control configurations and avoid silent policy loss during high-concurrency operations.

Responsible

Linux

Reservation

09/11/2026

Disclosure

09/17/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!