HID: pidff: fix OOB write when hid->inputs is empty
In the Linux kernel, the following vulnerability has been resolved: HID: pidff: fix OOB write when hid->inputs is empty hid_pidff_init_with_quirks() derives its input_dev from list_entry(hid->inputs.next, struct hid_input, list) without first checking that hid->inputs is non-empty. The list member of struct hid_input is at offset 0, so on an empty list list_entry() yields &hid->inputs itself and the following hidinput->input load reads an unrelated member of struct hid_device. dev is then a type-confused pointer, and force-feedback init writes through it: each set_bit(FF_*, dev->ffbit) stores 8 bytes at dev + 192, past the end of the object dev actually aliases, and input_ff_create() adds further writes of a heap pointer and two function pointers. Until hid-universal-pidff the only caller was hid_pidff_init() from usbhid, which runs under HID_CLAIMED_INPUT and therefore always has at least one hid_input. universal_pidff_probe() starts the device with HID_CONNECT_DEFAULT & ~HID_CONNECT_FF and then calls hid_pidff_init_with_quirks() directly whenever the descriptor carries a PID usage page, bypassing that gate. A report descriptor whose only application collection is on HID_UP_PID leaves hid->inputs empty while hid_connect() still succeeds through the hidraw claim, so probe reaches the unguarded list_entry(). The write happens in the USB probe path, on the hotplug workqueue, so plugging in a malicious device is enough to trigger it; no attacker software and no logged-in user ar
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.12.108, 6.18.47, 6.6.156, 7.1.11, 7.2.1
- CVEs
- CVE-2026-80780
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 19:49 UTC · Revision 1
Source evidence
HID: pidff: fix OOB write when hid->inputs is empty
core-osv · Original sourcePublished 4 Sept 2026, 15:12 UTC
In the Linux kernel, the following vulnerability has been resolved: HID: pidff: fix OOB write when hid->inputs is empty hid_pidff_init_with_quirks() derives its input_dev from list_entry(hid->inputs.next, struct hid_input, list) without first checking that hid->inputs is non-empty. The list member of struct hid_input is at offset 0, so on an empty list list_entry() yields &hid->inputs itself and the following hidinput->input load reads an unrelated member of struct hid_device. dev is then a type-confused pointer, and force-feedback init writes through it: each set_bit(FF_*, dev->ffbit) stores 8 bytes at dev + 192, past the end of the object dev actually aliases, and input_ff_create() adds further writes of a heap pointer and two function pointers. Until hid-universal-pidff the only caller was hid_pidff_init() from usbhid, which runs under HID_CLAIMED_INPUT and therefore always has at least one hid_input. universal_pidff_probe() starts the device with HID_CONNECT_DEFAULT & ~HID_CONNECT_FF and then calls hid_pidff_init_with_quirks() directly whenever the descriptor carries a PID usage page, bypassing that gate. A report descriptor whose only application collection is on HID_UP_PID leaves hid->inputs empty while hid_connect() still succeeds through the hidraw claim, so probe reaches the unguarded list_entry(). The write happens in the USB probe path, on the hotplug workqueue, so plugging in a malicious device is enough to trigger it; no attacker software and no logged-in user ar
osv:CVE-2026-80780
Kernel
Fixed versions: 6.6.156, 6.12.108, 6.18.47, 7.1.11, 7.2.1
Complete source record
{
"id": "ec77f83ae0ad26e5be447683123d91e196eee3a341f77b2da2a1afd888bb68de",
"url": "https://osv.dev/vulnerability/CVE-2026-80780",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "HID: pidff: fix OOB write when hid->inputs is empty",
"summary": "In the Linux kernel, the following vulnerability has been resolved: HID: pidff: fix OOB write when hid->inputs is empty hid_pidff_init_with_quirks() derives its input_dev from list_entry(hid->inputs.next, struct hid_input, list) without first checking that hid->inputs is non-empty. The list member of struct hid_input is at offset 0, so on an empty list list_entry() yields &hid->inputs itself and the following hidinput->input load reads an unrelated member of struct hid_device. dev is then a type-confused pointer, and force-feedback init writes through it: each set_bit(FF_*, dev->ffbit) stores 8 bytes at dev + 192, past the end of the object dev actually aliases, and input_ff_create() adds further writes of a heap pointer and two function pointers. Until hid-universal-pidff the only caller was hid_pidff_init() from usbhid, which runs under HID_CLAIMED_INPUT and therefore always has at least one hid_input. universal_pidff_probe() starts the device with HID_CONNECT_DEFAULT & ~HID_CONNECT_FF and then calls hid_pidff_init_with_quirks() directly whenever the descriptor carries a PID usage page, bypassing that gate. A report descriptor whose only application collection is on HID_UP_PID leaves hid->inputs empty while hid_connect() still succeeds through the hidraw claim, so probe reaches the unguarded list_entry(). The write happens in the USB probe path, on the hotplug workqueue, so plugging in a malicious device is enough to trigger it; no attacker software and no logged-in user ar",
"evidence": "osv:CVE-2026-80780",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.6.156",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.108",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.47",
"evidence": "/affected/1/ranges"
},
{
"value": "7.1.11",
"evidence": "/affected/1/ranges"
},
{
"value": "7.2.1",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-80780",
"aliases": [
"CVE-2026-80780"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "c1fde337b317f0a226de92803288741c30799eb0"
},
{
"fixed": "2e0471bf3ab2a6b7eedcc3b8a2a17286b6a9ae1a"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "f45f26a6b3e7260c129c7c6bb0ace63aeb7b3868"
},
{
"fixed": "ad9330f7e74a97842815a291a0d7389ed2f34504"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "f06bf8d94fffbb544b1cb5402c92e0a075f0d420"
},
{
"fixed": "4529c03c3da8f91392cd630453452f569973f4cd"
},
{
"fixed": "d416eeb7d016d82af67c149d884bc6a9323c4ac7"
},
{
"fixed": "86b63adfa5e132beac4be72668fdf9128fe51d2e"
},
{
"fixed": "67bb1074e3d2d12fa059a9cc707e89398a4e4704"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "6.6.88"
},
{
"fixed": "6.6.156"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "6.12.24"
},
{
"fixed": "6.12.108"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "6.13.12"
},
{
"fixed": "6.14"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "6.14.3"
},
{
"fixed": "6.15"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "af9f2471dfe5a48384f5b7f021a673fbc741465e"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "b797352954eee6dc084cfaed0659dea60adfb484"
}
]
}
],
"versions": [
"v6.6.155",
"v6.6.154",
"v6.6.153",
"v6.6.152",
"v6.6.151",
"v6.6.150",
"v6.6.149",
"v6.6.148",
"v6.6.147",
"v6.6.146",
"v6.6.145",
"v6.6.144",
"v6.6.143",
"v6.6.142",
"v6.6.141",
"v6.6.140",
"v6.6.139",
"v6.6.138",
"v6.6.137",
"v6.6.136",
"v6.6.135",
"v6.6.134",
"v6.6.133",
"v6.6.132",
"v6.6.131",
"v6.6.130",
"v6.6.129",
"v6.6.128",
"v6.6.127",
"v6.6.126",
"v6.6.125",
"v6.6.124",
"v6.6.123",
"v6.6.122",
"v6.6.121",
"v6.6.120",
"v6.6.119",
"v6.6.118",
"v6.6.117",
"v6.6.116",
"v6.6.115",
"v6.6.114",
"v6.6.113",
"v6.6.112",
"v6.6.111",
"v6.6.110",
"v6.6.109",
"v6.6.108",
"v6.6.107",
"v6.6.106",
"v6.6.105",
"v6.6.104",
"v6.6.103",
"v6.6.102",
"v6.6.101",
"v6.6.100",
"v6.6.99",
"v6.6.98",
"v6.6.97",
"v6.6.96",
"v6.6.95",
"v6.6.94",
"v6.6.93",
"v6.6.92",
"v6.6.91",
"v6.6.90",
"v6.6.89",
"v6.6.88",
"v6.12.107",
"v6.12.106",
"v6.12.105",
"v6.12.104",
"v6.12.103",
"v6.12.102",
"v6.12.101",
"v6.12.100",
"v6.12.99",
"v6.12.98",
"v6.12.97",
"v6.12.96",
"v6.12.95",
"v6.12.94",
"v6.12.93",
"v6.12.92",
"v6.12.91",
"v6.12.90",
"v6.12.89",
"v6.12.88",
"v6.12.87",
"v6.12.86",
"v6.12.85",
"v6.12.84",
"v6.12.83",
"v6.12.82",
"v6.12.81",
"v6.12.80",
"v6.12.79",
"v6.12.78",
"v6.12.77",
"v6.12.76",
"v6.12.75",
"v6.12.74",
"v6.12.73",
"v6.12.72",
"v6.12.71",
"v6.12.70",
"v6.12.69",
"v6.12.68",
"v6.12.67",
"v6.12.66",
"v6.12.65",
"v6.12.64",
"v6.12.63",
"v6.12.62",
"v6.12.61",
"v6.12.60",
"v6.12.59",
"v6.12.58",
"v6.12.57",
"v6.12.56",
"v6.12.55",
"v6.12.54",
"v6.12.53",
"v6.12.52",
"v6.12.51",
"v6.12.50",
"v6.12.49",
"v6.12.48",
"v6.12.47",
"v6.12.46",
"v6.12.45",
"v6.12.44",
"v6.12.43",
"v6.12.42",
"v6.12.41",
"v6.12.40",
"v6.12.39",
"v6.12.38",
"v6.12.37",
"v6.12.36",
"v6.12.35",
"v6.12.34",
"v6.12.33",
"v6.12.32",
"v6.12.31",
"v6.12.30",
"v6.12.29",
"v6.12.28",
"v6.12.27",
"v6.12.26",
"v6.12.25",
"v6.12.24",
"v6.13.12",
"v6.14.11",
"v6.14.10",
"v6.14.9",
"v6.14.8",
"v6.14.7",
"v6.14.6",
"v6.14.5",
"v6.14.4",
"v6.14.3"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-80780.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.156"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.108"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.47"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.15.0"
},
{
"fixed": "7.1.11"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.2.1"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-80780.json"
}
}
],
"modified": "2026-10-28T02:30:38.844236740Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/2e0471bf3ab2a6b7eedcc3b8a2a17286b6a9ae1a",
"https://git.kernel.org/stable/c/4529c03c3da8f91392cd630453452f569973f4cd",
"https://git.kernel.org/stable/c/67bb1074e3d2d12fa059a9cc707e89398a4e4704",
"https://git.kernel.org/stable/c/86b63adfa5e132beac4be72668fdf9128fe51d2e",
"https://git.kernel.org/stable/c/ad9330f7e74a97842815a291a0d7389ed2f34504",
"https://git.kernel.org/stable/c/d416eeb7d016d82af67c149d884bc6a9323c4ac7",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80780.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-80780",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80780.json"
}
},
"related_cves": [
{
"value": "CVE-2026-80780",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 506351,
"published_at": "2026-09-04T15:12:52.009+00:00"
}