GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-4HX6-RX69-CJ3H

Vulnerability from github – Published: 2026-09-04 18:31 – Updated: 2026-09-04 18:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

HID: nintendo: fix out-of-bounds read in joycon_ctlr_read_handler()

joycon_ctlr_read_handler() casts an incoming HID input report to struct joycon_input_report and parses it, guarding the cast only with a 12-byte length check:

if (size >= 12) /* make sure it contains the input report */
    joycon_parse_report(ctlr, (struct joycon_input_report *)data);

struct joycon_input_report is 49 bytes: a 13-byte header followed by a union whose IMU arm is 36 bytes. For an IMU report joycon_parse_report() -> joycon_parse_imu_report() walks that union (struct offsets 13..48), so a report of exactly 12 bytes with data[0] == JC_INPUT_IMU_DATA passes the guard yet is read up to 37 bytes past its declared length. The over-read bytes are decoded into accelerometer/gyroscope values and forwarded to userspace through the "(IMU)" input device, leaking driver-internal memory. data[0] and size are fully controlled by a malicious or spoofed Joy-Con/Pro Controller.

Receive buffers are sized to the maximum report length, so this is an over-read within the allocation rather than a slab OOB, but the decoded bytes still reach userspace.

The sibling subcmd path in joycon_ctlr_handle_event() already bounds the same cast correctly:

if (size < sizeof(struct joycon_input_report) ||
    data[0] != JC_INPUT_SUBCMD_REPLY)
    break;

Use the same sizeof(struct joycon_input_report) bound here.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-80772"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-04T16:18:02Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: nintendo: fix out-of-bounds read in joycon_ctlr_read_handler()\n\njoycon_ctlr_read_handler() casts an incoming HID input report to\nstruct joycon_input_report and parses it, guarding the cast only with a\n12-byte length check:\n\n\tif (size \u003e= 12) /* make sure it contains the input report */\n\t\tjoycon_parse_report(ctlr, (struct joycon_input_report *)data);\n\nstruct joycon_input_report is 49 bytes: a 13-byte header followed by a\nunion whose IMU arm is 36 bytes. For an IMU report joycon_parse_report()\n-\u003e joycon_parse_imu_report() walks that union (struct offsets 13..48),\nso a report of exactly 12 bytes with data[0] == JC_INPUT_IMU_DATA passes\nthe guard yet is read up to 37 bytes past its declared length. The\nover-read bytes are decoded into accelerometer/gyroscope values and\nforwarded to userspace through the \"(IMU)\" input device, leaking\ndriver-internal memory. data[0] and size are fully controlled by a\nmalicious or spoofed Joy-Con/Pro Controller.\n\nReceive buffers are sized to the maximum report length, so this is an\nover-read within the allocation rather than a slab OOB, but the decoded\nbytes still reach userspace.\n\nThe sibling subcmd path in joycon_ctlr_handle_event() already bounds the\nsame cast correctly:\n\n\tif (size \u003c sizeof(struct joycon_input_report) ||\n\t    data[0] != JC_INPUT_SUBCMD_REPLY)\n\t\tbreak;\n\nUse the same sizeof(struct joycon_input_report) bound here.",
  "id": "GHSA-4hx6-rx69-cj3h",
  "modified": "2026-09-04T18:31:25Z",
  "published": "2026-09-04T18:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80772"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/27b376b945c0aac46fcdfcc950b14a85b874b557"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/33ea29f8b6141f2d265de807e110a6435b355cb0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/34725ed4719da424113db8449fb5485aaf71a913"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/51cfd1adbe7a46bb08af162abb3ab3b6820e2d15"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/addca61f9a23c0d20a387c2040e70479f54518e1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bd397c4123a4bc084913d8c7fdb40ef94e9f8172"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d4cabd4089adb59cf7974915737c52cc47a9bb1b"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…