public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Lee Jones <lee@kernel.org>,
	Benjamin Tissoires <bentiss@kernel.org>,
	Sasha Levin <sashal@kernel.org>,
	jikos@kernel.org, linux-input@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.19-5.10] HID: multitouch: Check to ensure report responses match the request
Date: Tue, 24 Mar 2026 07:19:28 -0400	[thread overview]
Message-ID: <20260324111931.3257972-19-sashal@kernel.org> (raw)
In-Reply-To: <20260324111931.3257972-1-sashal@kernel.org>

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


      parent reply	other threads:[~2026-03-24 11:19 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-24 11:19 [PATCH AUTOSEL 6.19] drm/amd/display: Fix gamma 2.2 colorop TFs Sasha Levin
2026-03-24 11:19 ` [PATCH AUTOSEL 6.19] mshv: Fix error handling in mshv_region_pin Sasha Levin
2026-03-24 11:19 ` [PATCH AUTOSEL 6.19-6.1] tg3: replace placeholder MAC address with device property Sasha Levin
2026-03-24 11:19 ` [PATCH AUTOSEL 6.19-6.12] btrfs: reserve enough transaction items for qgroup ioctls Sasha Levin
2026-03-24 11:19 ` [PATCH AUTOSEL 6.19-5.10] objtool: Fix Clang jump table detection Sasha Levin
2026-03-24 11:19 ` [PATCH AUTOSEL 6.19-6.12] HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure Sasha Levin
2026-03-24 11:19 ` [PATCH AUTOSEL 6.19-6.1] i2c: tegra: Don't mark devices with pins as IRQ safe Sasha Levin
2026-03-24 11:19 ` [PATCH AUTOSEL 6.19-6.18] smb: client: fix generic/694 due to wrong ->i_blocks Sasha Levin
2026-03-24 11:19 ` [PATCH AUTOSEL 6.19-5.10] atm: lec: fix use-after-free in sock_def_readable() Sasha Levin
2026-03-24 11:19 ` [PATCH AUTOSEL 6.19-5.10] HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq Sasha Levin
2026-03-24 11:19 ` [PATCH AUTOSEL 6.19-6.6] spi: geni-qcom: Check DMA interrupts early in ISR Sasha Levin
2026-03-24 11:19 ` [PATCH AUTOSEL 6.19-6.12] wifi: mac80211: check tdls flag in ieee80211_tdls_oper Sasha Levin
2026-03-24 11:19 ` [PATCH AUTOSEL 6.19] objtool/klp: fix mkstemp() failure with long paths Sasha Levin
2026-03-24 11:19 ` [PATCH AUTOSEL 6.19-6.6] arm64/scs: Fix handling of advance_loc4 Sasha Levin
2026-03-24 11:19 ` [PATCH AUTOSEL 6.19-6.12] HID: logitech-hidpp: Enable MX Master 4 over bluetooth Sasha Levin
2026-03-24 11:19 ` [PATCH AUTOSEL 6.19-5.15] btrfs: reject root items with drop_progress and zero drop_level Sasha Levin
2026-03-24 11:19 ` [PATCH AUTOSEL 6.19-5.15] btrfs: don't take device_list_mutex when querying zone info Sasha Levin
2026-03-24 11:19 ` [PATCH AUTOSEL 6.19-6.18] HID: core: Mitigate potential OOB by removing bogus memset() Sasha Levin
2026-03-24 11:19 ` Sasha Levin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260324111931.3257972-19-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=bentiss@kernel.org \
    --cc=jikos@kernel.org \
    --cc=lee@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox