[PATCH AUTOSEL 6.19-6.12] HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure

[PATCH AUTOSEL 6.19-6.12] HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure

[Sasha Levin]

From: Lee Jones <lee@kernel.org>

[ Upstream commit f7a4c78bfeb320299c1b641500fe7761eadbd101 ]

Presently, if the force feedback initialisation fails when probing the
Logitech G920 Driving Force Racing Wheel for Xbox One, an error number
will be returned and propagated before the userspace infrastructure
(sysfs and /dev/input) has been torn down.  If userspace ignores the
errors and continues to use its references to these dangling entities, a
UAF will promptly follow.

We have 2 options; continue to return the error, but ensure that all of
the infrastructure is torn down accordingly or continue to treat this
condition as a warning by emitting the message but returning success.
It is thought that the original author's intention was to emit the
warning but keep the device functional, less the force feedback feature,
so let's go with that.

Signed-off-by: Lee Jones <lee@kernel.org>
Reviewed-by: Günther Noack <gnoack@google.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The same bug exists in v6.6 - `hidpp_ff_init` failure leads to `ret`
being non-zero and the function returning error after userspace
interfaces are exported. The fix would need minor adaptation for v6.6
(the code structure is slightly different but the same logic applies).

Record: [Bug exists in all stable trees (v5.15+). In v6.6 and older, the
code structure is slightly different (g920_get_config is called
earlier), but the same hidpp_ff_init failure → error return path exists.
Backport may need minor adaptation for older trees.]

### Step 6.2: BACKPORT COMPLICATIONS
For v6.12 and later, the patch should apply cleanly (same code
structure). For v6.6 and v6.1, the code is slightly different but the
same fix (setting `ret = 0` after the warning) applies to the same
logical block.

Record: [Clean apply for 6.12.y; minor context adaptation needed for
6.6.y and older]

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
- **Subsystem**: HID (Human Interface Devices) - specifically the
  Logitech HID++ driver
- **Criticality**: IMPORTANT - USB input devices are common consumer
  hardware. The G920/G923 are popular gaming wheels.
- **Maintainer**: Benjamin Tissoires (who signed off on this patch)

Record: [HID/logitech-hidpp, IMPORTANT criticality, signed off by
subsystem maintainer]

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: DETERMINE WHO IS AFFECTED
Users of the Logitech G920 Driving Force Racing Wheel and G923 Xbox
version wheel. These are popular gaming peripherals.

Record: [Driver-specific: users of Logitech G920/G923 gaming wheels]

### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
- **Trigger**: Force feedback initialization fails during device probe.
  This can happen due to communication issues with the device, firmware
  quirks, or timing issues.
- **How common**: Not every plug-in, but not rare either (the original
  commit notes this is about a real failure path)
- **Unprivileged trigger**: Yes - plugging in a USB device or having it
  connected at boot

Record: [Triggered when FF init fails during probe; can happen during
normal device use; unprivileged (USB plug-in)]

### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
- **UAF**: Use-after-free when userspace continues to use dangling
  sysfs/input nodes after probe failure
- **Severity**: HIGH - UAF can lead to crashes, undefined behavior, and
  potentially security issues (exploitable from userspace via USB
  device)

Record: [Use-after-free → CRITICAL/HIGH severity. Can cause crashes,
potential security implications]

### Step 8.4: CALCULATE RISK-BENEFIT RATIO
- **BENEFIT**: HIGH - Prevents UAF for users of popular gaming hardware.
  Simple fix that also improves user experience (device works without FF
  instead of failing entirely).
- **RISK**: VERY LOW - 2 lines changed. Setting `ret = 0` is obviously
  correct. No new code paths, no locking changes, no API changes. Worst
  case: device appears to work but has no force feedback (which is the
  intended behavior stated in the commit message).

Record: [Benefit: HIGH (prevents UAF, improves UX). Risk: VERY LOW
(2-line change, obviously correct). Ratio: strongly favorable]

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**Evidence FOR backporting:**
- Fixes a use-after-free vulnerability (HIGH severity bug)
- Extremely small and surgical fix (2 lines: braces + `ret = 0;`)
- Obviously correct - matches the original author's intent
- Reviewed by Google engineer, signed off by HID subsystem maintainer
- Bug has existed since v5.5 (~6 years), affecting all active stable
  trees
- Affects real consumer hardware (Logitech G920/G923 gaming wheels)
- UAF is reachable from userspace (USB device plug-in)
- No regression risk - device remains functional, just without FF on
  failure
- Clean separation from other changes - standalone fix

**Evidence AGAINST backporting:**
- No explicit Cc: stable tag (expected for review candidates)
- No Fixes: tag (but the bug origin is clear from blame)
- May need minor context adaptation for older stable trees (6.6.y and
  earlier)

**UNRESOLVED QUESTIONS:**
- None significant

### Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. **Obviously correct and tested?** YES - reviewed, applied by
   maintainer, included in 7.0-rc5
2. **Fixes a real bug that affects users?** YES - UAF on G920/G923 probe
   failure
3. **Important issue?** YES - use-after-free (crash, potential security
   issue)
4. **Small and contained?** YES - 2 lines in 1 file
5. **No new features or APIs?** CORRECT - no new features
6. **Can apply to stable trees?** YES - cleanly for 6.12.y, with minor
   adaptation for older

### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Not an exception category - this is a straightforward bug fix that meets
the core stable criteria.

### Step 9.4: MAKE YOUR DECISION
This is a clear YES. A 2-line fix for a use-after-free vulnerability in
a popular USB gaming peripheral driver, reviewed by the subsystem
maintainer, with essentially zero regression risk.

## Verification

- [Phase 1] Parsed subject: "HID: logitech-hidpp:" subsystem, "Prevent"
  verb, UAF fix for FF init failure
- [Phase 1] Tags: Reviewed-by Günther Noack (Google), Signed-off-by
  Benjamin Tissoires (HID maintainer). No Fixes:, no Cc: stable
  (expected)
- [Phase 1] Commit body explicitly describes UAF scenario: error return
  after hid_connect() exports userspace interfaces
- [Phase 2] Diff: +3/-1 lines in drivers/hid/hid-logitech-hidpp.c,
  hidpp_probe() function. Adds braces + `ret = 0;`
- [Phase 2] Before: FF init failure → non-zero ret → probe returns error
  → userspace interfaces not torn down → UAF. After: FF init failure →
  ret=0 → probe succeeds → device works without FF
- [Phase 3] git blame: buggy pattern introduced in abdd3d0b344fdf (v5.5,
  2019-10-17), present in all active stable trees
- [Phase 3] git merge-base: confirmed abdd3d0b344fdf is ancestor of
  v5.5; 219ccfb60003a4 (refactored form) is in v6.7+ but not v6.6
- [Phase 3] Verified the same bug pattern exists in v6.6 by reading
  v6.6:drivers/hid/hid-logitech-hidpp.c lines 4538-4546
- [Phase 3] Author Lee Jones is a prolific kernel contributor with
  multiple HID patches
- [Phase 4] Lore: patch submitted 2026-02-27, reviewed without
  objections, applied by maintainer
- [Phase 5] HIDPP_QUIRK_CLASS_G920 applies to G920 (0xC262) and G923
  Xbox (matching 2 USB device entries)
- [Phase 5] hidpp_probe() is the standard USB device probe path, called
  during device enumeration
- [Phase 6] Bug exists in all stable trees (v5.15.y through v6.12.y).
  Code context differs slightly in v6.6 and older
- [Phase 7] HID subsystem, IMPORTANT criticality. Maintainer Benjamin
  Tissoires signed off
- [Phase 8] Severity: HIGH (UAF). Trigger: FF init failure during device
  probe. Risk: VERY LOW (2-line fix)

**YES**

 drivers/hid/hid-logitech-hidpp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index c3d53250a7604..65bfad405ac5b 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4487,10 +4487,12 @@ static int hidpp_probe(struct hid_device *hdev, const struct hid_device_id *id)
 		if (!ret)
 			ret = hidpp_ff_init(hidpp, &data);
 
