DEBIAN-CVE-2026-90001

See a problem?
Please try reporting it to the source first.

Source

https://security-tracker.debian.org/tracker/CVE-2026-90001

Import Source

https://storage.googleapis.com/debian-osv/debian-cve-osv/DEBIAN-CVE-2026-90001.json

JSON Data

https://api.osv.dev/v1/vulns/DEBIAN-CVE-2026-90001

Upstream

CVE-2026-90001

Published

2026-09-16T11:17:11Z

Modified

2026-09-17T05:00:45Z

Severity

7.8 (High) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H CVSS Calculator

Summary

[none]

Details

In the Linux kernel, the following vulnerability has been resolved: HID: bpf: serialize device reference release in struct_ops destroy path __hid_bpf_ops_destroy_device() and hid_bpf_unreg() can race on the same registration reference, double-putting struct hid_device and freeing it while hid_destroy_device() still uses it. Serialize the remove/NULL decision under hdev->bpf.prog_list_lock so exactly one path releases each registration reference: unreg re-checks ops->hdev under the lock and returns without putting when the destroy path already cleared it; all put_device() calls happen after the lock is dropped, which is safe because a concurrent unreg then observes ops->hdev == NULL under the lock. Background: each successful attach (hid_bpf_ops_reg) acquires one device reference (hid_get_device()). Two paths can release it: - device destruction: hid_destroy_device() -> hid_bpf_destroy_device() -> __hid_bpf_ops_destroy_device(), which walks hdev->bpf.prog_list under rcu_read_lock() and drops one reference per attached program; - BPF link release: bpf map delete (no BPF_F_LINK) synchronously calls st_ops->unreg() -> hid_bpf_unreg(), which drops the reference for its own registration. The coordination handshake (e->hdev = NULL on the destroy side vs "if (!hdev) return" on the unreg side) is a TOCTOU check: the two paths run under different lock domains (rcu_read_lock vs prog_list_lock), so a concurrent unreg can read ops->hdev as non-NULL, block on prog_list_lock, and then proceed while the destroy traversal executes - both paths then drop the same reference. The refcount reaches zero legitimately (each decrement is individually valid), so no refcount_t saturation fires: the device is simply freed while the transport is still inside hid_destroy_device(), and subsequent teardown touches freed memory. The fix serializes the remove/NULL decision under prog_list_lock on both sides and moves the destroy-side puts outside the lock. With the lock held, plain reads/writes of ops->hdev are sufficient; no READ_ONCE/WRITE_ONCE are added, keeping the patch minimal. Unlocked-read safety: the unlocked read of ops->hdev at the top of hid_bpf_unreg() cannot touch a freed device, because the unreg path itself still holds this registration's reference (released only by its own hid_put_device() after the lock is dropped), and a destroy traversal that already cleared ops->hdev makes the lock-internal re-check return early without any put. At most one of the two paths releases each registration reference.

References

https://security-tracker.debian.org/tracker/CVE-2026-90001

Affected packages

Debian:13 / linux

Package

Name: linux
Purl: pkg:deb/debian/linux?arch=source&distro=trixie

Affected ranges

Type: ECOSYSTEM
Events: Introduced

0 Unknown introduced version / All previous versions are affected

Affected versions

6.*

6.12.38-1

6.12.41-1

6.12.43-1~bpo12+1

6.12.43-1

6.12.48-1

6.12.57-1~bpo12+1

6.12.57-1

6.12.63-1~bpo12+1

6.12.63-1

6.12.69-1~bpo12+1

6.12.69-1

6.12.73-1~bpo12+1

6.12.73-1

6.12.74-1

6.12.74-2~bpo12+1

6.12.74-2

6.12.85-1~bpo12+1

6.12.85-1

6.12.86-1~bpo12+1

6.12.86-1

6.12.88-1~bpo12+1

6.12.88-1

6.12.90-1~bpo12+1

6.12.90-1

6.12.90-2~bpo12+1

6.12.90-2

6.12.94-1~bpo12+1

6.12.94-1

6.12.95-1~bpo12+1

6.12.95-1

6.12.96-1

6.12.100-1

6.12.101-1

6.12.105-1

6.12.107-1

6.13~rc6-1~exp1

