[REGRESSION] amd_sfh: accelerometer broken since 6.19 ("Event data for report 1 was too short (15 vs 14)")

[REGRESSION] amd_sfh: accelerometer broken since 6.19 ("Event data for report 1 was too short (15 vs 14)")

[Andrej Scek]

Hardware:  Lenovo Yoga 7 14ARP8 (82YM), AMD Ryzen 7 7735U (Rembrandt),
BIOS LCCN18WW (2023-09-16)
Distro:    Fedora 43
Component: amd_sfh / hid-sensor-hub / hid_sensor_accel_3d

Working:   6.18.13-200.fc43, 6.18.16-200.fc43
Broken:    6.19.12-200.fc43, 7.2.8-100.fc43

Description:
Screen auto-rotation stopped working after updating from 6.18.16 to 6.19.12.
Since 6.19, every boot logs repeated warnings from the AMD Sensor Fusion Hub
accelerometer, and iio-sensor-proxy never receives usable orientation data.
Booting back into 6.18.16 restores rotation, with the same BIOS and userspace.

Kernel log on 6.19.12 / 7.2.8 (zero occurrences on 6.18.x):
  hid-sensor-hub 0020:1022:0001.0003: hidraw2: SENSOR HUB HID v0.00
Device [hid-amdsfh 1022:0001] on pcie_mp2_amd
  hid-sensor-hub 0020:1022:0001.0003: Event data for report 1 was too
short (15 vs 14)
  (repeats 13-86 times per boot, whenever the device is moved)

Occurrences per boot, from the journal:
  6.18.16: 0, 0, 0
  6.19.12: 13, 31, 21, 86, 70, 39, 19, 25, 74
  7.2.8:   12

monitor-sensor output:
  6.18.16: === Has accelerometer (orientation: normal, tilt: vertical)
  -> rotates correctly
  7.2.8:   === Has accelerometer (orientation: undefined, tilt:
vertical) -> never changes

Steps to reproduce:
1. Boot 6.19 or newer on this machine
2. Run monitor-sensor and rotate the device in tablet mode
3. Orientation stays "undefined"/unchanged; dmesg shows "Event data
for report 1 was too short (15 vs 14)"

Notes:
  - Not bisected yet. From a quick look at the git history,
drivers/hid/hid-core.c
    and drivers/hid/amd-sfh-hid/ have no changes between v6.18 and
v6.19; the only
    hid-sensor-hub change in that window is b3e5bcffda37 ("HID: hid-sensor-hub:
    Use pm_ptr instead of #ifdef CONFIG_PM"). So the cause may be elsewhere.
  - iio-sensor-proxy 3.8-1.fc43, GNOME Shell 49
  - Happy to test patches or bisect between v6.18 and v6.19.

Additional info:
- iio-sensor-proxy 3.8-1.fc43, GNOME Shell 49
- Happy to test patches or bisect between 6.18 and 6.19.

Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=2545224

#regzbot introduced: v6.18..v6.19

Re: [REGRESSION] amd_sfh: accelerometer broken since 6.19 ("Event data for report 1 was too short (15 vs 14)")

[Andrej Scek]

Update: this looks like it is caused by

  0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")

which was backported to the 6.18.y and 6.19.y stable trees on 2026-04-11.
6.18.16 predates that backport and works; 6.19.12 and 7.2.8 contain it and
fail. The AMD SFH sends 14-byte reports where the descriptor declares 15, and
those are now rejected instead of zero-padded. (This corrects my earlier note
that hid-core had no relevant changes; I had only checked v6.18..v6.19.)

The same symptom on another AMD SFH device (Legion Go S, "18 vs 14"):
https://github.com/ublue-os/bazzite/issues/5796

So AMD SFH (hid-amdsfh 1022:0001) probably needs to be covered by whatever
short-report quirk/fix is adopted for this.

#regzbot introduced: 0a3fe972a7cb

Thanks,
Andrej

Re: [REGRESSION] amd_sfh: accelerometer broken since 6.19 ("Event data for report 1 was too short (15 vs 14)")

[Lee Jones]

On Fri, 02 Oct 2026, Andrej Scek wrote:

> Update: this looks like it is caused by
> 
>   0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
> 
> which was backported to the 6.18.y and 6.19.y stable trees on 2026-04-11.
> 6.18.16 predates that backport and works; 6.19.12 and 7.2.8 contain it and
> fail. The AMD SFH sends 14-byte reports where the descriptor declares 15, and
> those are now rejected instead of zero-padded. (This corrects my earlier note
> that hid-core had no relevant changes; I had only checked v6.18..v6.19.)
> 
> The same symptom on another AMD SFH device (Legion Go S, "18 vs 14"):
> https://github.com/ublue-os/bazzite/issues/5796
> 
> So AMD SFH (hid-amdsfh 1022:0001) probably needs to be covered by whatever
> short-report quirk/fix is adopted for this.
> 
> #regzbot introduced: 0a3fe972a7cb

This is on my radar.  Leave it with me.

-- 
Lee Jones