CVE-2026-98811

net/sched: cls_api: reclaim an empty proto on the error path

Published Oct 18, 2026 CVSS 3.1 · 3.3 Low EPSS < 1% KEV · Not listed
Description
In the Linux kernel, the following vulnerability has been resolved:

net/sched: cls_api: reclaim an empty proto on the error path

Two racing tc filter add requests on the same chain/prio of an
unlocked classifier both run change() on the shared proto and both
can fail: the winner's tcf_chain_tp_delete_empty() attempt gives up
because the loser's handle is still in the idr, and the loser's
error path drops only its own reference without a second reclamation
attempt. The empty proto stays linked in the chain, holding the
chain reference, a block reference and the classifier module
reference until the chain or block is torn down.

Reclaim the proto on the error path of any failed request that holds
a proto reference. The reclamation is emptiness-gated:
tcf_chain_tp_delete_empty() unlinks the proto only when
delete_empty() admits it is empty, so a live shared proto is never
unlinked. A proto the request created is reclaimed unconditionally -
it is the only owner, so marking it for deletion is safe even without
a delete_empty callback. Classifiers without one (the check marks the
proto unconditionally) are rtnl-serialized, so the raced window this
guard closes cannot arise for them.

This is a follow-up to commit d4e359b3608a ("net/sched: cls_api: fix
teardown of an adopted proto on insert-race loss"), which stopped the
loser of the insert race from unlinking the winner's live proto but
left the empty-proto residual in place.

Conditions to recreate:
- CONFIG_NET_CLS_FLOWER=y; veth pair
- tc qdisc add dev veth0 ingress
- two concurrent `tc filter add dev veth0 ingress protocol ip pref 1
flower skip_sw ... action drop` (both fail in fl_hw_replace_filter
after publishing their handle in the idr); repeat in a loop
- an empty flower tp stays linked after both requests fail; visible
as a bare `filter protocol ip pref 1 flower chain 0` header in
`tc filter show` with no filter entries
- CAP_NET_ADMIN (namespace-local via unshare -Urn suffices)

Remediation

No solution or workaround provided in the CVE record

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
Debian DLA Debian DLA DLA-4850-1 linux-6.12 security update
Ubuntu USN Ubuntu USN USN-9018-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9018-2 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-9019-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-9020-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9022-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9023-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9024-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9025-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9026-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-9039-1 Linux kernel (Azure CVM) vulnerabilities
Ubuntu USN Ubuntu USN USN-9040-1 Linux kernel (Low Latency NVIDIA) vulnerabilities
Ubuntu USN Ubuntu USN USN-9066-1 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-9091-1 Linux kernel (NVIDIA Tegra) vulnerabilities
History
Type Values Removed Values Added
Weaknesses CWE-362
CWE-754
Type Values Removed Values Added
Weaknesses CWE-772
References
Metrics threat_severity

None

cvssV3_1

{'score': 3.3, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L'}

threat_severity

Low

Type Values Removed Values Added
Weaknesses CWE-362
CWE-754
Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: reclaim an empty proto on the error path Two racing tc filter add requests on the same chain/prio of an unlocked classifier both run change() on the shared proto and both can fail: the winner's tcf_chain_tp_delete_empty() attempt gives up because the loser's handle is still in the idr, and the loser's error path drops only its own reference without a second reclamation attempt. The empty proto stays linked in the chain, holding the chain reference, a block reference and the classifier module reference until the chain or block is torn down. Reclaim the proto on the error path of any failed request that holds a proto reference. The reclamation is emptiness-gated: tcf_chain_tp_delete_empty() unlinks the proto only when delete_empty() admits it is empty, so a live shared proto is never unlinked. A proto the request created is reclaimed unconditionally - it is the only owner, so marking it for deletion is safe even without a delete_empty callback. Classifiers without one (the check marks the proto unconditionally) are rtnl-serialized, so the raced window this guard closes cannot arise for them. This is a follow-up to commit d4e359b3608a ("net/sched: cls_api: fix teardown of an adopted proto on insert-race loss"), which stopped the loser of the insert race from unlinking the winner's live proto but left the empty-proto residual in place. Conditions to recreate: - CONFIG_NET_CLS_FLOWER=y; veth pair - tc qdisc add dev veth0 ingress - two concurrent `tc filter add dev veth0 ingress protocol ip pref 1 flower skip_sw ... action drop` (both fail in fl_hw_replace_filter after publishing their handle in the idr); repeat in a loop - an empty flower tp stays linked after both requests fail; visible as a bare `filter protocol ip pref 1 flower chain 0` header in `tc filter show` with no filter entries - CAP_NET_ADMIN (namespace-local via unshare -Urn suffices)
Title net/sched: cls_api: reclaim an empty proto on the error path
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References
Weaknesses

Sources

Status
PUBLISHED
Assigner
Linux
Published
Updated
Oct 30, 2026, 12:39 PM
Reserved
Sep 25, 2026, 10:25 AM
Status
Received
Published
Oct 18, 2026, 4:17 PM
Modified
Oct 30, 2026, 1:21 PM
Severity
Low
Public date
Oct 18, 2026, 12:00 AM