6.13~rc7-1~exp1

6.13.2-1~exp1

6.13.3-1~exp1

6.13.4-1~exp1

6.13.5-1~exp1

6.13.6-1~exp1

6.13.7-1~exp1

6.13.8-1~exp1

6.13.9-1~exp1

6.13.10-1~exp1

6.13.11-1~exp1

6.14.3-1~exp1

6.14.5-1~exp1

6.14.6-1~exp1

6.15~rc7-1~exp1

6.15-1~exp1

6.15.1-1~exp1

6.15.2-1~exp1

6.15.3-1~exp1

6.15.4-1~exp1

6.15.5-1~exp1

6.15.6-1~exp1

6.16~rc7-1~exp1

6.16-1~exp1

6.16.1-1~exp1

6.16.3-1~bpo13+1

6.16.3-1

6.16.5-1

6.16.6-1

6.16.7-1

6.16.8-1

6.16.9-1

6.16.10-1

6.16.11-1

6.16.12-1~bpo13+1

6.16.12-1

6.16.12-2

6.17.2-1~exp1

6.17.5-1~exp1

6.17.6-1

6.17.7-1

6.17.7-2

6.17.8-1~bpo13+1

6.17.8-1

6.17.9-1

6.17.10-1

6.17.11-1

6.17.12-1

6.17.13-1~bpo13+1

6.17.13-1

6.18~rc4-1~exp1

6.18~rc4-1~exp2

6.18~rc5-1~exp1

6.18~rc6-1~exp1

6.18~rc7-1~exp1

6.18.1-1~exp1

6.18.2-1~exp1

6.18.3-1

6.18.5-1~bpo13+1

6.18.5-1

6.18.8-1

6.18.9-1~bpo13+1

6.18.9-1

6.18.10-1

6.18.12-1~bpo13+1

6.18.12-1

6.18.13-1

6.18.14-1

6.18.15-1~bpo13+1

6.18.15-1

6.19~rc4-1~exp1

6.19~rc5-1~exp1

6.19~rc6-1~exp1

6.19~rc7-1~exp1

6.19~rc8-1~exp1

6.19-1~exp1

6.19.2-1~exp1

6.19.3-1~exp1

6.19.4-1~exp1

6.19.5-1~exp1

6.19.6-1

6.19.6-2~bpo13+1

6.19.6-2

6.19.8-1~bpo13+1

6.19.8-1

6.19.10-1~bpo13+1

6.19.10-1

6.19.11-1~bpo13+1

6.19.11-1

6.19.12-1

6.19.13-1~bpo13+1

6.19.13-1

6.19.14-1~bpo13+1

6.19.14-1

7.*

7.0-1~exp1

7.0.1-1~exp1

7.0.3-1

7.0.4-1~bpo13+1

7.0.4-1

7.0.7-1~bpo13+1

7.0.7-1

7.0.9-1~bpo13+1

7.0.9-1

7.0.10-1~bpo13+1

7.0.10-1

7.0.12-1

7.0.12-2~bpo13+1

7.0.12-2

7.0.13-1~bpo13+1

7.0.13-1

7.0.14-1

7.1~rc2-1~exp1

7.1~rc3-1~exp1

7.1~rc4-1~exp1

7.1~rc4-1~exp2

7.1~rc5-1~exp1

7.1~rc7-1~exp1

7.1.1-1~exp1

7.1.2-1~exp1

7.1.3-1~bpo13+1

7.1.3-1

7.1.3-1+sunvdc

7.1.4-1

7.1.5-1

7.1.6-1

7.1.7-1~bpo13+1

7.1.7-1

7.1.8-1~bpo13+1

7.1.8-1

7.1.8-2

7.1.9-1

7.1.9-1+sparc64

7.1.10-1

7.1.12-1

7.1.13-1

7.2~rc3-1~exp1

7.2~rc5-1~exp1

7.2~rc7-1~exp1

7.2.2-1~exp1

7.2.3-1~exp1

7.2.6-1

Ecosystem specific

{
    "urgency": "not yet assigned"
}

Database specific

source

"https://storage.googleapis.com/debian-osv/debian-cve-osv/DEBIAN-CVE-2026-90001.json"

Debian:14 / linux