{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.12-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  HID: pidff: fix OOB write when hid-\u003einputs is empty  hid_pidff_init_with_quirks() derives its input_dev from  \tlist_entry(hid-\u003einputs.next, struct hid_input, list)  without first checking that hid-\u003einputs is non-empty.  The list member of struct hid_input is at offset 0, so on an empty list list_entry() yields \u0026hid-\u003einputs itself and the following hidinput-\u003einput 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-\u003effbit) 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 \u0026 ~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-\u003einputs 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 are required.  KASAN reports an 8-byte out-of-bounds write in hid_pidff_init_with_quirks() reached from universal_pidff_probe().  Check for an empty list before deriving dev and return -ENODEV, as the other HID force-feedback drivers already do.  universal_pidff_probe() propagates the error and unwinds.  Discovered by XBOW, triaged by Baul Lee \u003cbaul.lee@xbow.com\u003e",
  "id": "DEBIAN-CVE-2026-80780",
  "modified": "2026-09-14T16:47:38.113206250Z",
  "published": "2026-09-04T16:18:03.723Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-80780"
    }
  ],
  "upstream": [
    "CVE-2026-80780"
  ]
}