[PATCH AUTOSEL 7.0-6.18] media: rc: fix race between unregister and urb/irq callbacks

[PATCH AUTOSEL 7.0-6.18] media: rc: fix race between unregister and urb/irq callbacks

[Sasha Levin]

From: Sean Young <sean@mess.org>

[ Upstream commit dccc0c3ddf8f16071736f98a7d6dd46a2d43e037 ]

Some rc device drivers have a race condition between rc_unregister_device()
and irq or urb callbacks. This is because rc_unregister_device() does two
things, it marks the device as unregistered so no new commands can be
issued and then it calls rc_free_device(). This means the driver has no
chance to cancel any pending urb callbacks or interrupts after the device
has been marked as unregistered. Those callbacks may access struct rc_dev
or its members (e.g. struct ir_raw_event_ctrl), which have been freed by
rc_free_device().

This change removes the implicit call to rc_free_device() from
rc_unregister_device(). This means that device drivers can call
rc_unregister_device() in their remove or disconnect function, then cancel
all the urbs and interrupts before explicitly calling rc_free_device().

Note this is an alternative fix for an issue found by Haotian Zhang, see
the Closes: tags.

Reported-by: Haotian Zhang <vulab@iscas.ac.cn>
Closes: https://lore.kernel.org/linux-media/20251114101432.2566-1-vulab@iscas.ac.cn/
Closes: https://lore.kernel.org/linux-media/20251114101418.2548-1-vulab@iscas.ac.cn/
Closes: https://lore.kernel.org/linux-media/20251114101346.2530-1-vulab@iscas.ac.cn/
Closes: https://lore.kernel.org/linux-media/20251114090605.2413-1-vulab@iscas.ac.cn/
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Good - drivers using `devm_rc_allocate_device` don't call
`rc_unregister_device` manually (they use `devm_rc_register_device`
which handles cleanup automatically). The patch removes the
`managed_alloc` flag because it changes the contract:
`rc_unregister_device` no longer frees the device regardless of how it
was allocated. Instead, `devm_rc_alloc_release` (the devres release
callback) calls `rc_free_device`, and the regular drivers must add
explicit `rc_free_device` calls.

Now let me do the full analysis write-up.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
Record: [media: rc] [fix] [race between unregister and urb/irq
callbacks]

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Reported-by:** Haotian Zhang <vulab@iscas.ac.cn> - the reporter
  found multiple race conditions
- **Closes:** 4 separate lore.kernel.org links to bug reports (Nov 2025)
- **Reviewed-by:** Patrice Chotard <patrice.chotard@foss.st.com>
- **Signed-off-by:** Sean Young <sean@mess.org> (author, RC subsystem
  maintainer)
- **Signed-off-by:** Hans Verkuil <hverkuil+cisco@kernel.org> (media
  subsystem maintainer)

Record: Multiple bug reports (4 Closes: tags), reviewed by a maintainer,
written by the RC subsystem maintainer, merged by the media subsystem
maintainer. No Fixes: tag (expected).

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The commit explains a **use-after-free race condition**:
1. `rc_unregister_device()` marks the device as unregistered
2. Then it calls `rc_free_device()`, which frees `struct rc_dev` and
   `struct ir_raw_event_ctrl`
3. Between marking unregistered and freeing, there's no window for
   drivers to cancel pending URBs/IRQs
4. Those pending callbacks may still access the freed `struct rc_dev` or
   its members

Record: Bug = use-after-free due to race between device unregister and
URB/IRQ callbacks. Symptom = accessing freed memory. Root cause =
`rc_unregister_device()` implicitly calls `rc_free_device()` before
drivers can cancel pending async operations.

### Step 1.4: DETECT HIDDEN BUG FIXES
This is an explicit race condition / use-after-free fix. Not hidden.
Record: This is a clear, well-documented bug fix.

## PHASE 2: DIFF ANALYSIS

### Step 2.1: INVENTORY THE CHANGES
41 files changed, ~58 insertions, ~36 deletions. Files span:
- Core: `rc-main.c`, `rc-ir-raw.c`, `rc-core.h`
- ~30+ driver files across media/rc, media/pci, media/usb, gpu/drm, hid,
  staging

Record: Cross-subsystem change touching 41 files, but each driver change
is 1-3 lines. Core changes are ~10 lines net.

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Core changes:**
1. `rc-main.c`: `rc_unregister_device()` no longer calls
   `rc_free_device()` (removes the `if (!dev->managed_alloc)
   rc_free_device(dev)` block)
2. `rc-main.c`: `rc_dev_release()` now calls `ir_raw_event_free(dev)`
   before `kfree(dev)` - this ensures raw event data is cleaned up when
   the device struct is finally freed
3. `rc-main.c`: `devm_rc_allocate_device()` no longer sets
   `managed_alloc = true`
4. `rc-ir-raw.c`: `ir_raw_event_unregister()` no longer calls
   `ir_raw_event_free()` (moved to `rc_dev_release`)
5. `rc-ir-raw.c`: `ir_raw_event_free()` removes the `if (!dev)` guard
   (now only called from `rc_dev_release`)
6. `rc-core.h`: Removes `managed_alloc` field from `struct rc_dev`

**Driver changes:** Every driver using `rc_unregister_device()` now also
calls `rc_free_device()` afterward. Some USB drivers also reorder
operations to call `rc_unregister_device()` BEFORE killing URBs, then
`rc_free_device()` AFTER killing URBs.

### Step 2.3: IDENTIFY THE BUG MECHANISM
Category: **Race condition / Use-after-free**

Before the fix:
```
rc_unregister_device()
  -> marks device unregistered
  -> calls rc_free_device() -> frees struct rc_dev
  // URB/IRQ callbacks can still fire and access freed rc_dev!
```

After the fix:
```
rc_unregister_device()
  -> marks device unregistered
  // Driver cancels URBs/IRQs here
rc_free_device()
  -> safely frees struct rc_dev after all callbacks cancelled
```

Record: UAF race condition fix. Separating unregister from free gives
drivers a window to cancel async operations.

### Step 2.4: ASSESS THE FIX QUALITY
- Written by Sean Young (RC subsystem maintainer)
- Reviewed by Patrice Chotard
- Merged by Hans Verkuil (media maintainer)
- The approach is sound: it separates two concerns (marking unregistered
  vs. freeing memory)
- Each per-driver change is trivial (add one `rc_free_device()` line)
- **Concern:** The scope is very large (41 files), though each change is
  trivially mechanical

Record: High quality fix from the subsystem maintainer. Regression risk
is low per-driver but the sheer breadth is notable. The error path
changes in probe functions (removing `rdev = NULL` after
`rc_unregister_device`) are now correct because `rc_free_device(rdev)`
on the next goto target will properly free even after unregister.

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
The `managed_alloc` logic was introduced in commit `ddbf7d5a698c4d`
(2016, v4.10 era) by Heiner Kallweit. The implicit `rc_free_device()`
call in `rc_unregister_device()` has been present since `d8b4b5822f51e2`
(2010, v2.6.36 era). The race condition has existed since the very
beginning of the rc_core subsystem.

Record: Bug exists in all kernel versions since 2010 (v2.6.36+). Present
in all stable trees.

### Step 3.2: FOLLOW THE FIXES: TAG
No Fixes: tag present (expected for autosel candidates).

### Step 3.3: CHECK FILE HISTORY
Multiple previous fixes for the same class of UAF bugs exist:
- `5abda7a16698d` "media: dm1105: Fix use after free bug in
  dm1105_remove due to race condition"
- `29b0589a865b6` "media: rc: Fix use-after-free bugs caused by
  ene_tx_irqsim()"

These were individual driver fixes for the same systemic issue. This
patch fixes it once and for all in the core.

Record: This is a systemic fix replacing multiple individual driver-
level workarounds.

### Step 3.4: CHECK THE AUTHOR
Sean Young is the RC subsystem maintainer. He has dozens of commits in
`drivers/media/rc/`. This is his subsystem.

Record: Author is the subsystem maintainer - highest trust level.

### Step 3.5: CHECK FOR DEPENDENCIES
This is a single, self-contained patch. All changes are coordinated. No
other patches are needed.

Record: Standalone fix, no dependencies.

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Found via web search:
- v1: "[PATCH] media: rc: rc_unregister_device() should not call
  rc_free_device()" (Dec 20, 2025)
- v2: "[PATCH v2] media: rc: fix race between unregister and urb/irq
  callbacks" (Jan 26, 2026)

The v2 has the `Reviewed-by` tag from Patrice Chotard that v1 didn't
have.

Record: Patch went through 2 revisions. Applied version is v2 (latest).
Reviewed by maintainer.

### Step 4.2: WHO REVIEWED
- Reviewed-by: Patrice Chotard (STMicroelectronics, works on st_rc
  driver)
- Signed-off-by: Hans Verkuil (media subsystem co-maintainer)
- CC'd: Numerous subsystem maintainers (Maarten Lankhorst, David Airlie
  for DRM, etc.)

Record: Properly reviewed through the maintainer chain.

### Step 4.3: SEARCH FOR THE BUG REPORT
4 separate bug reports from Haotian Zhang (November 2025) about UAF
races in different RC drivers.

Record: Multiple independent bug reports confirm this is a real-world
issue.

### Step 4.4: RELATED PATCHES
This is the alternative/comprehensive fix. The original individual
patches from Haotian Zhang addressed each driver separately; Sean
Young's approach fixes the root cause in the core.

Record: This is the definitive fix rather than per-driver workarounds.

### Step 4.5: STABLE MAILING LIST
No specific stable discussion found. The patch does not have Cc: stable
tag.

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: KEY FUNCTIONS
- `rc_unregister_device()` - modified to remove implicit free
- `rc_free_device()` - now must be called explicitly by drivers
- `rc_dev_release()` - now frees raw event data
- `ir_raw_event_free()` - moved from unregister path to release path
- `ir_raw_event_unregister()` - no longer frees raw events

### Step 5.2: CALLERS
Every RC driver's remove/disconnect/exit function calls
`rc_unregister_device()`. The patch adds `rc_free_device()` to all of
them. This affects USB IR receivers, PCI TV tuner cards, embedded IR
receivers, DRM bridges, etc.

Record: Broad impact - every RC device driver is affected.

### Step 5.3-5.5: CALL CHAIN AND PATTERNS
The race is triggered during device removal (USB disconnect, PCI remove,
platform remove). This is a common path triggered by:
- USB device physical disconnect
- Module unload
- System shutdown
- Device unbind via sysfs

Record: The buggy path is easily triggered by physical device
disconnect. Not theoretical.

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

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE?
Yes. The buggy code in `rc_unregister_device()` (calling
`rc_free_device()` implicitly) has existed since 2010. It is present in
ALL stable trees.

Record: Bug affects all stable trees (6.6.y, 6.1.y, 5.15.y, etc.).

### Step 6.2: BACKPORT COMPLICATIONS
This patch touches 41 files. Some files may have diverged between
mainline and stable trees. Backporting will likely require resolving
minor conflicts in some drivers. The core changes to `rc-main.c`, `rc-
ir-raw.c`, and `rc-core.h` are critical and should apply with minor
fuzz. The per-driver changes are mechanical and can be adapted.

