{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-80780 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-80780 is a memory corruption vulnerability in Linux, published on 4 Sep 2026. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link."},"fix_prompt":"Check this codebase for CVE-2026-80780 and fix it if it is affected.\n\nWhat it is: CVE-2026-80780 is a memory corruption vulnerability in Linux, published on 4 Sep 2026. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link.\nExploitation: There is no known exploitation of CVE-2026-80780 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-80780/ (Markdown: https://insights.sbomify.com/CVE-2026-80780/index.md)","id":"CVE-2026-80780","markdown":"https://insights.sbomify.com/CVE-2026-80780/index.md","name":"CVE-2026-80780","record":{"aliases":["AZL-99650","BELL-CVE-2026-80780","DEBIAN-CVE-2026-80780","GHSA-rxff-7rcf-x4wj","UBUNTU-CVE-2026-80780"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["code_execution","privilege_escalation"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel HID driver","requires_auth":"none","summary":"A malicious USB device can trigger an out-of-bounds write in the Linux kernel HID driver, potentially allowing code execution or privilege escalation.","user_interaction":"required","vuln_class":"memory_corruption"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nHID: pidff: fix OOB write when hid-\u003einputs is empty\n\nhid_pidff_init_with_quirks() derives its input_dev from\n\n\tlist_entry(hid-\u003einputs.next, struct hid_input, list)\n\nwithout first checking that hid-\u003einputs is non-empty.  The list member\nof struct hid_input is at offset 0, so on an empty list list_entry()\nyields \u0026hid-\u003einputs itself and the following hidinput-\u003einput load reads\nan unrelated member of struct hid_device.  dev is then a type-confused\npointer, and force-feedback init writes through it: each\nset_bit(FF_*, dev-\u003effbit) stores 8 bytes at dev + 192, past the end of\nthe object dev actually aliases, and input_ff_create() adds further\nwrites of a heap pointer and two function pointers.\n\nUntil hid-universal-pidff the only caller was hid_pidff_init() from\nusbhid, which runs under HID_CLAIMED_INPUT and therefore always has at\nleast one hid_input.  universal_pidff_probe() starts the device with\nHID_CONNECT_DEFAULT \u0026 ~HID_CONNECT_FF and then calls\nhid_pidff_init_with_quirks() directly whenever the descriptor carries a\nPID usage page, bypassing that gate.  A report descriptor whose only\napplication collection is on HID_UP_PID leaves hid-\u003einputs empty while\nhid_connect() still succeeds through the hidraw claim, so probe reaches\nthe unguarded list_entry().\n\nThe write happens in the USB probe path, on the hotplug workqueue, so\nplugging in a malicious device is enough to trigger it; no attacker\nsoftware and no logged-in user are required.  KASAN reports an 8-byte\nout-of-bounds write in hid_pidff_init_with_quirks() reached from\nuniversal_pidff_probe().\n\nCheck for an empty list before deriving dev and return -ENODEV, as the\nother HID force-feedback drivers already do.  universal_pidff_probe()\npropagates the error and unwinds.\n\nDiscovered by XBOW, triaged by Baul Lee \u003cbaul.lee@xbow.com\u003e","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"HID: pidff: fix OOB write when hid-\u003einputs is empty","id":"CVE-2026-80780","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"memory_corruption","year":"2026"},"n_packages":0,"n_references":6,"next":{"headline":"HID: core: fix OOB read of field-\u003eusage in hid_set_field()","id":"CVE-2026-80781"},"packages":[],"prev":{"headline":"net/ionic: avoid OOB TX partner lookup for hwstamp RXQ","id":"CVE-2026-80779"},"products":["Linux"],"published":"2026-09-04","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-19","vendors":["Linux"]},"summary":"A malicious USB device can trigger an out-of-bounds write in the Linux kernel HID driver, potentially allowing code execution or privilege escalation.","url":"https://insights.sbomify.com/CVE-2026-80780/"}