-		if (ret)
+		if (ret) {
 			hid_warn(hidpp->hid_dev,
 		     "Unable to initialize force feedback support, errno %d\n",
 				 ret);
+			ret = 0;
+		}
 	}
 
 	/*
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.10] HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq

[Sasha Levin]

From: Benoît Sevens <bsevens@google.com>

[ Upstream commit 2f1763f62909ccb6386ac50350fa0abbf5bb16a9 ]

The wacom_intuos_bt_irq() function processes Bluetooth HID reports
without sufficient bounds checking. A maliciously crafted short report
can trigger an out-of-bounds read when copying data into the wacom
structure.

Specifically, report 0x03 requires at least 22 bytes to safely read
the processed data and battery status, while report 0x04 (which
falls through to 0x03) requires 32 bytes.

Add explicit length checks for these report IDs and log a warning if
a short report is received.

Signed-off-by: Benoît Sevens <bsevens@google.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have enough information for a complete analysis. Let me compile
everything.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem:** HID: wacom (HID subsystem, Wacom tablet driver)
- **Action verb:** "fix" — explicit bug fix
- **Summary:** Fix out-of-bounds read in wacom_intuos_bt_irq when
  processing short Bluetooth HID reports

### Step 1.2: Tags
- **Signed-off-by:** Benoît Sevens <bsevens@google.com> (author, Google
  — security researcher based on commit history)
- **Reviewed-by:** Jason Gerecke <jason.gerecke@wacom.com> (Wacom
  subsystem maintainer — strong endorsement)
- **Signed-off-by:** Jiri Kosina <jkosina@suse.com> (HID subsystem
  maintainer — merged the patch)
- **No Fixes: tag** — expected for commits under review
- **No Cc: stable** — expected
- **No Reported-by** — likely found through code audit/fuzzing by the
  Google security team

Record: Author is a Google security researcher (has other OOB fix
commits: ALSA, UVC). Reviewed by Wacom maintainer. Merged by HID
maintainer.

### Step 1.3: Commit Body
The bug: `wacom_intuos_bt_irq()` processes Bluetooth HID reports without
checking `len`. A short report causes out-of-bounds reads:
- Report 0x03 needs at least 22 bytes (offset 1 + 10 + 10 + 1 = 22)
- Report 0x04 needs at least 32 bytes (offset 1 + 10 + 10 + 10 + 1 = 32,
  due to fallthrough)
- The commit explicitly mentions "maliciously crafted short report" —
  security implication

Record: Clear security bug — a malicious Bluetooth device can trigger
OOB read. Failure mode is memory disclosure or crash.

### Step 1.4: Hidden Bug Fix Detection
Not hidden — explicitly labeled as a fix for out-of-bounds read. The
author even describes the exact byte thresholds.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files changed:** 1 (`drivers/hid/wacom_wac.c`)
- **Lines:** +10 added (two bounds-check blocks with `dev_warn` +
  `break`)
- **Functions modified:** `wacom_intuos_bt_irq`
- **Scope:** Single-file, single-function surgical fix

### Step 2.2: Code Flow Change
**Hunk 1 (case 0x04):**
- Before: Immediately calls `wacom_intuos_bt_process_data(wacom, data +
  1)` regardless of `len`
- After: Checks `len < 32`, warns and breaks if too short

**Hunk 2 (case 0x03):**
- Before: Immediately processes data at offset `i` regardless of `len`
- After: Checks `i == 1 && len < 22` (only when entering directly as
  0x03, not via fallthrough from 0x04), warns and breaks if too short

### Step 2.3: Bug Mechanism
**Category:** Buffer overflow / out-of-bounds read (memory safety)

The function accesses `data[i]` where `i` increments by 10 through
multiple `wacom_intuos_bt_process_data` calls. For report 0x03 (direct
entry, i=1): accesses up to data[21]. For report 0x04 (falls through):
accesses up to data[31]. If `len` is smaller than these values, this
reads beyond the allocated buffer.

With current code (post-5e013ad), `data = kmemdup(wacom->data, len,
GFP_KERNEL)` — heap OOB read.
With old code (pre-5e013ad), `unsigned char data[WACOM_PKGLEN_MAX]` +
`memcpy(data, wacom->data, len)` — reads uninitialized stack data beyond
`len`.

### Step 2.4: Fix Quality
- **Obviously correct:** Yes — the length checks match the exact data
  access patterns
- **Minimal:** Yes — 10 lines, only adds bounds checks
- **Regression risk:** Extremely low — only rejects malformed short
  reports
- **No red flags:** Single function, no API changes, no locking changes

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
The vulnerable code was introduced in commit `81af7e61a774e6` ("Input:
wacom - handle Intuos 4 BT in wacom.ko") by Benjamin Tissoires on
2014-08-06. This code was first released in **v3.18**. The bug has been
present for **~12 years** in every kernel version since.

### Step 3.2: Fixes Tag
No Fixes: tag present. The implicit fix target is 81af7e61a774e6 from
2014.

### Step 3.3: File History
The recent commit `5e013ad206895` ("HID: wacom: Remove static
WACOM_PKGLEN_MAX limit") went into v6.15 and changed the function from
using a stack buffer to `kmemdup`. This changes the context for the fix.
Stable trees v6.14 and earlier have the old stack-buffer code.

### Step 3.4: Author
Benoît Sevens (bsevens@google.com) has other security-fix commits:
- `b909df18ce2a9` "ALSA: usb-audio: Fix potential out-of-bound accesses
  for Extigy and Mbox devices"
- `ecf2b43018da9` "media: uvcvideo: Skip parsing frames of type
  UVC_VS_UNDEFINED"
- `082dd785e2086` "media: uvcvideo: Refactor frame parsing code"

This is consistent with a Google security researcher systematically
finding OOB bugs.

### Step 3.5: Dependencies
The fix itself is standalone — it only adds `if (len < N) break;`
checks. However, for stable trees prior to v6.15, the context will
differ (stack buffer vs kmemdup). The fix should still apply with minor
context adjustment.

---

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1: Lore Search
Found the patch at `https://lore.kernel.org/all/20260303135828.2374069-
1-bsevens@google.com/`. Replies from Jason Gerecke (2026-03-06) and Jiri
Kosina (2026-03-09). No Cc: stable in the original submission. The patch
was accepted and included in a HID pull request for 7.0-rc5 (i.e.,
6.19-rc5).

### Step 4.2: Bug Report
No separate bug report link — this appears to be found through code
audit by the Google security team.

### Step 4.3-4.4: Related Patches / Stable Discussion
This is a standalone single-patch fix. No evidence of related series or
prior stable discussion.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Functions Modified
- `wacom_intuos_bt_irq` — the only function modified

### Step 5.2: Callers
`wacom_intuos_bt_irq` is called from one location:
- `drivers/hid/wacom_wac.c:3490` in the `INTUOS4WL` case of the main
  wacom IRQ handler

This is the Bluetooth HID report interrupt handler for the Wacom Intuos
4 Wireless tablet. It's triggered every time the device sends a
Bluetooth HID report.

### Step 5.3-5.4: Call Chain
The call chain is: HID subsystem receives BT report → `wacom_raw_event`
→ `wacom_wac_irq` → `wacom_intuos_bt_irq`. This is directly reachable
from any Bluetooth HID device claiming to be an Intuos 4 WL tablet. A
malicious BT device can send arbitrary short reports to trigger this.

### Step 5.5: Similar Patterns
Other wacom IRQ handlers (like `wacom_intuos_irq`) may have similar
issues but are not addressed by this commit.

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy Code in Stable Trees
The buggy code (81af7e61a774e6) has been in the kernel since v3.18
(2014). It exists in **ALL** active stable trees (5.10.y, 5.15.y, 6.1.y,
6.6.y, 6.12.y, 6.14.y).

### Step 6.2: Backport Complications
- For v6.15+ stable trees: the fix should apply cleanly (same kmemdup
  code)
- For v6.14 and earlier: the surrounding context differs (stack buffer
  `unsigned char data[WACOM_PKGLEN_MAX]` + `memcpy` instead of
  `kmemdup`). The bounds-check additions themselves are the same, but
  the diff context won't match. Minor adaptation needed.

### Step 6.3: Related Fixes
No prior fix for this issue in any stable tree.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem
- **Subsystem:** HID / Wacom driver (drivers/hid/)
- **Criticality:** IMPORTANT — Wacom tablets are widely used by artists,
  designers, and professionals. Bluetooth variant is common for wireless
  tablets.

### Step 7.2: Activity
The wacom driver is actively maintained by Jason Gerecke, with regular
commits. 43 commits since v5.15.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who Is Affected
Users of Wacom Intuos 4 Wireless (Bluetooth) tablets. Also any system
with Bluetooth HID enabled where a malicious device could pair.

### Step 8.2: Trigger Conditions
- A malicious or malfunctioning Bluetooth HID device sends a short
  report (< 22 or < 32 bytes) with report ID 0x03 or 0x04
- This can be triggered by an unprivileged attacker within Bluetooth
  range
- No special configuration needed — just BT HID enabled (very common)

### Step 8.3: Failure Mode Severity
- **Heap OOB read** (current mainline code with kmemdup) → potential
  info disclosure, crash → **CRITICAL**
- **Uninitialized stack data use** (older code with stack buffer) →
  potential info disclosure, incorrect behavior → **HIGH**
- This is a security-relevant vulnerability exploitable via Bluetooth
  proximity

### Step 8.4: Risk-Benefit
- **Benefit:** HIGH — fixes a security-relevant OOB read reachable via
  Bluetooth, present for 12 years
- **Risk:** VERY LOW — 10 lines of bounds checking, obviously correct,
  no behavioral change for well-formed reports
- **Ratio:** Strongly favorable for backport

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence
**FOR backporting:**
- Fixes out-of-bounds read — memory safety / security bug
- Bug present since v3.18 (2014) — affects all stable trees
- Exploitable via Bluetooth by any nearby device
- Author is a Google security researcher with track record of finding
  OOB bugs
- Reviewed by the Wacom subsystem maintainer (Jason Gerecke)
- Merged by the HID subsystem maintainer (Jiri Kosina)
- Fix is tiny (10 lines), obviously correct, zero regression risk
- No behavioral change for valid reports

**AGAINST backporting:**
- For stable trees < v6.15, minor context adaptation needed (stack
  buffer vs kmemdup) — manageable
- No explicit Cc: stable in original patch — expected for commits under
  review

### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** YES — simple bounds checks matching
   exact data access patterns, reviewed by maintainer
2. **Fixes a real bug?** YES — out-of-bounds read / security
   vulnerability
3. **Important issue?** YES — memory safety bug exploitable via
   Bluetooth
4. **Small and contained?** YES — 10 lines, single function, single file
5. **No new features or APIs?** Correct — only adds validation
6. **Can apply to stable?** YES for v6.15+; needs minor context
   adaptation for older trees

### Step 9.3: Exception Categories
Not an exception category — this is a standard security bug fix (the
primary category for stable).

### Step 9.4: Decision
This is a clear, small, security-relevant fix for an out-of-bounds read
in a Bluetooth HID handler. It has been present for 12 years, is
exploitable by a nearby attacker, was reviewed by the subsystem
maintainer, and carries essentially zero regression risk.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by Jason Gerecke (Wacom maintainer),
  SOB Jiri Kosina (HID maintainer), author from Google
- [Phase 1] Author commit history: confirmed 3 other OOB/security fix
  commits (ALSA, UVC)
- [Phase 2] Diff analysis: +10 lines, two bounds checks in
  `wacom_intuos_bt_irq()`, adds `if (len < 32) break;` and `if (i == 1
  && len < 22) break;`
- [Phase 2] Verified math: report 0x04 accesses data[1] through data[31]
  (1+10+10+10+1=32); report 0x03 accesses data[1] through data[21]
  (1+10+10+1=22)
- [Phase 3] git blame: buggy code introduced in 81af7e61a774e6
  (2014-08-06), confirmed in v3.18
- [Phase 3] git show 5e013ad206895: confirmed this changed stack buffer
  to kmemdup, went into v6.15; stable trees have old code
- [Phase 3] Confirmed 5e013ad not in v6.12, v6.13, v6.14 (via merge-
  base)
- [Phase 4] Lore: found patch at
  20260303135828.2374069-1-bsevens@google.com, accepted with replies
  from Gerecke and Kosina
- [Phase 5] Grep callers: `wacom_intuos_bt_irq` called from line 3490 in
  INTUOS4WL case — BT HID interrupt path
- [Phase 6] Bug exists in all stable trees (code from 2014)
- [Phase 8] Failure mode: heap OOB read (mainline) or uninitialized
  stack read (stable), severity CRITICAL/HIGH

**YES**

 drivers/hid/wacom_wac.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 9b2c710f8da18..da1f0ea85625d 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -1208,10 +1208,20 @@ static int wacom_intuos_bt_irq(struct wacom_wac *wacom, size_t len)
 
 	switch (data[0]) {
 	case 0x04:
+		if (len < 32) {
+			dev_warn(wacom->pen_input->dev.parent,
+				 "Report 0x04 too short: %zu bytes\n", len);
+			break;
+		}
 		wacom_intuos_bt_process_data(wacom, data + i);
 		i += 10;
 		fallthrough;
 	case 0x03:
+		if (i == 1 && len < 22) {
+			dev_warn(wacom->pen_input->dev.parent,
+				 "Report 0x03 too short: %zu bytes\n", len);
+			break;
+		}
 		wacom_intuos_bt_process_data(wacom, data + i);
 		i += 10;
 		wacom_intuos_bt_process_data(wacom, data + i);
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.12] HID: logitech-hidpp: Enable MX Master 4 over bluetooth

[Sasha Levin]

From: Adrian Freund <adrian@freund.io>

[ Upstream commit 70031e70ca15ede6a39db4d978e53a6cc720d454 ]

The Logitech MX Master 4 can be connected over bluetooth or through a
Logitech Bolt receiver. This change adds support for non-standard HID
features, such as high resolution scrolling when the mouse is connected
over bluetooth.
Because no Logitech Bolt receiver driver exists yet those features
won't be available when the mouse is connected through the receiver.

Signed-off-by: Adrian Freund <adrian@freund.io>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The table has grown but the addition is at the end before the terminator
`{}`. It should apply cleanly or with trivial context adjustment to any
stable tree.

Record: [Clean apply expected — insertion point is at end of table
before terminator]

### Step 6.3: RELATED FIXES IN STABLE
No related fixes — this is new hardware support.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1
- **Subsystem**: HID (Human Interface Devices) — input peripherals
- **Criticality**: IMPORTANT — mice are core input devices for desktop
  users

### Step 7.2
The HID subsystem and this driver specifically are actively maintained
with regular device ID additions.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: WHO IS AFFECTED
Users who own an MX Master 4 mouse and connect it via Bluetooth on
stable kernels. Without this patch, they don't get high-resolution
scrolling and other hidpp features.

### Step 8.2: TRIGGER CONDITIONS
Any user who connects an MX Master 4 over Bluetooth is affected.

### Step 8.3: FAILURE MODE
Without the patch: missing features (high-res scrolling). With the
patch: device works with full feature set. No crash, no security issue —
hardware enablement.

### Step 8.4: RISK-BENEFIT
- **Benefit**: MEDIUM — enables features for popular Logitech mouse (MX
  Master line is very popular)
- **Risk**: VERY LOW — 2-line device ID table addition, zero chance of
  regression
- **Ratio**: Favorable

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: EVIDENCE
**FOR backporting:**
- This is a NEW DEVICE ID addition — an explicit exception category for
  stable
- Trivially small (2 lines), obviously correct, follows exact pattern of
  dozens of prior entries
- Zero regression risk — only affects users who have this specific
  hardware
- MX Master 4 is a popular consumer mouse; users on stable kernels would
  benefit
- The same author successfully added MX Master 3 previously
- Merged by the HID subsystem maintainer (Jiri Kosina)

**AGAINST backporting:**
- This is not a bug fix — it's enabling new hardware support
- The mouse still works as a basic HID device without this; only
  advanced features are missing
- Strictly speaking, this adds new functionality rather than fixing a
  bug

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **YES** — trivial pattern match, merged
   by maintainer
2. Fixes a real bug? **NO** — enables hardware features, not a bug fix
3. Important issue? **N/A** — not a bug, but important for hardware
   support
4. Small and contained? **YES** — 2 lines
5. No new features? **This adds a device ID, which is an allowed
   exception**
6. Can apply to stable? **YES** — clean apply expected

### Step 9.3: EXCEPTION CATEGORIES
**YES — Device ID addition to existing driver.** This falls squarely
into the "NEW DEVICE IDs" exception category. Adding device IDs to
existing drivers is explicitly allowed in stable trees because they are
trivial additions that enable hardware support with zero risk.

### Step 9.4: DECISION
This is a textbook device ID addition — 2 lines adding a Bluetooth
product ID for the Logitech MX Master 4 to an existing, well-established
driver. The stable kernel rules explicitly allow this pattern. The risk
is essentially zero, and users with this popular mouse benefit from full
feature support.

## Verification
- [Phase 1] Parsed tags: Author Adrian Freund, merged by HID maintainer
  Jiri Kosina
- [Phase 2] Diff analysis: +2 lines adding HID_BLUETOOTH_DEVICE entry
  (0xb042) to hidpp_devices[] table
- [Phase 3] git blame: Device ID table exists since 2014, continuously
  expanded with similar entries
- [Phase 3] git log --author: Author previously added MX Master 3
  (commit 04bd68171e018)
- [Phase 3] git log: File actively maintained, 19+ changes since v6.6
- [Phase 5] No functions modified — pure data table addition
- [Phase 6] Driver exists in all active stable trees (since 2014)
- [Phase 7] HID subsystem, actively maintained, IMPORTANT criticality
- [Phase 8] Risk: VERY LOW (2-line table entry), Benefit: MEDIUM
  (popular hardware)

**YES**

 drivers/hid/hid-logitech-hidpp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 02d83c3bd73d4..c3d53250a7604 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4668,6 +4668,8 @@ static const struct hid_device_id hidpp_devices[] = {
 	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb038) },
 	{ /* Slim Solar+ K980 Keyboard over Bluetooth */
 	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb391) },