Record: Expected difficulty: **medium**. Core changes likely apply
cleanly. Some driver-specific changes may need minor adjustment due to
driver-specific changes in stable trees vs mainline.

### Step 6.3: RELATED FIXES IN STABLE
Individual UAF fixes like `5abda7a16698d` (dm1105) and `29b0589a865b6`
(ene_ir) may already be in some stable trees, but they only fix specific
drivers. This systemic fix is comprehensive.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: SUBSYSTEM CRITICALITY
Media/RC subsystem - used by IR receivers on:
- TV tuner cards (USB and PCI)
- Media center remotes (iMON, MCE, Xbox)
- Embedded IR receivers (sunxi, meson, hix5hd2)
- DRM bridges with CEC/RC

Record: IMPORTANT level - affects users of IR remote control hardware
(common in HTPCs, embedded media devices).

### Step 7.2: SUBSYSTEM ACTIVITY
Active subsystem with regular maintenance from Sean Young.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: WHO IS AFFECTED
All users with IR remote control hardware who disconnect or unbind the
device. This includes USB IR receivers (very common for HTPC setups),
PCI TV tuner cards with IR, and embedded systems with hardware IR.

Record: Moderate user population - anyone using Linux with IR remote
control hardware.

### Step 8.2: TRIGGER CONDITIONS
- Physical USB disconnect of IR receiver
- Module unload while IR device active
- Device unbind via sysfs
- System shutdown with pending IR operations
- Concurrent with incoming IR data

Record: Common trigger conditions. USB disconnect is the most frequent.

### Step 8.3: FAILURE MODE SEVERITY
Use-after-free: Accessing freed `struct rc_dev` or `struct
ir_raw_event_ctrl` from URB/IRQ callbacks. This leads to:
- Kernel crash/oops (most likely)
- Memory corruption (possible)
- Security vulnerability (potential, if attacker controls USB device)

Record: Severity: HIGH to CRITICAL. UAF can cause crashes and is
potentially exploitable.

### Step 8.4: RISK-BENEFIT RATIO
**Benefit:** HIGH - Fixes use-after-free race in all RC drivers
systemically. Prevents crashes during device disconnect. Fixes reported
real-world bug.

**Risk:** MEDIUM - 41 files touched, but each change is 1-3 lines and
mechanically identical (add `rc_free_device()` after
`rc_unregister_device()`). The core API change is well-designed. Some
USB drivers also reorder operations to call `rc_unregister_device()`
before `usb_kill_urb()`, which is the correct order.

Record: Benefit HIGH, Risk MEDIUM. The fix is well-designed but the
scope is large.

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**Evidence FOR backporting:**
- Fixes a real use-after-free race condition
- Multiple independent bug reports (4 Closes: tags)
- Written and signed by the RC subsystem maintainer (Sean Young)
- Reviewed by Patrice Chotard, merged by Hans Verkuil
- Bug has existed since 2010, affects all stable trees
- Previous individual driver fixes confirm this is a known issue pattern
- UAF can cause kernel crashes and is potentially exploitable
- The fix is logically correct - it separates unregister from free

**Evidence AGAINST backporting:**
- Very large scope: 41 files modified across multiple subsystems
- Changes a core API contract (rc_unregister_device no longer frees)
- Risk of backport conflicts due to per-driver divergence between
  mainline and stable
- Some drivers may not exist in older stable trees, requiring manual
  adaptation
- Removes `managed_alloc` infrastructure, affecting
  `devm_rc_allocate_device()` users

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **YES** - reviewed by maintainers,
   applied to mainline
2. Fixes a real bug? **YES** - UAF race condition with 4 bug reports
3. Important issue? **YES** - use-after-free / crash during device
   disconnect
4. Small and contained? **NO** - 41 files is very large. However, each
   change is mechanical (1-3 lines per file) and the core change is
   small (~10 lines)
5. No new features or APIs? **YES** - only changes existing API behavior
6. Can apply to stable trees? **PARTIALLY** - core changes likely apply;
   some driver changes may need adaptation

### Step 9.3: EXCEPTION CATEGORIES
Not applicable - this is a bug fix, not a device ID/quirk/DT/build fix.

### Step 9.4: DECISION
This is a genuine, important use-after-free fix from the subsystem
maintainer with multiple independent bug reports. However, the **scope
is extremely large** (41 files across multiple subsystems) and it
changes a core API contract. While each individual change is trivial and
mechanical, the sheer number of files makes this a high-risk backport.
If even one driver is missed or adapted incorrectly, it introduces a new
bug (memory leak from missing `rc_free_device()` or double-free from
calling it when not needed).

The stable kernel rules explicitly require patches to be "small and
contained." While the fix itself is correct and important, 41 files
touching DRM, HID, media PCI, media USB, and staging subsystems is not
small and contained. A backport of this magnitude would need careful
manual review for each stable tree to handle driver-specific divergence.

Verification:
- [Phase 1] Parsed tags: Reported-by: Haotian Zhang, 4 Closes: links,
  Reviewed-by: Patrice Chotard, Signed-off-by: Sean Young (author/RC
  maintainer), Hans Verkuil (media maintainer)
- [Phase 2] Diff analysis: 41 files changed, core change removes
  implicit rc_free_device() from rc_unregister_device(), each driver
  adds explicit rc_free_device() call
- [Phase 2] Verified: Current rc_unregister_device() at line 2046 has
  `if (!dev->managed_alloc) rc_free_device(dev)` - confirmed the bug
  exists
- [Phase 2] Verified: rc_dev_release() at line 1610 currently just does
  `kfree(dev)` without freeing raw events - patch adds
  ir_raw_event_free(dev) there
- [Phase 3] git blame: rc_unregister_device() implicit free from
  d8b4b5822f51e2 (2010, v2.6.36), managed_alloc from ddbf7d5a698c4d
  (2016, v4.10)
- [Phase 3] git show ddbf7d5a698c4d: confirmed managed_alloc was
  introduced by Heiner Kallweit in 2016
- [Phase 3] Found related individual driver UAF fixes: 5abda7a16698d
  (dm1105), 29b0589a865b6 (ene_ir)
- [Phase 3] git show 5abda7a16698d: confirmed dm1105 UAF race diagram
  showing exactly the same pattern
- [Phase 4] Web search found v1 and v2 submissions: v1 Dec 2025, v2 Jan
  26 2026
- [Phase 4] Found full v2 patch on freedesktop.org archives - matches
  commit
- [Phase 4] 4 separate bug reports from Haotian Zhang (Nov 2025) confirm
  real-world issue
- [Phase 5] Verified devm_rc_allocate_device callers (gpio-ir-recv,
  meson-ir, etc.) don't manually call rc_unregister_device - they use
  devm path, so they're unaffected
- [Phase 6] Bug exists since v2.6.36 (2010) - present in all stable
  trees
- [Phase 8] Trigger: USB device disconnect during IR activity - common
  operation
- UNVERIFIED: Whether all 41 files exist in all stable trees (some
  drivers may have been added/removed between releases)

This is a borderline case. The fix addresses a real, reported use-after-
free bug from the subsystem maintainer with proper review. However, the
41-file scope makes it risky for stable. On balance, the UAF is serious
enough (crash, potential security) that it warrants backporting despite
the large scope, especially since each per-driver change is mechanically
identical and trivially verifiable.

**YES**

 drivers/gpu/drm/bridge/sil-sii8620.c        | 1 +
 drivers/hid/hid-picolcd_cir.c               | 1 +
 drivers/media/cec/core/cec-core.c           | 2 +-
 drivers/media/common/siano/smsir.c          | 1 +
 drivers/media/i2c/ir-kbd-i2c.c              | 2 ++
 drivers/media/pci/bt8xx/bttv-input.c        | 3 ++-
 drivers/media/pci/cx23885/cx23885-input.c   | 1 +
 drivers/media/pci/cx88/cx88-input.c         | 3 ++-
 drivers/media/pci/dm1105/dm1105.c           | 1 +
 drivers/media/pci/mantis/mantis_input.c     | 1 +
 drivers/media/pci/saa7134/saa7134-input.c   | 1 +
 drivers/media/pci/smipcie/smipcie-ir.c      | 1 +
 drivers/media/pci/ttpci/budget-ci.c         | 1 +
 drivers/media/rc/ati_remote.c               | 6 +++---
 drivers/media/rc/ene_ir.c                   | 2 +-
 drivers/media/rc/fintek-cir.c               | 3 ++-
 drivers/media/rc/igorplugusb.c              | 1 +
 drivers/media/rc/iguanair.c                 | 1 +
 drivers/media/rc/img-ir/img-ir-hw.c         | 3 ++-
 drivers/media/rc/img-ir/img-ir-raw.c        | 3 ++-
 drivers/media/rc/imon.c                     | 3 ++-
 drivers/media/rc/ir-hix5hd2.c               | 2 +-
 drivers/media/rc/ir_toy.c                   | 1 +
 drivers/media/rc/ite-cir.c                  | 2 +-
 drivers/media/rc/mceusb.c                   | 1 +
 drivers/media/rc/rc-ir-raw.c                | 5 -----
 drivers/media/rc/rc-loopback.c              | 1 +
 drivers/media/rc/rc-main.c                  | 6 +-----
 drivers/media/rc/redrat3.c                  | 4 +++-
 drivers/media/rc/st_rc.c                    | 2 +-
 drivers/media/rc/streamzap.c                | 7 ++++---
 drivers/media/rc/sunxi-cir.c                | 1 +
 drivers/media/rc/ttusbir.c                  | 2 +-
 drivers/media/rc/winbond-cir.c              | 2 +-
 drivers/media/rc/xbox_remote.c              | 5 +++--
 drivers/media/usb/au0828/au0828-input.c     | 1 +
 drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 1 +
 drivers/media/usb/dvb-usb/dvb-usb-remote.c  | 6 ++++--
 drivers/media/usb/em28xx/em28xx-input.c     | 1 +
 drivers/staging/media/av7110/av7110_ir.c    | 1 +
 include/media/rc-core.h                     | 2 --
 41 files changed, 58 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c b/drivers/gpu/drm/bridge/sil-sii8620.c
index d3f238b1f2a94..982306eb4f0a7 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -2221,6 +2221,7 @@ static void sii8620_detach(struct drm_bridge *bridge)
 		return;
 
 	rc_unregister_device(ctx->rc_dev);
+	rc_free_device(ctx->rc_dev);
 }
 
 static int sii8620_is_packing_required(struct sii8620 *ctx,
diff --git a/drivers/hid/hid-picolcd_cir.c b/drivers/hid/hid-picolcd_cir.c
index d6faa0e00f95a..6d4c636e1c9f7 100644
--- a/drivers/hid/hid-picolcd_cir.c
+++ b/drivers/hid/hid-picolcd_cir.c
@@ -134,5 +134,6 @@ void picolcd_exit_cir(struct picolcd_data *data)
 
 	data->rc_dev = NULL;
 	rc_unregister_device(rdev);
+	rc_free_device(rdev);
 }
 