+	{ /* MX Master 4 mouse over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb042) },
 	{}
 };
 
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.18] HID: core: Mitigate potential OOB by removing bogus memset()

[Sasha Levin]

From: Lee Jones <lee@kernel.org>

[ Upstream commit 0a3fe972a7cb1404f693d6f1711f32bc1d244b1c ]

The memset() in hid_report_raw_event() has the good intention of
clearing out bogus data by zeroing the area from the end of the incoming
data string to the assumed end of the buffer.  However, as we have
previously seen, doing so can easily result in OOB reads and writes in
the subsequent thread of execution.

The current suggestion from one of the HID maintainers is to remove the
memset() and simply return if the incoming event buffer size is not
large enough to fill the associated report.

Suggested-by Benjamin Tissoires <bentiss@kernel.org>

Signed-off-by: Lee Jones <lee@kernel.org>
[bentiss: changed the return value]
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed to complete the analysis. Let me
compile the full assessment.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `HID: core:`
- Action verb: "Mitigate" (fix-oriented)
- Summary: Removes a memset() that causes OOB reads/writes when incoming
  HID event data is shorter than expected report size.
- Record: [HID core] [Mitigate/fix] [Remove memset that causes OOB
  memory corruption]

**Step 1.2: Tags**
- `Suggested-by: Benjamin Tissoires <bentiss@kernel.org>` — HID co-
  maintainer suggested the approach
- `Signed-off-by: Lee Jones <lee@kernel.org>` — author
- `[bentiss: changed the return value]` — maintainer modified the return
  value
- `Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>` — applied by
  HID maintainer
- No Fixes: tag (expected for candidates)
- No Cc: stable (expected)
- No Reported-by tag
- Record: Suggested and accepted by the HID co-maintainer. Strong
  endorsement.

**Step 1.3: Commit Body**
- Bug: The `memset()` in `hid_report_raw_event()` zeros from `cdata +
  csize` to `cdata + rsize` when `csize < rsize`. However, the actual
  buffer may not be `rsize` bytes — it could be smaller, causing OOB
  writes.
- "as we have previously seen" — acknowledges a history of OOB issues
  from this code.
- The fix: reject short reports entirely with -EINVAL instead of zero-
  padding.
- Record: OOB writes from memset writing past actual buffer boundary.
  Longstanding known issue class.

**Step 1.4: Hidden Bug Fix Detection**
- Not hidden — explicitly describes an OOB vulnerability fix. The word
  "mitigate" and "OOB" make it clear.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Files: `drivers/hid/hid-core.c` (+4/-3 lines)
- Function: `hid_report_raw_event()`
- Scope: Single-file, single-function surgical fix
- Record: [1 file, net +1 line] [hid_report_raw_event()] [Single-file
  surgical fix]

**Step 2.2: Code Flow Change**
- BEFORE: When `csize < rsize`, the code logs a debug message and calls
  `memset(cdata + csize, 0, rsize - csize)` to zero-pad the buffer, then
  continues processing.
- AFTER: When `csize < rsize`, the code logs a rate-limited warning and
  returns `-EINVAL` via `goto out`, rejecting the short report entirely.
- Record: [Short report path: zero-pad and continue → reject and return
  -EINVAL]

**Step 2.3: Bug Mechanism**
- Category: **Buffer overflow / OOB write** (memory safety)
- Mechanism: `memset(cdata + csize, 0, rsize - csize)` writes zeros from
  the end of the actual received data to position `rsize`. But the
  underlying buffer (allocated by the transport layer) may only be
  `csize` bytes, meaning the memset writes past the buffer boundary.
- Additionally, subsequent code (like `hid_process_report`) reads up to
  `rsize` bytes from the buffer, causing OOB reads.
- Record: [OOB write from memset] [Buffer may be smaller than rsize,
  memset writes past end]

**Step 2.4: Fix Quality**
- Obviously correct: rejecting a too-short report is safer than
  attempting to zero-pad a buffer of unknown size.
- Minimal: 4 lines changed, net +1 line.
- Regression risk: Some devices that send short reports and relied on
  zero-padding will now have those reports rejected. Tissoires
  acknowledged this ("let's go with it and say sorry if we break some
  devices later on"), meaning the maintainer accepted this tradeoff.
- Record: [High quality, minimal fix] [Low regression risk, maintainer-
  accepted tradeoff]

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
- The buggy memset line traces to `85cdaf524b7dda` ("HID: make a bus
  from hid code") from 2008-05-16.
- This code has been present since Linux 2.6.26 — it exists in ALL
  active stable trees.
- Record: [Buggy code from 2008, present in all stable trees]

**Step 3.2: Fixes Tag**
- No Fixes: tag present. However, the memset dates to 85cdaf524b7dda
  (2008).

**Step 3.3: File History — Related Changes**
- 966922f26c7fb (2011): Fixed crash from rsize being too large
  (536870912) causing memset crash
- 5ebdffd250988 (2020): Fixed off-by-one in rsize calculation causing
  OOB memset
- b1a37ed00d790 (2023): Added `max_buffer_size` attribute to cap rsize
- ec61b41918587 (2022): Fixed shift-out-of-bounds in the processing
  after the memset
- Record: **Long history of OOB/crash bugs from this exact memset**.
  This is the definitive fix.

**Step 3.4: Author**
- Lee Jones is a prolific kernel contributor and has previously worked
  on HID buffer size hardening (b1a37ed00d790).
- Fix was suggested by and applied by Benjamin Tissoires, HID co-
  maintainer.
- Record: [Experienced author, maintainer-endorsed fix]

**Step 3.5: Dependencies**
- The fix uses `hid_warn_ratelimited`, introduced in commit
  1d64624243af8, which only entered v6.18.
- For stable trees < 6.18, this would need trivial adaptation (use
  `hid_warn` or `dev_warn_ratelimited` instead).
- The companion patch `e716edafedad4` (hid-multitouch report ID check)
  is independent — it adds a defense at the caller level, not a
  prerequisite.
- Record: [Minor dependency on hid_warn_ratelimited macro for older
  trees, trivially resolvable]

## PHASE 4: MAILING LIST RESEARCH

From the lore.kernel.org investigation:
- **v1 (2026-02-27)**: Initial version simply removed the memset
  entirely.
- **Tissoires review (2026-03-02)**: Pushed back — removing memset alone
  isn't enough because `hid_process_report()` would still read OOB.
  Suggested rejecting short reports entirely.
- **v3 (2026-03-09)**: Revised per Tissoires's feedback — now returns
  early with warning.
- **Tissoires final review (2026-03-16)**: Endorsed, changed return to
  -EINVAL, noted "works in 99% of cases" since transport layers allocate
  big enough buffers.
- Applied 2026-03-16, merged to Linus 2026-03-17.
- No explicit stable nomination, but no objections to backporting
  either.
- Record: [Thorough review by HID maintainer, iterated to correct
  approach, accepted]

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions Modified**
- `hid_report_raw_event()` — the core HID report processing function.

**Step 5.2: Callers**
- `__hid_input_report()` in hid-core.c (line 2144) — **THE main HID
  input path** for all HID devices
- `wacom_sys.c` — 3 call sites (Wacom tablet driver)
- `hid-gfrm.c` — Google Fiber Remote
- `hid-logitech-hidpp.c` — Logitech HID++
- `hid-primax.c` — Primax keyboards
- `hid-multitouch.c` — multitouch devices
- `hid-vivaldi-common.c` — Vivaldi keyboard
- Record: [Called from core HID input path and multiple drivers — very
  high impact surface]

**Step 5.3-5.4: Call Chain**
- USB HID: `hid_irq_in()` → `hid_input_report()` →
  `__hid_input_report()` → `hid_report_raw_event()`
- This is reachable from any USB HID device event — keyboards, mice,
  touchscreens, gamepads, etc.
- Also reachable from I2C-HID, BT-HID, and other transports.
- Record: [Reachable from any HID device input — universal impact]

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable?**
- The memset dates to 2008. Present in every stable tree.
- Record: [ALL active stable trees contain the buggy code]

**Step 6.2: Backport Complications**
- `hid_warn_ratelimited` only in v6.18+. For older stable trees, trivial
  substitution needed (e.g., `hid_warn`).
- The rest of the code context (csize, rsize, max_buffer_size, goto out)
  is identical in recent stable trees (verified: max_buffer_size was
  added in b1a37ed00d790 from 2023, present in 6.6+).
- Record: [Minor adaptation needed for < 6.18, clean apply otherwise]

**Step 6.3: Related Fixes in Stable**
- Previous mitigations (max_buffer_size capping, off-by-one fix) are in
  stable but didn't eliminate the fundamental OOB risk.
- Record: [No equivalent fix already in stable — this is the definitive
  solution]

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1: Subsystem Criticality**
- HID core — every keyboard, mouse, touchscreen, gamepad, etc. goes
  through this code.
- Criticality: **IMPORTANT** (affects virtually all desktop/laptop
  systems and many embedded devices)

**Step 7.2: Subsystem Activity**
- Very active — multiple fixes per release cycle.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
- Every system with HID devices (USB, Bluetooth, I2C) — essentially
  universal for desktops/laptops.

**Step 8.2: Trigger Conditions**
- A HID device sends a report shorter than the expected report size.
- Can be triggered by: malicious USB devices, faulty/buggy HID devices,
  or specific device configurations.
- Potentially exploitable via USB (e.g., BadUSB attacks).
- Record: [Trigger: short HID report] [Moderate likelihood for
  accidental, high for deliberate]

**Step 8.3: Failure Mode**
- **OOB write**: memset writes past buffer boundary → memory corruption,
  potential code execution
- **OOB read**: subsequent `hid_process_report()` reads past buffer →
  info leak or crash
- Severity: **CRITICAL** (OOB writes = security vulnerability, potential
  crash/corruption)

**Step 8.4: Risk-Benefit**
- Benefit: **VERY HIGH** — prevents OOB writes in a core, universally-
  used kernel path. Addresses a class of bugs that has caused multiple
  CVEs/crashes historically.
- Risk: **VERY LOW** — 4-line change, simple logic (reject vs. pad),
  maintainer acknowledged 99% of cases won't be affected, accepted the
  tradeoff.
- Ratio: Strongly favors backporting.

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Summary**

FOR backporting:
- Fixes OOB writes and reads (security-critical memory safety bug)
- In HID core — affects all HID users (universal impact)
- Very small change: 4 lines, single function, single file
- Bug exists since 2008 — present in ALL stable trees
- Long history of crashes/CVEs from this exact memset (966922f, 5ebdffd,
  ec61b41)
- Reviewed and applied by HID co-maintainer (Tissoires)
- Suggested by the maintainer himself
- Fix is the definitive solution after years of band-aid fixes

AGAINST backporting:
- Uses `hid_warn_ratelimited` not available before v6.18 (trivially
  adaptable)
- Tissoires noted potential for breaking devices relying on zero-padding
  (accepted risk)
- No explicit stable nomination (expected for candidates)

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — reviewed by maintainer,
   iterated through 3 versions
2. Fixes a real bug? **YES** — OOB write/read in HID core
3. Important issue? **YES** — security vulnerability (OOB write),
   potential crash/corruption
4. Small and contained? **YES** — 4 lines, single function
5. No new features or APIs? **YES** — behavior change only (reject
   instead of pad)
6. Can apply to stable? **YES** — with trivial adaptation for
   hid_warn_ratelimited

**Step 9.3: Exception Categories**
- Not an exception category — this is a standard critical bug fix.

**Step 9.4: Decision**
This is a clear YES. A 4-line fix to a critical OOB write vulnerability
in the core HID input path, present since 2008, with a long history of
related crashes, endorsed by the HID co-maintainer.

## Verification

- [Phase 1] Parsed tags: Suggested-by Tissoires, SOB by Lee Jones and
  Tissoires (maintainer applied)
- [Phase 2] Diff analysis: +4/-3 lines in hid_report_raw_event(),
  replaces memset+dbg_hid with warn+return -EINVAL
- [Phase 3] git blame: buggy memset from commit 85cdaf524b7dda (2008,
  v2.6.26), present in all stable trees
- [Phase 3] git log: found 3 prior fixes to same memset area (966922f,
  5ebdffd, b1a37ed) — confirms recurring issue
- [Phase 3] Author: Lee Jones authored the max_buffer_size hardening
  (b1a37ed), experienced with this code
- [Phase 4] lore.kernel.org: v1 reviewed by Tissoires who requested
  stronger approach; v3 accepted with -EINVAL return; maintainer noted
  "works in 99% of cases"
- [Phase 5] Callers: hid_report_raw_event() called from
  __hid_input_report() (core path) and 6+ drivers
- [Phase 6] hid_warn_ratelimited introduced in v6.18 (1d64624243af8) —
  verified not in v6.12/6.14/6.15/6.16/6.17; needs trivial adaptation
  for older trees
- [Phase 6] Companion patch e716edafedad4 is independent (hid-
  multitouch.c report ID check), not a prerequisite
- [Phase 8] Failure mode: OOB writes via memset → memory corruption,
  severity CRITICAL
- UNVERIFIED: Exact behavior with specific HID devices that send
  intentionally short reports (Tissoires accepted the risk)

**YES**

 drivers/hid/hid-core.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index a5b3a8ca2fcbc..f5587b786f875 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2057,9 +2057,10 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
 		rsize = max_buffer_size;
 
 	if (csize < rsize) {
-		dbg_hid("report %d is too short, (%d < %d)\n", report->id,
-				csize, rsize);
-		memset(cdata + csize, 0, rsize - csize);
+		hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %d)\n",
+				     report->id, rsize, csize);
+		ret = -EINVAL;
+		goto out;
 	}
 
 	if ((hid->claimed & HID_CLAIMED_HIDDEV) && hid->hiddev_report_event)
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.10] HID: multitouch: Check to ensure report responses match the request

[Sasha Levin]

From: Lee Jones <lee@kernel.org>

[ Upstream commit e716edafedad4952fe3a4a273d2e039a84e8681a ]

It is possible for a malicious (or clumsy) device to respond to a
specific report's feature request using a completely different report
ID.  This can cause confusion in the HID core resulting in nasty
side-effects such as OOB writes.

Add a check to ensure that the report ID in the response, matches the
one that was requested.  If it doesn't, omit reporting the raw event and
return early.

Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

As Tissoires noted, `hid-vivaldi-common.c` has the same vulnerable
pattern. `wacom_sys.c` also has it. This confirms the bug is systemic.

Record: Same vulnerable pattern exists in hid-vivaldi-common.c and
wacom_sys.c. This is a known systemic issue.

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?

The buggy code was introduced in commit `6d4f5440a3a2bb` from
2015-10-07, which is approximately kernel v4.4. This means the
vulnerable code exists in **ALL active stable trees** (5.4.y, 5.10.y,
5.15.y, 6.1.y, 6.6.y, 6.12.y, etc.).

Record: Buggy code exists in all active stable trees. Very wide
exposure.

### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS

The fix is 7 lines added to a single function. The function has been
stable since 2015 with only minor modifications (2018 `ret` variable and
`hid_report_len` changes). The patch should apply cleanly to all stable
trees or with trivial context adjustments.

Record: Expected backport difficulty: clean apply or trivial conflicts.

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY IN STABLE
No related fixes for this specific issue found in any stable tree.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
- **Subsystem**: HID (Human Interface Devices) — drivers/hid/
- **Criticality**: IMPORTANT — HID affects all USB input devices (mice,
  keyboards, touchscreens, touchpads). Multitouch is used by virtually
  all modern laptops and tablets.
- **Security aspect**: USB devices are a common physical attack vector.
  A malicious USB device can be plugged into any machine.

Record: [HID/multitouch] [IMPORTANT - affects all multitouch devices,
USB attack vector]

### Step 7.2: ASSESS SUBSYSTEM ACTIVITY
Active subsystem with regular commits. The HID maintainer (Benjamin
Tissoires) actively reviews and merges patches.

Record: Active subsystem, responsive maintainer.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: DETERMINE WHO IS AFFECTED
Any system using HID multitouch devices (virtually all laptops, tablets,
kiosks, and touchscreen-equipped systems). The vulnerability is
triggerable via a malicious USB device.

Record: Affected user population: universal (any system with USB ports
and HID multitouch support).

### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
- **Trigger**: A USB device sends a HID feature report response with a
  report ID different from the one requested
- **Attack scenario**: Malicious USB device (BadUSB-style attack) — plug
  in a crafted USB device
- **Also possible**: Buggy/clumsy device firmware (accidental trigger)
- **Privilege**: Physical access to USB port required (no unprivileged
  userspace trigger)
- **Reproducibility**: Deterministic — controlled by the device firmware

Record: Physical access via USB required. Deterministic trigger from
device side. No unprivileged software trigger.

### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
- **Failure mode**: Out-of-bounds memory write in kernel space
- **Consequences**: Memory corruption, potential kernel crash, potential
  privilege escalation
- **Severity**: **CRITICAL** — OOB write is one of the most serious
  vulnerability classes

Record: [OOB write / memory corruption] [Severity: CRITICAL]

### Step 8.4: CALCULATE RISK-BENEFIT RATIO
- **BENEFIT**: Very high — prevents OOB kernel memory corruption from
  malicious USB devices
- **RISK**: Very low — 7 lines, simple ID comparison check, only affects
  feature report processing in multitouch driver
- **Ratio**: Excellent — high benefit, minimal risk

Record: [Benefit: VERY HIGH] [Risk: VERY LOW] [Ratio: strongly favors
backporting]

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Fixes OOB write (CRITICAL severity security vulnerability)
- Exploitable via malicious USB device (physical attack vector)
- Fix is 7 lines, obviously correct (simple ID comparison)
- Accepted by HID maintainer Benjamin Tissoires
- Buggy code exists in ALL stable trees (since 2015, kernel v4.4)
- No dependencies on other patches (standalone fix)
- Clean backport expected
- Verified the OOB mechanism in `hid_report_raw_event()` — the `memset`
  at line 2062 can write beyond buffer bounds

**AGAINST backporting:**
- Part of a 2-patch series, but patch 1/2 is independent (different
  file, different issue)
- No explicit Cc: stable from author or reviewer (expected, that's why
  we're reviewing)
- Requires physical USB access (not remotely exploitable)

**UNRESOLVED:**
- None significant — the bug mechanism is clearly verified

### Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. **Obviously correct and tested?** YES — simple comparison of
   report->id vs buf[0], reviewed and accepted by HID maintainer
2. **Fixes a real bug that affects users?** YES — OOB write from
   malicious/buggy USB devices
3. **Important issue?** YES — memory corruption / security vulnerability
   (CRITICAL)
4. **Small and contained?** YES — 7 lines in one function in one file
5. **No new features or APIs?** YES — purely validation logic
6. **Can apply to stable trees?** YES — code has been stable since 2015

### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Not an exception category — this is a standard security bug fix, which
is the primary use case for stable.

### Step 9.4: MAKE YOUR DECISION
This is a clear YES. It's a small, obviously correct security fix that
prevents OOB writes from malicious USB devices. The fix has been
reviewed and accepted by the HID maintainer. It affects all stable trees
and has minimal regression risk.

## Verification

- [Phase 1] Parsed tags: Signed-off-by Lee Jones (author), Signed-off-by
  Benjamin Tissoires (HID maintainer). No Fixes/Reported-by/Cc:stable
  tags.
- [Phase 2] Diff analysis: 7 lines added to `mt_get_feature()` in hid-
  multitouch.c, adds report ID validation check before calling
  `hid_report_raw_event()`
- [Phase 3] git blame: Buggy code introduced in commit `6d4f5440a3a2bb`
  (2015-10-07, ~v4.4), present in ALL active stable trees
- [Phase 3] git log: No previous related fixes for this issue found
- [Phase 4] lore.kernel.org: Found patch submission at
  `20260227163031.1166560-2-lee@kernel.org`. Patch 2/2 of series; patch
  1/2 is independent (different file). Benjamin Tissoires reviewed and
  accepted. He noted same bug exists in hid-vivaldi-common.c.
- [Phase 4] RFC v3: Tissoires NACK'd core-level fix, preferred per-
  driver fixes like this one — confirming this is the maintainer's
  preferred approach.
- [Phase 5] Callers: `mt_get_feature()` called from
  `mt_feature_mapping()` at 3 sites during device enumeration — standard
  path for multitouch devices
- [Phase 5] Verified OOB mechanism: `hid_report_raw_event()` at hid-
  core.c:2040 uses `data[0]` (buf[0]) to look up report; at line 2062,
  `memset(cdata + csize, 0, rsize - csize)` writes beyond buffer if
  looked-up report is larger than the buffer allocated for the requested
  report
- [Phase 5] Same vulnerable pattern confirmed in hid-vivaldi-common.c:87
  and wacom_sys.c:397
- [Phase 6] Code exists in all active stable trees (v4.4+), fix should
  apply cleanly
- [Phase 7] HID subsystem: IMPORTANT criticality, affects all multitouch
  USB devices
- [Phase 8] Failure mode: OOB kernel memory write, severity CRITICAL.
  Trigger: malicious USB device (physical access required).

**YES**

 drivers/hid/hid-multitouch.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index b8a748bbf0fd8..e82a3c4e5b44e 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -526,12 +526,19 @@ static void mt_get_feature(struct hid_device *hdev, struct hid_report *report)
 		dev_warn(&hdev->dev, "failed to fetch feature %d\n",
 			 report->id);
 	} else {
+		/* The report ID in the request and the response should match */
+		if (report->id != buf[0]) {
+			hid_err(hdev, "Returned feature report did not match the request\n");
+			goto free;
+		}
+
 		ret = hid_report_raw_event(hdev, HID_FEATURE_REPORT, buf,
 					   size, 0);
 		if (ret)
 			dev_warn(&hdev->dev, "failed to report feature\n");
 	}
 
+free:
 	kfree(buf);
 }
 
-- 
2.51.0