diff --git a/drivers/media/cec/core/cec-core.c b/drivers/media/cec/core/cec-core.c
index 1953ce559ecaf..0fcd3b5e60c8d 100644
--- a/drivers/media/cec/core/cec-core.c
+++ b/drivers/media/cec/core/cec-core.c
@@ -338,8 +338,8 @@ int cec_register_adapter(struct cec_adapter *adap,
 	res = cec_devnode_register(&adap->devnode, adap->owner);
 	if (res) {
 #ifdef CONFIG_MEDIA_CEC_RC
-		/* Note: rc_unregister also calls rc_free */
 		rc_unregister_device(adap->rc);
+		rc_free_device(adap->rc);
 		adap->rc = NULL;
 #endif
 		return res;
diff --git a/drivers/media/common/siano/smsir.c b/drivers/media/common/siano/smsir.c
index af07fed21ae12..283770d583d56 100644
--- a/drivers/media/common/siano/smsir.c
+++ b/drivers/media/common/siano/smsir.c
@@ -92,6 +92,7 @@ int sms_ir_init(struct smscore_device_t *coredev)
 void sms_ir_exit(struct smscore_device_t *coredev)
 {
 	rc_unregister_device(coredev->ir.dev);
+	rc_free_device(coredev->ir.dev);
 
 	pr_debug("\n");
 }
diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
index 5588cdd7ec20d..6047453170043 100644
--- a/drivers/media/i2c/ir-kbd-i2c.c
+++ b/drivers/media/i2c/ir-kbd-i2c.c
@@ -355,6 +355,7 @@ static void ir_work(struct work_struct *work)
 		mutex_unlock(&ir->lock);
 		if (rc == -ENODEV) {
 			rc_unregister_device(ir->rc);
+			rc_free_device(ir->rc);
 			ir->rc = NULL;
 			return;
 		}
@@ -972,6 +973,7 @@ static void ir_remove(struct i2c_client *client)
 	i2c_unregister_device(ir->tx_c);
 
 	rc_unregister_device(ir->rc);
+	rc_free_device(ir->rc);
 }
 
 static const struct i2c_device_id ir_kbd_id[] = {
diff --git a/drivers/media/pci/bt8xx/bttv-input.c b/drivers/media/pci/bt8xx/bttv-input.c
index 373b6c6817d76..f704476506e07 100644
--- a/drivers/media/pci/bt8xx/bttv-input.c
+++ b/drivers/media/pci/bt8xx/bttv-input.c
@@ -572,8 +572,9 @@ void bttv_input_fini(struct bttv *btv)
 	if (btv->remote == NULL)
 		return;
 
-	bttv_ir_stop(btv);
 	rc_unregister_device(btv->remote->dev);
+	bttv_ir_stop(btv);
+	rc_free_device(btv->remote->dev);
 	kfree(btv->remote);
 	btv->remote = NULL;
 }
diff --git a/drivers/media/pci/cx23885/cx23885-input.c b/drivers/media/pci/cx23885/cx23885-input.c
index ffbbeca8a8e5f..554767b8ef2bf 100644
--- a/drivers/media/pci/cx23885/cx23885-input.c
+++ b/drivers/media/pci/cx23885/cx23885-input.c
@@ -402,6 +402,7 @@ void cx23885_input_fini(struct cx23885_dev *dev)
 	if (dev->kernel_ir == NULL)
 		return;
 	rc_unregister_device(dev->kernel_ir->rc);
+	rc_free_device(dev->kernel_ir->rc);
 	kfree(dev->kernel_ir->phys);
 	kfree(dev->kernel_ir->name);
 	kfree(dev->kernel_ir);
diff --git a/drivers/media/pci/cx88/cx88-input.c b/drivers/media/pci/cx88/cx88-input.c
index e958eecb29c5c..5d9ce4f9af011 100644
--- a/drivers/media/pci/cx88/cx88-input.c
+++ b/drivers/media/pci/cx88/cx88-input.c
@@ -509,8 +509,9 @@ int cx88_ir_fini(struct cx88_core *core)
 	if (!ir)
 		return 0;
 
-	cx88_ir_stop(core);
 	rc_unregister_device(ir->dev);
+	cx88_ir_stop(core);
+	rc_free_device(ir->dev);
 	kfree(ir);
 
 	/* done */
diff --git a/drivers/media/pci/dm1105/dm1105.c b/drivers/media/pci/dm1105/dm1105.c
index de05d8b0f9dc5..bbd24769ae56b 100644
--- a/drivers/media/pci/dm1105/dm1105.c
+++ b/drivers/media/pci/dm1105/dm1105.c
@@ -763,6 +763,7 @@ static int dm1105_ir_init(struct dm1105_dev *dm1105)
 static void dm1105_ir_exit(struct dm1105_dev *dm1105)
 {
 	rc_unregister_device(dm1105->ir.dev);
+	rc_free_device(dm1105->ir.dev);
 }
 
 static int dm1105_hw_init(struct dm1105_dev *dev)
diff --git a/drivers/media/pci/mantis/mantis_input.c b/drivers/media/pci/mantis/mantis_input.c
index 34c0d979240fd..edb4cacf55d22 100644
--- a/drivers/media/pci/mantis/mantis_input.c
+++ b/drivers/media/pci/mantis/mantis_input.c
@@ -72,5 +72,6 @@ EXPORT_SYMBOL_GPL(mantis_input_init);
 void mantis_input_exit(struct mantis_pci *mantis)
 {
 	rc_unregister_device(mantis->rc);
+	rc_free_device(mantis->rc);
 }
 EXPORT_SYMBOL_GPL(mantis_input_exit);
diff --git a/drivers/media/pci/saa7134/saa7134-input.c b/drivers/media/pci/saa7134/saa7134-input.c
index 5b71014157808..7f6680de31564 100644
--- a/drivers/media/pci/saa7134/saa7134-input.c
+++ b/drivers/media/pci/saa7134/saa7134-input.c
@@ -834,6 +834,7 @@ void saa7134_input_fini(struct saa7134_dev *dev)
 		return;
 
 	rc_unregister_device(dev->remote->dev);
+	rc_free_device(dev->remote->dev);
 	kfree(dev->remote);
 	dev->remote = NULL;
 }
diff --git a/drivers/media/pci/smipcie/smipcie-ir.c b/drivers/media/pci/smipcie/smipcie-ir.c
index c0604d9c70119..0bbe4fa2d5a84 100644
--- a/drivers/media/pci/smipcie/smipcie-ir.c
+++ b/drivers/media/pci/smipcie/smipcie-ir.c
@@ -181,5 +181,6 @@ void smi_ir_exit(struct smi_dev *dev)
 
 	rc_unregister_device(rc_dev);
 	smi_ir_stop(ir);
+	rc_free_device(rc_dev);
 	ir->rc_dev = NULL;
 }
diff --git a/drivers/media/pci/ttpci/budget-ci.c b/drivers/media/pci/ttpci/budget-ci.c
index 3709c0fb23b07..8b496b959d7ea 100644
--- a/drivers/media/pci/ttpci/budget-ci.c
+++ b/drivers/media/pci/ttpci/budget-ci.c
@@ -249,6 +249,7 @@ static void msp430_ir_deinit(struct budget_ci *budget_ci)
 	cancel_work_sync(&budget_ci->ir.msp430_irq_bh_work);
 
 	rc_unregister_device(budget_ci->ir.dev);
+	rc_free_device(budget_ci->ir.dev);
 }
 
 static int ciintf_read_attribute_mem(struct dvb_ca_en50221 *ca, int slot, int address)
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index 78abe810a88e7..51d85de24fae3 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -921,7 +921,6 @@ static int ati_remote_probe(struct usb_interface *interface,
 	input_free_device(input_dev);
  exit_unregister_device:
 	rc_unregister_device(rc_dev);
-	rc_dev = NULL;
  exit_kill_urbs:
 	usb_kill_urb(ati_remote->irq_urb);
 	usb_kill_urb(ati_remote->out_urb);
@@ -941,18 +940,19 @@ static void ati_remote_disconnect(struct usb_interface *interface)
 	struct ati_remote *ati_remote;
 
 	ati_remote = usb_get_intfdata(interface);
-	usb_set_intfdata(interface, NULL);
 	if (!ati_remote) {
 		dev_warn(&interface->dev, "%s - null device?\n", __func__);
 		return;
 	}
 
+	rc_unregister_device(ati_remote->rdev);
+	usb_set_intfdata(interface, NULL);
 	usb_kill_urb(ati_remote->irq_urb);
 	usb_kill_urb(ati_remote->out_urb);
 	if (ati_remote->idev)
 		input_unregister_device(ati_remote->idev);
-	rc_unregister_device(ati_remote->rdev);
 	ati_remote_free_buffers(ati_remote);
+	rc_free_device(ati_remote->rdev);
 	kfree(ati_remote);
 }
 
diff --git a/drivers/media/rc/ene_ir.c b/drivers/media/rc/ene_ir.c
index f8120605501ab..6f7dccc965e7f 100644
--- a/drivers/media/rc/ene_ir.c
+++ b/drivers/media/rc/ene_ir.c
@@ -1090,7 +1090,6 @@ static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id)
 	release_region(dev->hw_io, ENE_IO_SIZE);
 exit_unregister_device:
 	rc_unregister_device(rdev);
-	rdev = NULL;
 exit_free_dev_rdev:
 	rc_free_device(rdev);
 	kfree(dev);
@@ -1110,6 +1109,7 @@ static void ene_remove(struct pnp_dev *pnp_dev)
 	ene_rx_restore_hw_buffer(dev);
 	spin_unlock_irqrestore(&dev->hw_lock, flags);
 
+	rc_free_device(dev->rdev);
 	free_irq(dev->irq, dev);
 	release_region(dev->hw_io, ENE_IO_SIZE);
 	kfree(dev);
diff --git a/drivers/media/rc/fintek-cir.c b/drivers/media/rc/fintek-cir.c
index f7cfa8a073ebc..5055dfc3f4651 100644
--- a/drivers/media/rc/fintek-cir.c
+++ b/drivers/media/rc/fintek-cir.c
@@ -568,6 +568,7 @@ static void fintek_remove(struct pnp_dev *pdev)
 	struct fintek_dev *fintek = pnp_get_drvdata(pdev);
 	unsigned long flags;
 
+	rc_unregister_device(fintek->rdev);
 	spin_lock_irqsave(&fintek->fintek_lock, flags);
 	/* disable CIR */
 	fintek_disable_cir(fintek);
@@ -580,7 +581,7 @@ static void fintek_remove(struct pnp_dev *pdev)
 	free_irq(fintek->cir_irq, fintek);
 	release_region(fintek->cir_addr, fintek->cir_port_len);
 
-	rc_unregister_device(fintek->rdev);
+	rc_free_device(fintek->rdev);
 
 	kfree(fintek);
 }
diff --git a/drivers/media/rc/igorplugusb.c b/drivers/media/rc/igorplugusb.c
index e034c93d57cf0..5ceb5ca44e235 100644
--- a/drivers/media/rc/igorplugusb.c
+++ b/drivers/media/rc/igorplugusb.c
@@ -242,6 +242,7 @@ static void igorplugusb_disconnect(struct usb_interface *intf)
 	usb_set_intfdata(intf, NULL);
 	usb_unpoison_urb(ir->urb);
 	usb_free_urb(ir->urb);
+	rc_free_device(ir->rc);
 	kfree(ir->buf_in);
 }
 
diff --git a/drivers/media/rc/iguanair.c b/drivers/media/rc/iguanair.c
index c508f2536243e..0c5b8befb0af3 100644
--- a/drivers/media/rc/iguanair.c
+++ b/drivers/media/rc/iguanair.c
@@ -500,6 +500,7 @@ static void iguanair_disconnect(struct usb_interface *intf)
 	usb_set_intfdata(intf, NULL);
 	usb_kill_urb(ir->urb_in);
 	usb_kill_urb(ir->urb_out);
+	rc_free_device(ir->rc);
 	usb_free_urb(ir->urb_in);
 	usb_free_urb(ir->urb_out);
 	usb_free_coherent(ir->udev, MAX_IN_PACKET, ir->buf_in, ir->dma_in);
diff --git a/drivers/media/rc/img-ir/img-ir-hw.c b/drivers/media/rc/img-ir/img-ir-hw.c
index 63f6f5b36838d..f30adf4d8444d 100644
--- a/drivers/media/rc/img-ir/img-ir-hw.c
+++ b/drivers/media/rc/img-ir/img-ir-hw.c
@@ -1118,9 +1118,10 @@ void img_ir_remove_hw(struct img_ir_priv *priv)
 	struct rc_dev *rdev = hw->rdev;
 	if (!rdev)
 		return;
+	rc_unregister_device(rdev);
 	img_ir_set_decoder(priv, NULL, 0);
 	hw->rdev = NULL;
-	rc_unregister_device(rdev);
+	rc_free_device(rdev);
 #ifdef CONFIG_COMMON_CLK
 	if (!IS_ERR(priv->clk))
 		clk_notifier_unregister(priv->clk, &hw->clk_nb);
diff --git a/drivers/media/rc/img-ir/img-ir-raw.c b/drivers/media/rc/img-ir/img-ir-raw.c
index 92fb7b555a0f6..f1460d4acf3e8 100644
--- a/drivers/media/rc/img-ir/img-ir-raw.c
+++ b/drivers/media/rc/img-ir/img-ir-raw.c
@@ -136,6 +136,7 @@ void img_ir_remove_raw(struct img_ir_priv *priv)
 	if (!rdev)
 		return;
 
+	rc_unregister_device(rdev);
 	/* switch off and disable raw (edge) interrupts */
 	spin_lock_irq(&priv->lock);
 	raw->rdev = NULL;
@@ -145,7 +146,7 @@ void img_ir_remove_raw(struct img_ir_priv *priv)
 	img_ir_write(priv, IMG_IR_IRQ_CLEAR, IMG_IR_IRQ_EDGE);
 	spin_unlock_irq(&priv->lock);
 
-	rc_unregister_device(rdev);
+	rc_free_device(rdev);
 
 	timer_delete_sync(&raw->timer);
 }
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 7e92161105d53..310c9fc9ae91c 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -2541,9 +2541,10 @@ static void imon_disconnect(struct usb_interface *interface)
 
 	if (ifnum == 0) {
 		ictx->dev_present_intf0 = false;
+		rc_unregister_device(ictx->rdev);
 		usb_kill_urb(ictx->rx_urb_intf0);
 		input_unregister_device(ictx->idev);
-		rc_unregister_device(ictx->rdev);
+		rc_free_device(ictx->rdev);
 		if (ictx->display_supported) {
 			if (ictx->display_type == IMON_DISPLAY_TYPE_LCD)
 				usb_deregister_dev(interface, &imon_lcd_class);
diff --git a/drivers/media/rc/ir-hix5hd2.c b/drivers/media/rc/ir-hix5hd2.c
index edc46828509c8..1b061e4a3dcfa 100644
--- a/drivers/media/rc/ir-hix5hd2.c
+++ b/drivers/media/rc/ir-hix5hd2.c
@@ -331,7 +331,6 @@ static int hix5hd2_ir_probe(struct platform_device *pdev)
 
 regerr:
 	rc_unregister_device(rdev);
-	rdev = NULL;
 clkerr:
 	clk_disable_unprepare(priv->clock);
 err:
@@ -346,6 +345,7 @@ static void hix5hd2_ir_remove(struct platform_device *pdev)
 
 	clk_disable_unprepare(priv->clock);
 	rc_unregister_device(priv->rdev);
+	rc_free_device(priv->rdev);
 }
 
 #ifdef CONFIG_PM_SLEEP
diff --git a/drivers/media/rc/ir_toy.c b/drivers/media/rc/ir_toy.c
index d6472de5da87d..089833e411786 100644
--- a/drivers/media/rc/ir_toy.c
+++ b/drivers/media/rc/ir_toy.c
@@ -536,6 +536,7 @@ static void irtoy_disconnect(struct usb_interface *intf)
 	usb_free_urb(ir->urb_out);
 	usb_kill_urb(ir->urb_in);
 	usb_free_urb(ir->urb_in);
+	rc_free_device(ir->rc);
 	kfree(ir->in);
 	kfree(ir->out);
 	kfree(ir);
diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c
index bf544517c67a9..bde2a70512310 100644
--- a/drivers/media/rc/ite-cir.c
+++ b/drivers/media/rc/ite-cir.c
@@ -1414,7 +1414,6 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id
 	release_region(itdev->cir_addr, itdev->params->io_region_size);
 exit_unregister_device:
 	rc_unregister_device(rdev);
-	rdev = NULL;
 exit_free_dev_rdev:
 	rc_free_device(rdev);
 	kfree(itdev);
@@ -1439,6 +1438,7 @@ static void ite_remove(struct pnp_dev *pdev)
 	release_region(dev->cir_addr, dev->params->io_region_size);
 
 	rc_unregister_device(dev->rdev);
+	rc_free_device(dev->rdev);
 
 	kfree(dev);
 }
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index ed55e9ec3c570..06222eee17540 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -1850,6 +1850,7 @@ static void mceusb_dev_disconnect(struct usb_interface *intf)
 	usb_free_urb(ir->urb_in);
 	usb_free_coherent(dev, ir->len_in, ir->buf_in, ir->dma_in);
 	usb_put_dev(dev);
+	rc_free_device(ir->rc);
 
 	kfree(ir);
 }
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 2e269ef5e26be..ba24c2f22d39f 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -648,9 +648,6 @@ int ir_raw_event_register(struct rc_dev *dev)
 
 void ir_raw_event_free(struct rc_dev *dev)
 {
-	if (!dev)
-		return;
-
 	kfree(dev->raw);
 	dev->raw = NULL;
 }
@@ -674,8 +671,6 @@ void ir_raw_event_unregister(struct rc_dev *dev)
 
 	lirc_bpf_free(dev);
 
-	ir_raw_event_free(dev);
-
 	/*
 	 * A user can be calling bpf(BPF_PROG_{QUERY|ATTACH|DETACH}), so
 	 * ensure that the raw member is null on unlock; this is how
diff --git a/drivers/media/rc/rc-loopback.c b/drivers/media/rc/rc-loopback.c
index 78ac09b3cbd34..53d0540717b36 100644
--- a/drivers/media/rc/rc-loopback.c
+++ b/drivers/media/rc/rc-loopback.c
@@ -263,6 +263,7 @@ static int __init loop_init(void)
 static void __exit loop_exit(void)
 {
 	rc_unregister_device(loopdev.dev);
+	rc_free_device(loopdev.dev);
 }
 
 module_init(loop_init);
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 821607504008a..dda3479ea3add 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1611,6 +1611,7 @@ static void rc_dev_release(struct device *device)
 {
 	struct rc_dev *dev = to_rc_dev(device);
 
+	ir_raw_event_free(dev);
 	kfree(dev);
 }
 
@@ -1773,7 +1774,6 @@ struct rc_dev *devm_rc_allocate_device(struct device *dev,
 	}
 
 	rc->dev.parent = dev;
-	rc->managed_alloc = true;
 	*dr = rc;
 	devres_add(dev, dr);
 
@@ -2042,11 +2042,7 @@ void rc_unregister_device(struct rc_dev *dev)
 	device_del(&dev->dev);
 
 	ida_free(&rc_ida, dev->minor);
-
-	if (!dev->managed_alloc)
-		rc_free_device(dev);
 }
-
 EXPORT_SYMBOL_GPL(rc_unregister_device);
 
 /*
diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 3b917a2a89188..3f828a564e192 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -1131,11 +1131,13 @@ static void redrat3_dev_disconnect(struct usb_interface *intf)
 {
 	struct usb_device *udev = interface_to_usbdev(intf);
 	struct redrat3_dev *rr3 = usb_get_intfdata(intf);
+	struct rc_dev *rc = rr3->rc;
 
 	usb_set_intfdata(intf, NULL);
-	rc_unregister_device(rr3->rc);
+	rc_unregister_device(rc);
 	led_classdev_unregister(&rr3->led);
 	redrat3_delete(rr3, udev);
+	rc_free_device(rc);
 }
 
 static int redrat3_dev_suspend(struct usb_interface *intf, pm_message_t message)
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index 6b70bac5f45d6..0ba06bfc9e14b 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -203,6 +203,7 @@ static void st_rc_remove(struct platform_device *pdev)
 	device_init_wakeup(&pdev->dev, false);
 	clk_disable_unprepare(rc_dev->sys_clock);
 	rc_unregister_device(rc_dev->rdev);
+	rc_free_device(rc_dev->rdev);
 }
 
 static int st_rc_open(struct rc_dev *rdev)
@@ -334,7 +335,6 @@ static int st_rc_probe(struct platform_device *pdev)
 	return ret;
 rcerr:
 	rc_unregister_device(rdev);
-	rdev = NULL;
 clkerr:
 	clk_disable_unprepare(rc_dev->sys_clock);
 err:
diff --git a/drivers/media/rc/streamzap.c b/drivers/media/rc/streamzap.c
index 5a18603f9a95c..7103da57c19f1 100644
--- a/drivers/media/rc/streamzap.c
+++ b/drivers/media/rc/streamzap.c
@@ -388,15 +388,16 @@ static void streamzap_disconnect(struct usb_interface *interface)
 	struct streamzap_ir *sz = usb_get_intfdata(interface);
 	struct usb_device *usbdev = interface_to_usbdev(interface);
 
-	usb_set_intfdata(interface, NULL);
-
 	if (!sz)
 		return;
 
-	usb_kill_urb(sz->urb_in);
 	rc_unregister_device(sz->rdev);
+	usb_set_intfdata(interface, NULL);
+
+	usb_kill_urb(sz->urb_in);
 	usb_free_urb(sz->urb_in);
 	usb_free_coherent(usbdev, sz->buf_in_len, sz->buf_in, sz->dma_in);
+	rc_free_device(sz->rdev);
 
 	kfree(sz);
 }
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 92ef4e7c6f69f..cb4c56bf0752a 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -371,6 +371,7 @@ static void sunxi_ir_remove(struct platform_device *pdev)
 	struct sunxi_ir *ir = platform_get_drvdata(pdev);
 
 	rc_unregister_device(ir->rc);
+	rc_free_device(ir->rc);
 	sunxi_ir_hw_exit(&pdev->dev);
 }
 
diff --git a/drivers/media/rc/ttusbir.c b/drivers/media/rc/ttusbir.c
index 110a469001146..a2a64a860264b 100644
--- a/drivers/media/rc/ttusbir.c
+++ b/drivers/media/rc/ttusbir.c
@@ -333,7 +333,6 @@ static int ttusbir_probe(struct usb_interface *intf,
 	return 0;
 out3:
 	rc_unregister_device(rc);
-	rc = NULL;
 out2:
 	led_classdev_unregister(&tt->led);
 out:
@@ -373,6 +372,7 @@ static void ttusbir_disconnect(struct usb_interface *intf)
 	}
 	usb_kill_urb(tt->bulk_urb);
 	usb_free_urb(tt->bulk_urb);
+	rc_free_device(tt->rc);
 	usb_set_intfdata(intf, NULL);
 	kfree(tt);
 }
diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index 515469dd82d4c..8e804661a6215 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -1132,7 +1132,6 @@ wbcir_probe(struct pnp_dev *device, const struct pnp_device_id *dev_id)
 	release_region(data->wbase, WAKEUP_IOMEM_LEN);
 exit_unregister_device:
 	rc_unregister_device(data->dev);
-	data->dev = NULL;
 exit_free_rc:
 	rc_free_device(data->dev);
 exit_unregister_led:
@@ -1163,6 +1162,7 @@ wbcir_remove(struct pnp_dev *device)
 	wbcir_set_bits(data->wbase + WBCIR_REG_WCEIR_EV_EN, 0x00, 0x07);
 
 	rc_unregister_device(data->dev);
+	rc_free_device(data->dev);
 
 	led_classdev_unregister(&data->led);
 
diff --git a/drivers/media/rc/xbox_remote.c b/drivers/media/rc/xbox_remote.c
index 3e3da70cf8da0..c64123e9d16a5 100644
--- a/drivers/media/rc/xbox_remote.c
+++ b/drivers/media/rc/xbox_remote.c
@@ -277,14 +277,15 @@ static void xbox_remote_disconnect(struct usb_interface *interface)
 	struct xbox_remote *xbox_remote;
 
 	xbox_remote = usb_get_intfdata(interface);
-	usb_set_intfdata(interface, NULL);
 	if (!xbox_remote) {
 		dev_warn(&interface->dev, "%s - null device?\n", __func__);
 		return;
 	}
 
-	usb_kill_urb(xbox_remote->irq_urb);
 	rc_unregister_device(xbox_remote->rdev);
+	usb_set_intfdata(interface, NULL);
+	usb_kill_urb(xbox_remote->irq_urb);
+	rc_free_device(xbox_remote->rdev);
 	usb_free_urb(xbox_remote->irq_urb);
 	kfree(xbox_remote);
 }
diff --git a/drivers/media/usb/au0828/au0828-input.c b/drivers/media/usb/au0828/au0828-input.c
index 7dec1a360da6a..81d0165a3064d 100644
--- a/drivers/media/usb/au0828/au0828-input.c
+++ b/drivers/media/usb/au0828/au0828-input.c
@@ -357,6 +357,7 @@ void au0828_rc_unregister(struct au0828_dev *dev)
 		return;
 
 	rc_unregister_device(ir->rc);
+	rc_free_device(ir->rc);
 
 	/* done */
 	kfree(ir);
diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
index 600cff8a4abdc..bd86d250433df 100644
--- a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
+++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
@@ -187,6 +187,7 @@ static int dvb_usbv2_remote_exit(struct dvb_usb_device *d)
 	if (d->rc_dev) {
 		cancel_delayed_work_sync(&d->rc_query_work);
 		rc_unregister_device(d->rc_dev);
+		rc_free_device(d->rc_dev);
 		d->rc_dev = NULL;
 	}
 
diff --git a/drivers/media/usb/dvb-usb/dvb-usb-remote.c b/drivers/media/usb/dvb-usb/dvb-usb-remote.c
index 65e2c9e2cdc99..6dc11718dfb98 100644
--- a/drivers/media/usb/dvb-usb/dvb-usb-remote.c
+++ b/drivers/media/usb/dvb-usb/dvb-usb-remote.c
@@ -347,10 +347,12 @@ int dvb_usb_remote_exit(struct dvb_usb_device *d)
 {
 	if (d->state & DVB_USB_STATE_REMOTE) {
 		cancel_delayed_work_sync(&d->rc_query_work);
-		if (d->props.rc.mode == DVB_RC_LEGACY)
+		if (d->props.rc.mode == DVB_RC_LEGACY) {
 			input_unregister_device(d->input_dev);
-		else
+		} else {
 			rc_unregister_device(d->rc_dev);
+			rc_free_device(d->rc_dev);
+		}
 	}
 	d->state &= ~DVB_USB_STATE_REMOTE;
 	return 0;
diff --git a/drivers/media/usb/em28xx/em28xx-input.c b/drivers/media/usb/em28xx/em28xx-input.c
index 20fdd59b55185..ab61d9a29b10e 100644
--- a/drivers/media/usb/em28xx/em28xx-input.c
+++ b/drivers/media/usb/em28xx/em28xx-input.c
@@ -853,6 +853,7 @@ static int em28xx_ir_fini(struct em28xx *dev)
 		goto ref_put;
 
 	rc_unregister_device(ir->rc);
+	rc_free_device(ir->rc);
 
 	kfree(ir->i2c_client);
 
diff --git a/drivers/staging/media/av7110/av7110_ir.c b/drivers/staging/media/av7110/av7110_ir.c
index 68b3979ba5f20..fdae467fd7ab8 100644
--- a/drivers/staging/media/av7110/av7110_ir.c
+++ b/drivers/staging/media/av7110/av7110_ir.c
@@ -151,6 +151,7 @@ int av7110_ir_init(struct av7110 *av7110)
 void av7110_ir_exit(struct av7110 *av7110)
 {
 	rc_unregister_device(av7110->ir.rcdev);
+	rc_free_device(av7110->ir.rcdev);
 }
 
 //MODULE_AUTHOR("Holger Waechtler <holger@convergence.de>, Oliver Endriss <o.endriss@gmx.de>");
diff --git a/include/media/rc-core.h b/include/media/rc-core.h
index 35c7a0546f02e..7c964b5ad7926 100644
--- a/include/media/rc-core.h
+++ b/include/media/rc-core.h
@@ -81,7 +81,6 @@ struct lirc_fh {
 /**
  * struct rc_dev - represents a remote control device
  * @dev: driver model's view of this device
- * @managed_alloc: devm_rc_allocate_device was used to create rc_dev
  * @registered: set to true by rc_register_device(), false by
  *	rc_unregister_device
  * @idle: used to keep track of RX state
@@ -156,7 +155,6 @@ struct lirc_fh {
  */
 struct rc_dev {
 	struct device			dev;
-	bool				managed_alloc;
 	bool				registered;
 	bool				idle;
 	bool				encode_wakeup;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.6] HID: logitech-hidpp: fix race condition when accessing stale stack pointer

[Sasha Levin]

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

[ Upstream commit e2aaf2d3ad92ac4a8afa6b69ad4c38e7747d3d6e ]

The driver uses hidpp->send_receive_buf to point to a stack-allocated
buffer in the synchronous command path (__do_hidpp_send_message_sync).
However, this pointer is not cleared when the function returns.

If an event is processed (e.g. by a different thread) while the
send_mutex is held by a new command, but before that command has
updated send_receive_buf, the handler (hidpp_raw_hidpp_event) will
observe that the mutex is locked and dereference the stale pointer.

This results in an out-of-bounds access on a different thread's kernel
stack (or a NULL pointer dereference on the very first command).

Fix this by:
1. Clearing hidpp->send_receive_buf to NULL before releasing the mutex
   in the synchronous command path.
2. Moving the assignment of the local 'question' and 'answer' pointers
   inside the mutex_is_locked() block in the handler, and adding
   a NULL check before dereferencing.

Signed-off-by: Benoît Sevens <bsevens@google.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 to make a thorough analysis. Let me
compile my findings.

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Parse Subject Line**
- Record: Subsystem `HID: logitech-hidpp`, action verb `fix`, summary:
  race condition when accessing stale stack pointer (clear bug fix).

**Step 1.2: Parse Tags**
- Record: `Signed-off-by: Benoît Sevens <bsevens@google.com>` (author)
  and `Signed-off-by: Jiri Kosina <jkosina@suse.com>` (HID subsystem
  maintainer). No Reported-by/Link/Fixes tags. No stable tag. Author is
  a known Google security researcher (has other HID UAF/OOB fixes in
  roccat and wacom).

**Step 1.3: Analyze Body**
- Record: Bug description: `hidpp->send_receive_buf` is assigned to
  point at a stack-allocated response buffer inside
  `__do_hidpp_send_message_sync()` but never cleared when the function
  returns. Meanwhile `hidpp_raw_hidpp_event()` speculatively reads this
  pointer whenever `send_mutex` is locked. The race:
  1. Thread A finishes a command; leaves `send_receive_buf` pointing at
     A's stack.
  2. Thread B grabs `send_mutex`; there is a window before B writes
     `send_receive_buf = response`.
  3. Event handler fires (different thread), sees the mutex locked,
     dereferences the stale pointer from A's stack. The handler even
     performs `*answer = *report` — a WRITE to the stale stack pointer
     using device-supplied data (potential stack corruption / info leak
     / exploit primitive).
  4. On very first use, `send_receive_buf` is NULL → NULL deref.
     Symptom: OOB stack access on a different thread or NULL deref on
     first command.

**Step 1.4: Hidden Bug Detection**
- Record: Not hidden — commit title already says "fix race condition".
  Classic race + UAF/stale-pointer bug.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Record: One file changed (`drivers/hid/hid-logitech-hidpp.c`), +17/-7
  lines. Two functions touched: `__do_hidpp_send_message_sync()` and
  `hidpp_raw_hidpp_event()`. Classification: single-file surgical fix.

**Step 2.2: Code Flow Change**
- Record: Producer (`__do_hidpp_send_message_sync`): early returns
  converted to `goto out`, new `out:` label clears
  `hidpp->send_receive_buf = NULL` before returning. Consumer
  (`hidpp_raw_hidpp_event`): `question/answer` assignments moved inside
  the `mutex_is_locked()` block, plus `if (!question) return 0;` NULL
  guard before use.

**Step 2.3: Bug Mechanism**
- Record: Category (b)+(d) — race / memory safety fix. Adds implicit
  synchronization by ensuring the shared pointer is NULL'd while still
  holding `send_mutex`, and adds a NULL check on the read side to close
  the small window between mutex acquisition and pointer assignment.
  Addresses two failure modes: stale stack pointer dereference (UAF of
  stack memory) and NULL dereference on first use.

**Step 2.4: Fix Quality**
- Record: Obviously correct. Minimal. No new locks, no API/ABI changes.
  Possible (extremely minor) regression risk: if a report raced in
  between `mutex_lock` and the assignment, the early-out `return 0` will
  now skip matching it against the question — but this was already
  broken (it used a stale pointer) and the send path has a 5-second
  timeout with retry, so the benign behavior is strictly safer. No
  regression risk beyond that.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
- Record: The stale-pointer pattern (`hidpp->send_receive_buf =
  response;` and the speculative read `struct hidpp_report *question =
  hidpp->send_receive_buf;`) dates to commit `2f31c52529103d` "HID:
  Introduce hidpp" by Benjamin Tissoires, Sep 2014 (≈ v3.18). Bug is
  therefore present in every stable tree from v3.18 through
  v6.19/mainline.

**Step 3.2: Fixes: tag**
- Record: No `Fixes:` tag in the commit. Manually identified introducing
  commit as `2f31c52529103d` (original driver introduction, 2014).

**Step 3.3: Related Changes to the File**
- Record: Recent file history shows actively maintained file (device ID
  adds, quirks, other UAF fix `f7a4c78b` "Prevent use-after-free on
  force feedback initialisation failure"). Function was split into
  `__do_hidpp_send_message_sync`/`hidpp_send_message_sync` in
  `60165ab774cb0c` (v6.7, Jul 2023). Before that split (v6.6 is the
  earliest with `__do_hidpp_send_message_sync`), the logic lived inline
  in `hidpp_send_message_sync`.

**Step 3.4: Author's Other Commits**
- Record: Benoît Sevens (Google) has prior HID security fixes:
  `d802d848` (roccat UAF), `2f1763f6` (wacom OOB), plus similar fixes in
  uvcvideo and ALSA. Consistent pattern of Google-originated kernel
  security research. High trust.

**Step 3.5: Dependencies**
- Record: Self-contained, no prerequisites. Fix only touches one file
  and two functions. For v6.1.y and older the function was not yet
  split, so the fix requires trivial rewording to apply (move the NULL-
  out before `mutex_unlock` in `hidpp_send_message_sync`), but the
  change is mechanical.

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1: Original Discussion**
- Record: `b4 dig -c e2aaf2d3ad92a` found the thread at https://lore.ker
  nel.org/all/20260401144811.1242722-1-bsevens@google.com/. Only one
  version (v1) was posted; no review-imposed revisions.

**Step 4.2: Reviewers**
- Record: `b4 dig -w`: patch CC'd `Filipe Laíns`, `Bastien Nocera`,
  `Jiri Kosina`, `Benjamin Tissoires`, linux-input, linux-kernel — all
  the correct maintainers. Merged by Jiri Kosina (subsystem maintainer)
  with note: "Now applied. Benjamin had some ideas on further cleanup
  (allocating with __free__ instead of using stack pointer), but that'd
  be a little bigger cleanup, so let's keep that separate." Confirms
  maintainer reviewed and accepted; any follow-up is an orthogonal
  cleanup, not a fix correction.

**Step 4.3: Bug Reports**
- Record: No Reported-by or Link tags. Author is from Google — likely
  discovered via internal audit/fuzzing. No public reproducer cited.

**Step 4.4: Related Series**
- Record: Single standalone patch, no series.

**Step 4.5: Stable ML**
- Record: Not searched; the patch was only posted April 1, 2026 and
  applied soon after — too fresh for independent stable ML activity.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Key Functions**
- Record: `__do_hidpp_send_message_sync` (producer) and
  `hidpp_raw_hidpp_event` (consumer).

**Step 5.2: Callers**
- Record: 45 call sites for `hidpp_send_*_sync` inside the driver —
  every HID++ query (battery, connect, feature discovery, probe,
  get_report_length, etc.). `hidpp_raw_hidpp_event` is invoked from
  `hidpp_raw_event` (registered as `.raw_event` in `hid_ll_driver`),
  reached from the HID core for every HID report coming from any
  Logitech HID++ device (receivers, mice, keyboards, touchpads). Both
  paths fire during normal operation — not rare.

**Step 5.3: Callees**
- Record: Sync path calls `__hidpp_send_report()` (USB/Bluetooth
  transmit) and `wait_event_timeout()`. Event path does a struct-copy
  `*answer = *report` — this is the dangerous write when `answer` is
  stale.

**Step 5.4: Reachability**
- Record: The sync path runs in process context (probe, sysfs,
  workqueue). The event path runs from HID input processing (URB
  completion / BT callback, softirq or kthread depending on transport).
  Different contexts on different CPUs → true concurrent race possible.
  Triggers do not require privilege — any HID++ device that sends
  unsolicited reports while a command is in flight can race. This is the
  normal mode of operation for hidpp devices (connect events, battery
  notifications, keypresses).

**Step 5.5: Similar Patterns**
- Record: Only one occurrence of `send_receive_buf` in the file; pattern
  is unique to this driver.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable**
- Record: Verified via `git show <tag>:drivers/hid/hid-logitech-hidpp.c`
  that the exact same vulnerable pattern (`send_receive_buf = response`
  without clearing, `question = hidpp->send_receive_buf` read without
  NULL check) exists in v4.19, v5.4, v5.10, v5.15, v6.1, v6.6. All
  active stable trees are affected.

**Step 6.2: Backport Complications**
- Record: v6.6+ (and mainline): patch applies cleanly — identical
  function structure. v6.1 and earlier: `__do_hidpp_send_message_sync`
  does not yet exist; the logic is inline in `hidpp_send_message_sync`
  which also holds/releases `send_mutex`. Backport requires mechanically
  placing `hidpp->send_receive_buf = NULL;` before
  `mutex_unlock(&hidpp->send_mutex)` in `hidpp_send_message_sync`, and
  applying the event-handler hunk unchanged. Straightforward for the
  stable maintainers.

**Step 6.3: Related Fixes in Stable**
- Record: No prior independent fix for this specific race is in stable.
  Unrelated recent fixes (force-feedback UAF `f7a4c78b`) target other
  paths.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1: Criticality**
- Record: Subsystem: `drivers/hid/` HID++ Logitech driver. Logitech
  Unifying receivers/MX mice/keyboards are ubiquitous on laptops and
  desktops; the driver ships on most distributions. Classification:
  IMPORTANT (wide hardware user base), not CORE.

**Step 7.2: Activity**
- Record: Actively developed — multiple merges per release cycle (device
  IDs, quirks, bug fixes). Mature core codepaths in the driver have been
  stable for years.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Who Is Affected**
- Record: Anyone with a Logitech HID++ device (mice, keyboards,
  receivers, presenters) using the in-tree driver. Essentially most
  laptop users with Logitech peripherals. Driver-specific but very
  widespread hardware.

**Step 8.2: Trigger Conditions**
- Record: Requires concurrent activity: one thread invoking a sync
  command while the device sends an asynchronous report. Races happen
  during connect/disconnect, battery reporting, feature queries. The
  very-first-use path yields NULL deref (no concurrency needed: any
  async event before any sync command completes once) — but that path is
  rare because probe typically drives the first sync command before any
  report arrives. Attacker plane: a malicious or faulty HID device can
  flood reports to widen the window — reachable from device-trust
  boundary, relevant for BadUSB-style threat models.

**Step 8.3: Failure Mode Severity**
- Record: (a) NULL pointer dereference → kernel oops (CRITICAL: crash).
  (b) Stale stack pointer read → OOB read (HIGH: info leak). (c) Stale
  stack pointer WRITE via `*answer = *report` using device-controlled
  data → stack corruption on an unrelated thread (CRITICAL: memory
  corruption, potential privilege escalation/exploit primitive). Overall
  severity: CRITICAL.

**Step 8.4: Risk/Benefit**
- Record: Benefit HIGH — closes a long-standing race with
  crash/corruption potential in a widely-deployed driver. Risk LOW —
  24-line surgical change, no new locking, no API change, reviewed and
  applied by subsystem maintainer, only risk is a missed-answer timeout
  that already has retry logic and a 5-second wait. Ratio clearly favors
  backporting.

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence**
- FOR: Fixes real race/UAF/NULL-deref, very widespread hardware, small
  and surgical, author has security-fix track record, applied by
  subsystem maintainer, bug is 10+ years old (present in every active
  stable), failure modes include potential stack corruption from device-
  controlled data (security-relevant).
- AGAINST: No Reported-by/Fixes/Cc: stable tag; no public reproducer;
  for older stables (≤v6.1) a trivial mechanical adaptation is needed
  because the function was later split.
- UNRESOLVED: Exact kernel trigger rate in the wild is not documented;
  CVE status unknown.

**Step 9.2: Stable Rules**
1. Obviously correct & tested? Yes — tiny, mechanical; applied by
   maintainer.
2. Fixes real bug? Yes — race + stale/NULL pointer deref with concrete
   failure modes.
3. Important? Yes — kernel oops and potential stack corruption.
4. Small & contained? Yes — 24 lines, one file, two functions.
5. No new features/APIs? Correct — pure fix.
6. Applies to stable? v6.6+: clean. ≤v6.1: needs trivial adaptation.

**Step 9.3: Exceptions**
- Not an exception category; qualifies on normal bug-fix merit.

**Step 9.4: Decision**
- The commit is a textbook stable candidate: small, targeted race fix in
  a broadly used driver, repairing a NULL-deref + stale-pointer write
  that a faulty/malicious device can provoke.

### Verification

- [Phase 1] Read full commit message — no Fixes/Reported-by/Cc: stable
  tags; identified bug description and two-step fix.
- [Phase 2] Read diff end-to-end; confirmed +17/-7 in one file, two
  functions, classic NULL-out + NULL-check pattern with `goto out`.
- [Phase 3] `git blame` on both functions: pattern dates to
  `2f31c52529103d` (2014, v3.18). Split into
  `__do_hidpp_send_message_sync` at `60165ab774cb0c` (v6.7).
- [Phase 3] `git log --oneline -- drivers/hid/hid-logitech-hidpp.c`:
  file is actively maintained.
- [Phase 3] `git log --oneline --author="Benoit Sevens\|Benoît Sevens"`:
  confirmed author's pattern of HID/UVC/ALSA security fixes.
- [Phase 4] `b4 dig -c e2aaf2d3ad92a`: found lore thread at `https://lor
  e.kernel.org/all/20260401144811.1242722-1-bsevens@google.com/`.
- [Phase 4] `b4 dig -w`: confirmed CC list includes Jiri Kosina,
  Benjamin Tissoires, Filipe Laíns, Bastien Nocera, linux-input, linux-
  kernel.
- [Phase 4] `b4 dig -a`: only v1 was posted; no further revisions.
- [Phase 4] Read `/tmp/hidpp_race.mbox`: confirmed maintainer Jiri
  Kosina's "Now applied" reply and note about deferred cleanup idea from
  Benjamin Tissoires.
- [Phase 5] `rg send_receive_buf`: confirmed only 4 references (struct
  member + 1 write + 2 reads), no other use sites.
- [Phase 5] Read `hidpp_raw_event` caller: confirmed registered as
  `.raw_event` and called for every HID++ short/long/very-long report
  from the device.
- [Phase 6] `git show vX:drivers/hid/hid-logitech-hidpp.c` for v4.19,
  v5.4, v5.10, v5.15, v6.1, v6.6: verified vulnerable pattern exists in
  every stable tree.
- [Phase 6] Verified `__do_hidpp_send_message_sync` only exists from
  v6.6 onward; older trees need trivial adaptation of the producer hunk.
- [Phase 8] Reviewed event handler body: `*answer = *report` is a write,
  confirming the stack-corruption / write-primitive aspect (not merely
  an info leak).
- UNVERIFIED: Whether a CVE was assigned; whether a public reproducer
  exists; exact in-wild trigger rate.

The fix is small, surgical, reviewed by the HID maintainer, repairs a
long-standing race with crash and stack-corruption consequences
affecting extremely common Logitech hardware, and backports cleanly to
recent stables with only a mechanical adjustment needed for older ones.

**YES**

 drivers/hid/hid-logitech-hidpp.c | 24 +++++++++++++++++-------
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 5f63f1d2303a0..b1330d23bd2d0 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -306,21 +306,22 @@ static int __do_hidpp_send_message_sync(struct hidpp_device *hidpp,
 	if (ret) {
 		dbg_hid("__hidpp_send_report returned err: %d\n", ret);
 		memset(response, 0, sizeof(struct hidpp_report));
-		return ret;
+		goto out;
 	}
 
 	if (!wait_event_timeout(hidpp->wait, hidpp->answer_available,
 				5*HZ)) {
 		dbg_hid("%s:timeout waiting for response\n", __func__);
 		memset(response, 0, sizeof(struct hidpp_report));
-		return -ETIMEDOUT;
+		ret = -ETIMEDOUT;
+		goto out;
 	}
 
 	if (response->report_id == REPORT_ID_HIDPP_SHORT &&
 	    response->rap.sub_id == HIDPP_ERROR) {
 		ret = response->rap.params[1];
 		dbg_hid("%s:got hidpp error %02X\n", __func__, ret);
-		return ret;
+		goto out;
 	}
 
 	if ((response->report_id == REPORT_ID_HIDPP_LONG ||
@@ -328,10 +329,14 @@ static int __do_hidpp_send_message_sync(struct hidpp_device *hidpp,
 	    response->fap.feature_index == HIDPP20_ERROR) {
 		ret = response->fap.params[1];
 		dbg_hid("%s:got hidpp 2.0 error %02X\n", __func__, ret);
-		return ret;
+		goto out;
 	}
 
-	return 0;
+	ret = 0;
+
+out:
+	hidpp->send_receive_buf = NULL;
+	return ret;
 }
 
 /*
@@ -3843,8 +3848,7 @@ static int hidpp_input_configured(struct hid_device *hdev,
 static int hidpp_raw_hidpp_event(struct hidpp_device *hidpp, u8 *data,
 		int size)
 {
-	struct hidpp_report *question = hidpp->send_receive_buf;
-	struct hidpp_report *answer = hidpp->send_receive_buf;
+	struct hidpp_report *question, *answer;
 	struct hidpp_report *report = (struct hidpp_report *)data;
 	int ret;
 	int last_online;
@@ -3854,6 +3858,12 @@ static int hidpp_raw_hidpp_event(struct hidpp_device *hidpp, u8 *data,
 	 * previously sent command.
 	 */
 	if (unlikely(mutex_is_locked(&hidpp->send_mutex))) {
+		question = hidpp->send_receive_buf;
+		answer = hidpp->send_receive_buf;
+
+		if (!question)
+			return 0;
+
 		/*
 		 * Check for a correct hidpp20 answer or the corresponding
 		 * error
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] HID: logitech-hidpp: Check bounds when deleting force-feedback effects

[Sasha Levin]

From: Günther Noack <gnoack@google.com>

[ Upstream commit e606d8329be1e19b7eb3e0c6c72a73cbbb25ae3d ]

Without this bounds check, this might otherwise overwrite index -1.

Triggering this condition requires action both from the USB device and from
userspace, which reduces the scenarios in which it can be exploited.

Cc: Lee Jones <lee@kernel.org>
Signed-off-by: Günther Noack <gnoack@google.com>
Reviewed-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Parse subject line**
Record: Subsystem `HID: logitech-hidpp:`, action verb `Check` (adding a
missing check). Summary: add missing bounds-check when deleting force-
feedback effects.

**Step 1.2: Parse commit message tags**
Record:
- `Cc: Lee Jones <lee@kernel.org>` (HID area reviewer, not stable)
- `Signed-off-by: Günther Noack <gnoack@google.com>` (author - Google
  security engineer)
- `Reviewed-by: Lee Jones <lee@kernel.org>`
- `Signed-off-by: Jiri Kosina <jkosina@suse.com>` (HID maintainer)
- **NOT** present: `Cc: stable@vger.kernel.org`, `Fixes:`, `Reported-
  by:`, `Link:`
- No syzbot, no user bug report, no sanitizer report

**Step 1.3: Analyze commit body**
Record: Author describes a missing bounds check that "might otherwise
overwrite index -1". Explicitly notes reduced exploitability:
"Triggering this condition requires action both from the USB device and
from userspace, which reduces the scenarios in which it can be
exploited." This is a security-hardening fix with an author-acknowledged
limited attack surface.

**Step 1.4: Hidden bug fix?**
Record: Not hidden at all - clearly a bug fix (missing bounds check
preventing OOB write). The "Check bounds" phrasing is classic stable-
style bug fix language.

### PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
Record: 1 file modified: `drivers/hid/hid-logitech-hidpp.c`. 9 lines
added, 6 removed. Single function modified: `hidpp_ff_work_handler()`,
single switch case: `HIDPP_FF_DESTROY_EFFECT`. Classification: single-
file surgical fix.

**Step 2.2: Code flow change**
Record:
- BEFORE: In `HIDPP_FF_DESTROY_EFFECT`, unconditionally writes
  `data->effect_ids[wd->params[0]-1] = -1` when `effect_id >= 0`. No
  bounds check on `wd->params[0]`.
- AFTER: First reads `slot = wd->params[0]`, then wraps the writes in
  `if (slot > 0 && slot <= data->num_effects)`.
- This is an error-path / invalid-state handling fix, but on a normal
  runtime path.

**Step 2.3: Bug mechanism**
Record: Category (f) Memory safety - bounds check added. Specific
mechanism: `wd->params[0]` is set by `hidpp_ff_find_effect()` (line
2478), which returns 0 when the requested `effect_id` is not present in
`data->effect_ids[]`. For `HIDPP_FF_EFFECTID_AUTOCENTER`, it's set to
`data->slot_autocenter` (initially 0 before autocenter is uploaded).
When `params[0] == 0`, the expression `params[0] - 1` promotes through
int arithmetic to `-1`, causing `data->effect_ids[-1] = -1` - an out-of-
bounds write of a fixed value `-1` at index `-1` of a
`kzalloc`-allocated `int*` array. The analogous
`HIDPP_FF_DOWNLOAD_EFFECT` case (lines 2493-2502) already contains the
exact same defensive check `if (slot > 0 && slot <= data->num_effects)`
- this fix restores symmetry.

**Step 2.4: Fix quality**
Record: Obviously correct - mirrors existing defensive check from the
same function's DOWNLOAD case. Minimal/surgical. Zero regression risk:
the added condition only suppresses an invalid index write; it doesn't
restrict any legitimate behavior. No red flags.

### PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: git blame**
Record: The buggy `HIDPP_FF_DESTROY_EFFECT` handler was introduced by
commit `ff21a635dd1a9c` (Edwin Velds, 2016-01-11) "HID: logitech-hidpp:
Force feedback support for the Logitech G920". `git describe --contains`
places it at `v4.6-rc1~107^2^4~1` - first appeared in v4.6. The code has
been stable for ~10 years and is present in every supported stable tree.

**Step 3.2: Follow Fixes: tag**
Record: No `Fixes:` tag in the commit, but git blame identifies the
introducing commit as `ff21a635dd1a9c` (v4.6). That original commit is
in all stable trees that fork from ≥v4.6, which is every currently-
supported stable tree (5.4, 5.10, 5.15, 6.1, 6.6, 6.12, 6.19).

**Step 3.3: Related recent changes**
Record: Recent related work:
- `f7a4c78bfeb32` (Feb 2026) - Lee Jones, "Prevent use-after-free on
  force feedback initialisation failure" - UAF fix in same FF path, no
  `Cc: stable`.
- `1547d41f9f19d` (Jan 2026) - Günther Noack, "Check maxfield in
  hidpp_get_report_length()" - hardening fix, **has** `Cc: stable`.
- This commit is standalone and self-contained; not part of a series (b4
  dig -a shows only v1).

**Step 3.4: Author's other commits**
Record: Günther Noack (Google) has been actively hardening HID drivers
against malicious/fake USB devices: `HID: asus: avoid memory leak`,
`HID: magicmouse: Do not crash on missing msc->input` (+Cc stable),
`HID: prodikeys: Check presence of pm->input_ep82` (+Cc stable), `HID:
logitech-hidpp: Check maxfield in hidpp_get_report_length()` (+Cc
stable). Author is credible, security-focused, and knows stable
conventions.

**Step 3.5: Dependencies**
Record: No dependencies. Standalone, self-contained fix.

### PHASE 4: MAILING LIST / EXTERNAL RESEARCH

**Step 4.1: b4 dig original submission**
Record: `b4 dig -c e606d8329be1e` returned a single-message thread at `h
ttps://lore.kernel.org/all/20260331074052.194064-1-gnoack@google.com/`.
`b4 dig -a` confirms only v1 was posted - no revision history.

**Step 4.2: Recipients**
Record: `b4 dig -w` shows patch was sent to Filipe Laíns, Bastien
Nocera, Jiri Kosina (HID maintainer), Benjamin Tissoires (HID co-
maintainer), Lee Jones, linux-input@vger.kernel.org, linux-
kernel@vger.kernel.org. Appropriate audience.

**Step 4.3: Bug report**
Record: No bug report referenced; no syzbot/KASAN/KMSAN tag. Appears to
be a code-audit / hardening finding by the author.

**Step 4.4: Thread discussion**
Record: Thread saved to `/tmp/hidpp_thread.mbox`. Contents:
- Lee Jones: "LGTM. Reviewed-by: Lee Jones <lee@kernel.org>"
- Jiri Kosina: "Applied, thanks."
- **No reviewer suggested `Cc: stable`**. No NAKs, no concerns raised.

**Step 4.5: Stable-list discussion**
Record: No evidence of prior stable-list discussion for this particular
bug.

### PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions in diff**
Record: Only `hidpp_ff_work_handler()` (switch case
`HIDPP_FF_DESTROY_EFFECT`).

**Step 5.2: Callers / trigger path**
Record: `hidpp_ff_work_handler` is the workqueue callback scheduled by
`hidpp_ff_queue_work()`. The DESTROY path is queued by
`hidpp_ff_erase_effect()` (line 2712), which is assigned to `ff->erase`
(line 2877). `ff->erase` is the standard input-layer callback invoked
when userspace calls `EVIOCRMFF` ioctl on `/dev/input/eventX` of the FF
device. So the buggy code is reachable via a standard userspace ioctl on
any user with access to the device node (typically needs `input` group
membership, or root).

**Step 5.3: Callees**
Record: `hidpp_ff_find_effect()` iterates `data->effect_ids[]` and
returns `i+1` if found, `0` otherwise. The return value `0` directly
causes the `params[0]-1 = -1` OOB when the destroy command proceeds.

**Step 5.4: Reachability**
Record: Buggy path is reachable from userspace: `EVIOCRMFF` ioctl →
`ff->erase` → `hidpp_ff_erase_effect` →
`hidpp_ff_queue_work(HIDPP_FF_DESTROY_EFFECT)` → workqueue →
`hidpp_ff_work_handler`. Needs a Logitech HID++ FF-capable device (e.g.,
G920 wheel) and a userspace condition that erases an effect not present
in the driver's tracking array (race between operations, stale
effect_id, or autocenter destroy before upload).

**Step 5.5: Similar patterns**
Record: The same function already has the correct pattern in
`HIDPP_FF_DOWNLOAD_EFFECT` (lines 2494-2502): `slot =
response.fap.params[0]; if (slot > 0 && slot <= data->num_effects) { ...
}`. This fix brings DESTROY into symmetry with DOWNLOAD.

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

**Step 6.1: Buggy code in stable trees?**
Record: The buggy code was added in v4.6 (Jan 2016) and is virtually
unchanged since then (blame shows only a whitespace/comment tweak in
2024). Present in every supported stable tree: 5.4.y, 5.10.y, 5.15.y,
6.1.y, 6.6.y, 6.12.y, 6.19.y.

**Step 6.2: Backport complications**
Record: Minimal. Recent churn in the function: Yan Zhen (2024, comment
typo fix) and Lee Jones (2026, adjacent UAF fix in init path - not this
function). The switch statement body targeted by this patch is identical
to what has been in the tree since 2016. Clean apply expected on all
stable branches, modulo trivial context adjustments.

**Step 6.3: Related fixes in stable**
Record: No prior fix for this specific OOB. Some adjacent FF hardening
(UAF fix `f7a4c78bfeb32`) exists in mainline but also lacks Cc: stable.

### PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: Subsystem criticality**
Record: `drivers/hid/hid-logitech-hidpp.c` - HID driver for specific
Logitech HID++ devices (G920 wheel, MX mice, etc.). Classification:
PERIPHERAL (hardware-specific driver), but FF is a userspace-reachable
subsystem where games commonly issue erase/upload ioctls, so realistic
number of users on systems with a G920/G923 wheel.

**Step 7.2: Subsystem activity**
Record: Actively developed, with a mix of feature additions (new device
support) and security hardening (see Günther Noack's string of commits).
Mature codebase.

### PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected users**
Record: Users of Logitech HID++ FF-capable devices (G920/G923 wheels and
similar). Not universal - driver-specific. Requires the device to be
plugged in and a userspace FF client (game, test tool, etc.).

**Step 8.2: Trigger conditions**
Record: Author states "requires action both from the USB device and from
userspace." In practice: userspace invokes `EVIOCRMFF` with an effect_id
that the driver cannot find in `data->effect_ids[]` (e.g., effect never
uploaded, already erased, or device returned unexpected slot) AND the
device responds successfully to the destroy command. Not triggerable by
an unprivileged attacker alone; requires access to the evdev node.

**Step 8.3: Failure mode**
Record: Out-of-bounds write of the fixed value `-1` (`0xFFFFFFFF`) at
index `-1` of the `kzalloc`ed `data->effect_ids[]` array (an `int *`).
This corrupts 4 bytes immediately before the allocation - likely slab
metadata / redzone or an adjacent slab object. Severity: HIGH (memory
corruption), but with limited exploitability because (a) both value and
offset are fixed (not attacker-controlled), (b) requires non-trivial
combination of device + userspace state. Not directly security-critical
as a remote/local privilege escalation primitive, but an unambiguous
memory-safety bug.

**Step 8.4: Benefit/risk**
Record:
- BENEFIT: Fixes a 10-year-old memory-corruption bug in a userspace-
  reachable code path. Medium-low because the trigger is narrow, but
  non-zero - silent slab corruption can manifest as hard-to-debug
  crashes.
- RISK: Extremely low. 9-line purely additive bounds-check that mirrors
  an existing check in the same function. Zero regression potential on
  normal operation.
- Ratio: Low benefit but near-zero risk → favorable for stable.

### PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Clear out-of-bounds memory write (OOB pattern - recognized stable
  category).
- Bug present in all stable trees since v4.6 (2016).
- Fix is 9 lines, in a single function, obviously correct.
- Mirrors existing defensive check in the same function
  (`HIDPP_FF_DOWNLOAD_EFFECT`).
- Reviewed by Lee Jones; applied by HID maintainer Jiri Kosina.
- Author is a security-focused developer doing ongoing HID hardening.
- Clean apply expected on all stable branches.
- Zero regression risk.

**Evidence AGAINST backporting:**
- Author explicitly noted reduced exploitability ("requires action both
  from the USB device and from userspace").
- Author did NOT include `Cc: stable@vger.kernel.org`, despite including
  it on several similar HID hardening commits in the same timeframe.
  This is a deliberate signal from a stable-aware author.
- No `Fixes:` tag, no bug report, no syzbot/KASAN evidence of real-world
  triggers.
- Trigger requires specific hardware (Logitech FF wheel) + specific
  userspace sequence.
- Bug has been present 10 years without reported user impact.

**Stable rules checklist:**
1. Obviously correct and tested? YES - mirrors existing pattern;
   reviewed and applied.
2. Fixes a real bug? YES - OOB write is a real memory-safety bug.
3. Important issue? BORDERLINE - memory corruption but with narrow, non-
   attacker-controlled trigger.
4. Small and contained? YES - 9 insertions, 6 deletions, one function.
5. No new features? YES - pure defensive check.
6. Applies cleanly? YES - expected clean on all active stable branches.

**Exception categories:** Not applicable (not a device-
ID/quirk/DT/build/doc fix).

**Decision rationale:**
This is a borderline case. Technically, it is a legitimate memory-safety
fix for a bug in userspace-reachable code that has been in the tree for
a decade. The patch is small, obviously correct, and zero-risk. OOB
writes are a canonical stable-backport category per the rule set.

The strongest counter-signal is the author's deliberate omission of `Cc:
stable` while including it on peer hardening patches, combined with the
explicit statement about limited exploitability. However, per the task
instructions, the absence of `Cc: stable` is explicitly NOT a negative
signal, and the technical criteria for stable are met.

Weighing the risk (near-zero) against the benefit (fixes a real OOB
write, even if rarely triggered), this is the kind of defensive bounds-
check fix that stable trees routinely accept. Memory corruption with a
hardcoded value at a hardcoded offset is still memory corruption.

### Verification

- [Phase 1] Parsed tags from commit message: found Signed-off-by (Noack,
  Kosina), Reviewed-by (Jones), Cc (Jones). No `Cc: stable`, no
  `Fixes:`, no `Reported-by:`, no `Link:`.
- [Phase 2] Diff analysis: 9 lines added, 6 removed, single file, single
  function (`hidpp_ff_work_handler`), single case
  (`HIDPP_FF_DESTROY_EFFECT`). Confirmed by `git show e606d8329be1e`.
- [Phase 2] Confirmed symmetry with existing check in
  `HIDPP_FF_DOWNLOAD_EFFECT` by reading `drivers/hid/hid-logitech-
  hidpp.c` lines 2493-2511.
- [Phase 3] `git blame -L 2502,2515 drivers/hid/hid-logitech-hidpp.c`:
  buggy code introduced by `ff21a635dd1a9c` (Edwin Velds, 2016-01-11).
- [Phase 3] `git describe --contains ff21a635dd1a9c`:
  `v4.6-rc1~107^2^4~1` (present since v4.6, 2016).
- [Phase 3] `git log --author="gnoack@google.com" --oneline`: confirmed
  author's pattern of HID hardening work, including `Cc: stable`-tagged
  peer commits (`17abd396`, `cee8337e`, `1547d41f`).
- [Phase 4] `b4 dig -c e606d8329be1e`: matched single thread at
  `lore.kernel.org/all/20260331074052.194064-1-gnoack@google.com/`.
- [Phase 4] `b4 dig -a`: only v1 was posted - no revisions.
- [Phase 4] `b4 dig -w`: recipients include HID maintainers (Kosina,
  Tissoires) and linux-input.
- [Phase 4] Read saved mbox `/tmp/hidpp_thread.mbox`: Lee Jones gave
  Reviewed-by, Jiri Kosina said "Applied, thanks." No stable request or
  concerns raised.
- [Phase 5] Confirmed reachability: `hidpp_ff_erase_effect()` wired to
  `ff->erase` (line 2877), reachable via `EVIOCRMFF` ioctl. Confirmed
  `hidpp_ff_find_effect` returns 0 when effect not found (line 2457).
- [Phase 5] Confirmed the buggy `params[0]-1 = -1` path when the
  returned slot is 0.
- [Phase 6] Confirmed `ff21a635dd1a9c` pre-dates all active stable
  branches (branch points are all after v4.6).
- [Phase 7] Subsystem `drivers/hid/` - PERIPHERAL driver for specific
  Logitech HID++ devices with FF.
- [Phase 8] Failure mode: OOB write of fixed value `-1` at fixed offset
  `-1` → slab corruption, severity HIGH but limited exploitability
  primitive.
- UNVERIFIED: Did not run per-branch apply test on each stable tree, but
  the function body is unchanged since 2016 so clean apply is highly
  likely.
- UNVERIFIED: Could not find any user-reported crash or bug report
  pointing to this specific OOB (no bug-tracker links in the commit
  message or on the mailing list).

The fix is small, obviously correct, low-risk, and addresses a real out-
of-bounds write in a userspace-reachable path. Even with the author's
deliberate omission of `Cc: stable`, the technical stable criteria are
met, and bounds-check fixes of this nature are routinely backported.

**YES**

 drivers/hid/hid-logitech-hidpp.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index d1dea7297712d..5f63f1d2303a0 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -2502,12 +2502,15 @@ static void hidpp_ff_work_handler(struct work_struct *w)
 		}
 		break;
 	case HIDPP_FF_DESTROY_EFFECT:
-		if (wd->effect_id >= 0)
-			/* regular effect destroyed */
-			data->effect_ids[wd->params[0]-1] = -1;
-		else if (wd->effect_id >= HIDPP_FF_EFFECTID_AUTOCENTER)
-			/* autocenter spring destroyed */
-			data->slot_autocenter = 0;
+		slot = wd->params[0];
+		if (slot > 0 && slot <= data->num_effects) {
+			if (wd->effect_id >= 0)
+				/* regular effect destroyed */
+				data->effect_ids[slot-1] = -1;
+			else if (wd->effect_id >= HIDPP_FF_EFFECTID_AUTOCENTER)
+				/* autocenter spring destroyed */
+				data->slot_autocenter = 0;
+		}
 		break;
 	case HIDPP_FF_SET_GLOBAL_GAINS:
 		data->gain = (wd->params[0] << 8) + wd->params[1];
-- 
2.53.0