summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-08-03HID: picolcd: clamp eeprom debugfs read to bytes actually receivedIbrahim Hashimov
picolcd_debug_eeprom_read() trusts resp->raw_data[2] -- a length byte supplied by the device in its REPORT_EE_DATA reply -- clamped only to the caller's read() count: ret = resp->raw_data[2]; if (ret > s) ret = s; if (copy_to_user(u, resp->raw_data+3, ret)) It never checks resp->raw_size, the number of bytes picolcd_raw_event() actually copied into the 64-byte raw_data[] of the kmalloc'd struct picolcd_pending. A device (or a spoofed picoLCD) returning a length byte of 0xff, read with a count >= 255, makes copy_to_user() read past raw_data[] into adjacent slab memory and return it to userspace through the debugfs "eeprom" file: BUG: KASAN: slab-out-of-bounds in _copy_to_user Read of size 255 ... picolcd_debug_eeprom_read+0x214/0x2f0 [hid_picolcd] The debug-dump path in the same file already validates the device length byte against the received size before trusting it; this read does not. The file is created S_IRUSR (root-only) and a crafted device is needed, so it is neither unprivileged- nor remotely-triggerable. Clamp the copy length to resp->raw_size - 3 (the payload actually received, minus the 3-byte header), floored at 0 for short replies. Fixes: 9bbf2b98ba11 ("HID: add experimental access to PicoLCD device's EEPROM and FLASH") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov <security@auditcode.ai> Assisted-by: AuditCode-AI:2026.07 Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: apple: use the standard keyboard backlight LED nameAndre Eikmeyer
The T2-attached butterfly keyboard backlight is exposed as apple::kbd_backlight. This leaves the color field empty and gives userspace a model-specific name for the same white keyboard-backlight function exposed by Magic Keyboards. Magic Keyboard backlight support was added later and already follows the current LED naming convention. As a result, userspace has to handle two different names for the same function. We should use :white:kbd_backlight for both implementations. This follows the LED color and function naming convention and lets userspace discover either keyboard generation without a special case for the butterfly models. Signed-off-by: Andre Eikmeyer <dev@deq.rocks> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: apple: preserve keyboard backlight across T2 resumeAndre Eikmeyer
The T2 virtual USB host controller re-enumerates the internal keyboard after system resume. The butterfly keyboard backlight currently uses LED_CORE_SUSPENDRESUME, so the LED core sends a blocking request to the old HID device while it is disappearing. That request fails with -ENODEV and the newly probed device starts with its backlight off. To fix this, we cache the requested brightness when the old HID device is removed and restore it when the replacement is probed. We let re-enumeration handle restoration instead of issuing a request through the stale device. Fixes: 1f95a6cd5ad7 ("HID: apple: ensure the keyboard backlight is off if suspending") Cc: stable@vger.kernel.org Signed-off-by: Andre Eikmeyer <dev@deq.rocks> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03drm/panel-edp: Add Sharp LQ120P1JX51 (Surface Pro 12in 1st Ed.)François Roux
The internal eDP panel of the Microsoft Surface Pro 12in 1st Edition (Snapdragon X Plus, X1P42100) is not in edp_panels[], so every boot produces the deliberate WARN_ON splat in panel_edp_probe() and the panel falls back to conservative timings: WARNING: drivers/gpu/drm/panel/panel-edp.c:814 panel_edp_probe+0x53c/0x56c panel-simple-dp-aux aux-aea0000.displayport-controller: Unknown panel SHP 0x15a7, using conservative timings EDID, read over the panel's DP AUX DDC bus: 00 ff ff ff ff ff ff 00 4d 10 a7 15 a0 00 00 1f 31 22 01 04 a5 19 11 78 07 ee 91 a3 54 4c 99 26 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 62 53 94 a0 80 b8 2e 50 18 10 3a 00 fe a9 00 00 00 18 13 7d 94 a0 80 b8 2e 50 18 10 3a 00 fe a9 00 00 00 18 00 00 00 fd 00 18 5a 88 88 21 01 00 00 00 00 00 00 00 00 00 00 fc 00 4c 51 31 32 30 50 31 4a 58 35 31 0a 20 00 69 Manufacturer: SHP Model: 0x15a7 Made in: week 49 of 2024 Display Product Name: 'LQ120P1JX51' DTD 1: 2196x1464 60.001799 Hz 3:2 (254 mm x 169 mm) DTD 2: 2196x1464 90.002698 Hz 3:2 (254 mm x 169 mm) Timings are deliberately cautious rather than datasheet-derived. The conservative fallback sets unprepare=2000 and enable=200; unprepare=2000 is a safety margin for unknown panels only and is the single occurrence of that value in the file -- no real panel entry uses it. delay_200_500_e200 keeps the same generous 200 ms enable delay while using the 500 ms unprepare shared by every actual panel in the table. A shorter enable delay may well be fine, but has not been validated here. Signed-off-by: François Roux <info@humanlearning.ch> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260802135107.4420-1-info@humanlearning.ch
2026-08-03HID: intel-ish-hid: ignore post-init ENUM_DEVICES from firmwareWahid Khan
Some ISH firmware versions (observed on Tiger Lake LP, 8086:a0fc, GUID {33AECD58-B679-4E54-9BD9-A04D34F0C226}) periodically re-send an unsolicited HOSTIF_DM_ENUM_DEVICES response roughly every 79 seconds. The current guard collapses two distinct cases into one condition: if (!(response_flag) || init_done) -> bad packet + ish_hw_reset This incorrectly treats a valid post-init firmware announcement as a corrupted packet, triggering an ISH soft-reset and a full ISHTP re-initialisation cycle on each occurrence (~1100 times per day on affected hardware). Split the check: reject messages with no response flag as before, but simply discard valid ENUM_DEVICES messages that arrive after init is complete. Signed-off-by: Wahid Khan <wahidzk0091@gmail.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Tested-by: Zhang Lixu <lixu.zhang@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03hwmon: (pmbus) Fix type confusion in notification logicGuenter Roeck
Sashiko reports: At the start of the loop in pmbus_notify(), the code unconditionally casts every attribute to a struct sensor_device_attribute: drivers/hwmon/pmbus/pmbus_core.c:pmbus_notify() { for (i = 0; i < data->num_attributes; i++) { struct device_attribute *da = to_dev_attr(data->group.attrs[i]); struct sensor_device_attribute *attr = to_sensor_dev_attr(da); int index = attr->index; ... } However, data->group.attrs can contain other types like struct pmbus_samples_reg or struct pmbus_sensor, which only embed a base struct device_attribute. If da is a struct pmbus_samples_reg, dev_attr is the last member. Casting it to struct sensor_device_attribute and reading the index field appears to access memory past the end of the allocation, which might trigger a slab-out-of-bounds read. Additionally, if da is a struct pmbus_sensor, casting it causes the index field to overlap with the page, phase, and reg fields. Could this produce a garbage mask on little-endian systems that spuriously matches the target reg, page, and flags during an alert? Fix the problem by using struct sensor_device_attr in struct pmbus_sensor and struct pmbus_label. Since those attributes never trigger a notification, set the value of attr->index to -1 for them. Use this value to distinguish from boolean attributes which _can_ trigger a notification and use the index field to encode mask, page, and register values. Fixes: f469bde9afd1 ("hwmon: (pmbus/core) Notify hwmon events") Cc: Vincent Jardin <vjardin@free.fr> Tested-by: Vincent Jardin <vjardin@free.fr> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-08-03hwmon: (pmbus/core) Avoid race condition during probeGuenter Roeck
pmbus_write_smbalert_mask() is not guarded, which can cause race conditions with concurrent sysfs attribute accesses. Similar, PMBus accesses in pmbus_init_debugfs() are not guarded, also resulting in potential race conditions. Add guards to both functions to prevent the races. Reported-by: Sashiko <sashiko-bot@kernel.org> Fixes: 221819ca4c36e ("hwmon: (pmbus/core) Add interrupt support") Fixes: 1e069dfd96dfe ("hwmon: (pmbus) Add debugfs for status registers") Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-08-03perf arm-spe: Reject zero nr_cpu in metadata to prevent division by zeroArnaldo Carvalho de Melo
arm_spe__alloc_metadata() reads nr_cpu from the auxtrace_info priv array without validation. When a crafted perf.data provides nr_cpu=0, the per_cpu_sz calculation divides by zero: per_cpu_sz = (metadata_size - (hdr_sz * sizeof(u64))) / (*nr_cpu); Reject nr_cpu <= 0 early, before the division. The caller already treats NULL return with metadata_ver != 1 as a parse failure. Fixes: 7842a4b6ff698 ("perf arm-spe: Support metadata version 2") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Reviewed-by: James Clark <james.clark@linaro.org> Reviewed-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2026-08-03perf intel-bts: Fix off-by-one in auxtrace_info minimum size checkArnaldo Carvalho de Melo
Same pattern as the Intel PT fix: min_sz is set to sizeof(u64) * INTEL_BTS_SNAPSHOT_MODE, but the code accesses auxtrace_info->priv[INTEL_BTS_SNAPSHOT_MODE], which requires at least INTEL_BTS_SNAPSHOT_MODE + 1 elements. Use (INTEL_BTS_SNAPSHOT_MODE + 1) to ensure the highest accessed index is within bounds. Fixes: d0170af7004dce9c ("perf tools: Add Intel BTS support") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Reviewed-by: James Clark <james.clark@linaro.org> Reviewed-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2026-08-03perf intel-pt: Fix off-by-one in auxtrace_info minimum size checkArnaldo Carvalho de Melo
min_sz is set to sizeof(u64) * INTEL_PT_PER_CPU_MMAPS, but the code accesses auxtrace_info->priv[INTEL_PT_PER_CPU_MMAPS], which requires at least INTEL_PT_PER_CPU_MMAPS + 1 elements. A file with exactly min_sz bytes of priv data passes the size check but the access reads one u64 past the validated region. Use (INTEL_PT_PER_CPU_MMAPS + 1) to ensure the highest accessed index is within bounds. Fixes: 90e457f7be087005 ("perf tools: Add Intel PT support") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Reviewed-by: James Clark <james.clark@linaro.org> Reviewed-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2026-08-03perf auxtrace: Fix queue grow overflow and old array leakArnaldo Carvalho de Melo
auxtrace_queues__grow() has two bugs: 1. When idx is UINT_MAX, the caller passes new_nr_queues = idx + 1 = 0. The function skips growing (since any nr_queues >= 0), returns success, and the caller accesses queue_array[UINT_MAX] — an OOB heap write. Fix by rejecting new_nr_queues == 0 up front. 2. The function allocates a new queue_array via calloc and copies elements from the old array, but never frees the old array. Fix by saving the old pointer and freeing it after the copy. Fixes: e502789302a6ece9 ("perf auxtrace: Add helpers for queuing AUX area tracing data") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Reviewed-by: James Clark <james.clark@linaro.org> Reviewed-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2026-08-03perf thread-stack: Fix heap buffer overflow on branch stack wrap copyArnaldo Carvalho de Melo
thread_stack__br_sample() copies the wrap-around portion of the branch stack ring buffer with: nr = min(ts->br_stack_pos, sz); memcpy(be, &src->entries[0], bsz * ts->br_stack_pos); 'nr' is correctly bounded to min(br_stack_pos, sz) but the memcpy uses the unbounded ts->br_stack_pos directly. When br_stack_pos exceeds the remaining destination space 'sz', this writes past the destination buffer. Use 'nr' (the bounded value) in the memcpy size, matching the pattern of the first memcpy in the same function. Fixes: 86d67180b920 ("perf thread-stack: Add branch stack support") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Reviewed-by: James Clark <james.clark@linaro.org> Reviewed-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2026-08-03HID: hid-msi: Add Rumble Intensity AttributesDerek J. Clark
Adds intensity adjustment for the left and right rumble motors. Claude was used during the reverse-engineering data gathering for this feature done by Zhouwang Huang. As the code had already been affected, I used Claude to create the initial framing for the feature, then did manual cleanup of the _show and _store functions afterwards to fix bugs and keep the coding style consistent. Claude was also used as an initial reviewer of this patch. Assisted-by: Claude:claude-sonnet-4-6 Co-developed-by: Zhouwang Huang <honjow311@gmail.com> Signed-off-by: Zhouwang Huang <honjow311@gmail.com> Link: https://patch.msgid.link/20260529072111.7565-5-derekjohn.clark@gmail.com Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: hid-msi: Add RGB control interfaceDerek J. Clark
Adds RGB control interface for MSI Claw devices. The MSI Claw uses a fairly unique RGB interface. It has 9 total zones (4 per joystick ring and 1 for the ABXY buttons), and supports up to 8 sequential frames of RGB zone data. Each frame is written to a specific area of MCU memory by the profile command, the value of which changes based on the firmware of the device. Unlike other devices (such as the Legion Go or the OneXPlayer devices), there are no hard coded effects built into the MCU. Instead, the basic effects are provided as a series of frame data. I have mirrored the effects available in Windows in this driver, while keeping the effect names consistent with the Lenovo drivers for the effects that are similar. Initial reverse-engineering and implementation of this feature was done by Zhouwang Huang. I refactored the overall format to conform to kernel driver best practices and style guides. Claude was used as an initial reviewer of this patch. Assisted-by: Claude:claude-sonnet-4-6 Co-developed-by: Zhouwang Huang <honjow311@gmail.com> Signed-off-by: Zhouwang Huang <honjow311@gmail.com> Link: https://patch.msgid.link/20260529072111.7565-4-derekjohn.clark@gmail.com Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: hid-msi: Add M-key mapping attributesDerek J. Clark
Adds attributes that allow for remapping the M-keys with up to 5 values when in macro mode. There are 2 mappable buttons on the rear of the device, M1 on the right and M2 on the left. When mapped, the events will fire from one of three event devices: gamepad buttons will fire from the device handled by xpad, while keyboard and mouse events will fire from respectively typed evdevs provided by the input core. Names of each mapping have been kept as close to the event that will fire from the evdev as possible, with context added to the ABS_ events on the direction of the movement. Initial reverse-engineering and implementation of this feature was done by Zhouwang Huang. I refactored the overall format to conform to kernel driver best practices and style guides. Claude was used as an initial reviewer of this patch. Assisted-by: Claude:claude-sonnet-4-6 Co-developed-by: Zhouwang Huang <honjow311@gmail.com> Signed-off-by: Zhouwang Huang <honjow311@gmail.com> Link: https://patch.msgid.link/20260529072111.7565-3-derekjohn.clark@gmail.com Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: hid-msi: Add MSI Claw configuration driverDerek J. Clark
Adds configuration HID driver for the MSI Claw series of handheld PC's. In this initial patch add the initial driver outline and attributes for changing the gamepad mode, M-key behavior, and add a WO reset function. Sending the SWITCH_MODE and RESET commands causes a USB disconnect in the device. The completion will therefore never get hit and would trigger an -EIO. To avoid showing the user an error for every write to these attrs a bypass for the completion handling is introduced when timeout == 0. The initial version of this patch was written by Denis Benato, which contained the initial reverse-engineering and implementation for the gamepad mode switching. This work was later expanded by Zhouwang Huang to include more gamepad modes. Finally, I refactored the drivers data in/out flow and overall format to conform to kernel driver best practices and style guides. Claude was used as an initial reviewer of this patch. Assisted-by: Claude:claude-sonnet-4-6 Co-developed-by: Denis Benato <denis.benato@linux.dev> Signed-off-by: Denis Benato <denis.benato@linux.dev> Co-developed-by: Zhouwang Huang <honjow311@gmail.com> Signed-off-by: Zhouwang Huang <honjow311@gmail.com> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: Intel-thc-hid: Remove redundant dev_err()Pan Chuang
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in devm_request_*_irq()"), devm_request_threaded_irq() automatically logs detailed error messages on failure. Remove the now-redundant driver-specific dev_err() calls. Signed-off-by: Pan Chuang <panchuang@vivo.com> Reviewed-by: Even Xu <even.xu@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: intel-ish-hid: ipc: Remove redundant dev_err()Pan Chuang
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in devm_request_*_irq()"), devm_request_irq() automatically logs detailed error messages on failure. Remove the now-redundant driver-specific dev_err() calls. Signed-off-by: Pan Chuang <panchuang@vivo.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: hid-goodix: Remove redundant dev_err()Pan Chuang
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in devm_request_*_irq()"), devm_request_threaded_irq() automatically logs detailed error messages on failure. Remove the now-redundant driver-specific dev_err() calls. Signed-off-by: Pan Chuang <panchuang@vivo.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: amd_sfh: Remove redundant dev_err()Pan Chuang
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in devm_request_*_irq()"), devm_request_irq() automatically logs detailed error messages on failure. Remove the now-redundant driver-specific dev_err() calls. Signed-off-by: Pan Chuang <panchuang@vivo.com> Acked-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: hyperx: add driver for the HyperX QuadCast 2 mute buttonBenjamin Blume
The tap-to-mute button of the HyperX QuadCast 2 (03f0:07b4) is handled entirely in the device firmware. The firmware gates the audio internally but never sends the Telephony "Phone Mute" usage (0x2f) that its own report descriptor advertises, and it does not touch the UAC feature unit either. Consequently neither an evdev key event nor an ALSA mixer change is ever generated, and userspace has no way to learn that the microphone was muted: desktops keep showing the microphone as live, and conferencing applications keep displaying an unmuted microphone while transmitting silence. The mute state is reported through a vendor-defined collection instead: 06 c0 ff Usage Page (Vendor-Defined 0xFFC0) a1 01 Collection (Application) 06 c1 ff Usage Page (Vendor-Defined 0xFFC1) 85 77 Report ID (0x77) 09 f0 Usage (0xF0) 75 08 95 3f Report Size (8), Report Count (63) 81 02 Input (Data,Var,Abs) Pressing the button emits a 64-byte report on that collection: 77 06 00 00 ... microphone unmuted 77 06 01 00 ... microphone muted where byte 1 identifies the mute event and byte 2 carries the resulting state. As the payload is an opaque vendor blob carrying no HID usages, hid-input cannot map it and a hwdb entry cannot express it either. Add a driver that decodes the report and emits KEY_MICMUTE, which makes the button behave like any other microphone mute key. Note that the device reports the resulting absolute state, whereas KEY_MICMUTE is a momentary key that userspace acts on as a toggle, so the driver emits one keypress per state change. Tested on a HyperX QuadCast 2 (03f0:07b4). Signed-off-by: Benjamin Blume <benjaminblume@posteo.de> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: steelseries: Add support for Arctis Nova 5X and Nova 7 familiesSriman Achanta
The Arctis Nova 5X, Nova 7 Gen2, and Nova 7 2026 refresh headsets answer status polls, but also send unsolicited battery and connection updates on a second HID interface (interface 5). Use that interface through async_interface so the driver does not have to poll. Add request and parse helpers for the Nova status format (0xb0/0xb7/0xb9/0xbb opcodes). The original (pre-Gen2) Arctis Nova 7 family answers the same status opcodes on the same interfaces, but reports battery capacity as a discrete 0-4 level instead of a raw percentage. Add a second parse function that maps that level through steelseries_map_capacity(), and a separate device_info so the two capacity encodings cannot get mixed up. Add the fourteen USB product IDs that share these protocols: 0x2253 Arctis Nova 5X 0x2202 Arctis Nova 7 0x2206 Arctis Nova 7X 0x22a4 Arctis Nova 7X (alternate PID) 0x223a Arctis Nova 7 Diablo 0x227a Arctis Nova 7 World of Warcraft Edition 0x22a1 Arctis Nova 7 2026 0x22a7 Arctis Nova 7P 2026 0x22a5 Arctis Nova 7X 2026 0x22a9 Arctis Nova 7 Diablo 2026 0x227e Arctis Nova 7 Gen 2 0x2258 Arctis Nova 7X Gen 2 0x229e Arctis Nova 7X Gen 2 (alternate PID) 0x22ad Arctis Nova 7X Gen 2 (alternate PID) Signed-off-by: Sriman Achanta <srimanachanta@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: steelseries: Add async status interface supportSriman Achanta
Some headsets expose a second HID interface that sends battery and connection updates on its own. Watching that interface lets the driver stop polling the sync interface. Add a steelseries_device_info::async_interface field and the code to handle it: - The driver binds both the sync and async interfaces. The async interface shares the steelseries_device created by the sync interface. It finds the sibling with usb_ifnum_to_if(), and before trusting its intfdata it rejects non-HID siblings by descriptor class and holds the sibling's device lock across the lookup, so a crafted device cannot cause a type-confused read and a concurrent unbind cannot free the hid_device from under it. It then takes a reference and returns -EPROBE_DEFER until the sync interface has probed. If the sync interface never binds, the async interface defers forever, which is fine here. - raw_event() now holds sd->lock and re-checks sd->removed so events on either interface are serialised against removal. - status_work runs once for async devices instead of rearming. A single status request is sent when the headset connects to get the initial battery level. No device sets async_interface yet. This is the infrastructure for the next commit. Signed-off-by: Sriman Achanta <srimanachanta@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: steelseries: Manage battery lifetime with refcountingSriman Achanta
The next change shares one steelseries_device between two HID interfaces, so the state can outlive either interface. Stop using devm for it. Reference count the struct with a kref and free it from steelseries_device_release(). Register and unregister the power supply explicitly, and clear sd->battery under sd->lock in remove() so it is not touched after it is unregistered. Drop the global atomic battery counter and name the power supply after the device (hdev->uniq, or dev_name() when empty), as hid-input and the other HID battery drivers do. No functional change for the current single-interface devices. Signed-off-by: Sriman Achanta <srimanachanta@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: steelseries: Correct Arctis 9 battery calibration rangeSriman Achanta
Map the Arctis 9 raw battery value over 0x64 (empty) to 0x9a (full) instead of 0x68 to 0x9d. These values match the HeadsetControl project [1] and fit the calibration points from an independent reverse engineering of the battery tray (about 25% at raw 112, 50% at raw 125) [2]. I do not have this headset. The values come from those references and were not measured directly. [1] https://github.com/Sapd/HeadsetControl/blob/master/lib/devices/steelseries_arctis_9.hpp [2] https://magnier.io/reverse-engineering-arctis-9-battery-tray/ Signed-off-by: Sriman Achanta <srimanachanta@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: steelseries: Report POWER_SUPPLY_STATUS_FULL when fullSriman Achanta
Report POWER_SUPPLY_STATUS_FULL when the headset is connected, charging, and at 100% capacity. It reported CHARGING in that case before. The charging flag doubles as a power-present signal: the headset keeps reporting charging while it sits docked at 100%, and clears the flag as soon as it runs on battery. Gating FULL on the charging flag therefore avoids reporting FULL for an unplugged headset that merely happens to be at 100%, which would otherwise hide the discharge state from userspace. Signed-off-by: Sriman Achanta <srimanachanta@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: steelseries: Refactor Arctis driver to use device_info frameworkSriman Achanta
Replace the per-product if/else quirk bitmap with a steelseries_device_info struct. Each model provides its capabilities, sync_interface, and request_status/parse_status callbacks. Report sending is folded into steelseries_send_report() and the feature and output wrappers, and the battery identifiers lose their per-model names. This is mostly a refactor, but it changes two things: - Battery status is polled from a periodic delayed work (status_work) instead of being requested from raw_event(). The interval stays at 3s. - Arctis 1 no longer clamps the reported capacity to 100% while disconnected. The connection state already controls how this is shown to userspace. ARCTIS_1_X and ARCTIS_9 keep working. No new devices are added. Signed-off-by: Sriman Achanta <srimanachanta@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: steelseries: Split Arctis headset driver into separate moduleSriman Achanta
Move all Arctis headset code (battery monitoring, wireless status, power supply registration, raw event handling) from hid-steelseries.c into the new hid-steelseries-arctis.c driver module. hid-steelseries.c keeps the SRWS1 racing wheel and the MSI RGB LED devices, while hid-steelseries-arctis.c handles the Arctis 1 (Xbox) and Arctis 9 wireless headsets with their own device table, probe, remove, and raw_event implementations. Signed-off-by: Sriman Achanta <srimanachanta@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: steelseries: Fix ARCTIS_1_X device mislabelingSriman Achanta
The SteelSeries Arctis 1 Wireless for Xbox (0x12b6) was labelled as the plain Arctis 1 Wireless. Rename USB_DEVICE_ID_STEELSERIES_ARCTIS_1 to USB_DEVICE_ID_STEELSERIES_ARCTIS_1_X, along with the matching quirk flag and device table entry. The device ID value is unchanged. Signed-off-by: Sriman Achanta <srimanachanta@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03docs: pt_BR: translate the management-style.rst to Brazilian PortugueseAmanda Corrêa
Key changes include: - Translated management-style.rst into and adapted idiomatic expressions and humor to sound natural in Brazilian Portuguese while maintaining the original tone. Signed-off-by: Amanda Corrêa <amandacorreasilvax@gmail.com> Acked-by: Daniel Pereira <danielmaraboo@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260704202831.112653-1-amandacorreasilvax@gmail.com>
2026-08-03HID: magicmouse: re-enable multitouch after reset-resumeChristopher Kodama
When the Apple Magic Trackpad 2 (USB) is reset across a power transition (e.g. resume from hibernation) it drops out of multitouch mode: it keeps sending report ID 0x02 on its HID_TYPE_USBMOUSE interface, but the packet shrinks from 21 to 8 bytes and the trackpad2 handler drops it (size < 12). Clicks still work but pointer motion is lost until the device is re-plugged or the driver reloaded. Re-enable multitouch from .reset_resume via the workqueue. Only .reset_resume is needed; suspend-to-idle keeps the device powered and retains multitouch. Fixes: 87a2f10395c8 ("HID: magicmouse: Apple Magic Trackpad 2 USB-C driver support") Cc: stable@vger.kernel.org Assisted-by: Claude-Code:claude-opus-4-8 Signed-off-by: Christopher Kodama <ckhordiasma@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03Merge tag 'fsverity-for-linus' of git://git.kernel.org/pub/scm/fs/fsverity/linuxLinus Torvalds
Pull fsverity fix from Eric Biggers: "Fix a regression where truncating a file with fsverity enabled started being allowed on kernels without fsverity support" * tag 'fsverity-for-linus' of git://git.kernel.org/pub/scm/fs/fsverity/linux: fs,fsverity: remove check for fsverity being enabled in setattr_prepare()
2026-08-03Merge tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/linuxLinus Torvalds
Pull fscrypt fix from Eric Biggers: "Fix a bug where FS_IOC_SET_ENCRYPTION_POLICY checked the original uid rather than the idmapped one" * tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/linux: fscrypt: use the mount idmap for the owner check in fscrypt_ioctl_set_policy()
2026-08-03HID: lg4ff: validate report length before fixed offsetsJiancheng Huang
lg4ff_raw_event() rewrites fixed report offsets when combined pedals are enabled. It currently assumes that each product report contains every source and destination byte used by the rewrite. Return without rewriting a short report before each product-specific access. Apply the same bound to the computed offset path. Fixes: c832f86effbc ("HID: hid-logitech: Add combined pedal support Logitech wheels") Signed-off-by: Jiancheng Huang <jchuang@seu.edu.cn> Assisted-by: Codex:gpt-5.6-luna Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: corsair: cancel worker before unregistering LED to fix use-after-freeChen Changcheng
The cleanup functions k90_cleanup_backlight() and k90_cleanup_macro_functions() call led_classdev_unregister() before cancel_work_sync(): led_classdev_unregister() <-- may free led->cdev.dev cancel_work_sync() <-- wait for worker If the LED worker (k90_backlight_work / k90_record_led_work) is already running on another CPU, the following race can occur: CPU 1 (worker) CPU 2 (remove) --------------------- -------------------- if (led->removed) -> false (passed the guard, about to read led->cdev.dev) * preempted removed = true led_classdev_unregister() -> led->cdev.dev freed cancel_work_sync() -> waits for worker * resumes dev = led->cdev.dev->parent <-- UAF! Fix by swapping the order so that the worker is cancelled first: cancel_work_sync() <-- wait for worker first led_classdev_unregister() <-- then safe to unregister The removed flag is set before cancel_work_sync() so that if led_classdev_unregister() internally triggers another brightness update (which re-schedules the work), the worker will see the flag and return immediately. Signed-off-by: Chen Changcheng <chenchangcheng@kylinos.cn> Reported-by: sashiko-bot <sashiko-bot@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: corsair: fix use-after-free by reordering remove sequenceChen Changcheng
The corsair_remove() function currently frees the k90 driver data before calling hid_hw_stop(). Since hid_hw_stop() stops HID I/O, the event callback corsair_event() can still be invoked between the kfree() and hid_hw_stop(), and will dereference the freed drvdata->k90 pointer to write record_led.brightness. Reorder the remove sequence so that hid_hw_stop() is called first. Once hid_hw_stop() completes, the HID device is disconnected and no URBs are active, so corsair_event() cannot fire anymore. The driver data is freed only afterwards. Additionally, set drvdata->k90 to NULL after kfree() as a defensive measure, matching the existing pattern in the error path of k90_init_macro_functions(). Signed-off-by: Chen Changcheng <chenchangcheng@kylinos.cn> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03vdpa/mlx5: Fix buffer length in create_direct_keys()Christian Borntraeger
We have seen in our CI the following KASAN message: BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core] Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764 [...] [<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core] [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core] [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa] [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa] [...] The buggy address is located 4128 bytes inside of allocated 4384-byte region [0000000176794000, 0000000176795120) So in essence we read 16 bytes beyond 4384-byte allocation. create_direct_keys calculates the pointer and length for in and out buffers. The size calculation for in includes the entire structure size (out + in + mtt[]) but the pointer passed to cmd_exec points only to the 'in' field, skipping the 'out' field. This causes mlx5_copy_to_msg() to read beyond the allocated buffer by sizeof(out) bytes when copying command data. Properly calculate the input size to match the pointer and allocation size. Fixes: 0071b138d44a ("vdpa/mlx5: Create direct MKEYs in parallel") Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Tested-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260706141537.3510294-1-borntraeger@linux.ibm.com>
2026-08-03vhost/vdpa: reject overflowing PA map page counts on 32-bitYousef Alhouseen
vhost_vdpa_pa_map() adds the IOVA page offset to the user-controlled map size before computing the number of pages to pin. On 32-bit systems, where unsigned long is narrower than u64, that addition can overflow and the code can pin and map fewer pages than the requested IOTLB range. Reject sizes that overflow the unsigned long page-count calculation. Fixes: 22af48cf91aa ("vdpa: factor out vhost_vdpa_pa_map() and vhost_vdpa_pa_unmap()") Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <CAMuQ4bX-iDvcUOPPY+NLz95tkRJYwWqvzAr=U48uNaub_HZLGw@mail.gmail.com>
2026-08-03vhost_iotlb: bound map allocation in add_rangeLinfeng Sun 
vhost_iotlb_add_range_ctx() only retires an old entry when the table has a non-zero limit, has exactly reached that limit and has VHOST_IOTLB_FLAG_RETIRE set. Non-retiring tables can keep allocating entries after reaching their configured limit. Existing vhost devices allocate their IOTLB with max_iotlb_entries from vhost.c, which defaults to 2048 and is tunable by module parameter. Use the caller-provided limit at the allocation point instead of adding a separate default in the common IOTLB helper, and reject non-positive values in vhost paths that can report an error. Other vhost IOTLB users should not create zero-limit tables when entries can be populated from userspace or guest-controlled requests. Add caller-side max_iotlb_entries parameters for mlx5 vDPA, VDUSE and vhost-vDPA. Reject non-positive VDUSE and vhost-vDPA values, and require at least two entries for vdpa_sim and mlx5 vDPA paths that install full-range mappings, since those mappings are split into two IOTLB entries. Handle full-range mappings in the common helper by checking that the IOTLB can hold both split entries before inserting the first half. This avoids returning an error after leaving a half mapping behind. When the table is full, keep the existing retire behavior for retiring tables and return -ENOSPC for non-retiring tables. Reuse the retired map node instead of freeing it and allocating a replacement, so a stream of IOTLB updates cannot keep forcing GFP_ATOMIC allocations after the table has reached its limit. If a zero-limit IOTLB still reaches the common helper, treat it as a configuration error and return -EINVAL. I found this bug myself, though the patch was written with AI assistance. Fixes: 0bbe30668d89 ("vhost: factor out IOTLB") Assisted-by: OpenAI-Codex:GPT-5 Signed-off-by: Linfeng Sun <linfeng.sun.dev@gamil.com> Message-ID: <AMYAtgAiKmgYcSQT5ukl-4qq.3.1781960405943.Hmail.241270009@hdu.edu.cn> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2026-08-03HID: quirks: add ALWAYS_POLL quirk for AULA Mini 60 HE Pro DongleYuxiang Lin
The AULA Mini 60 HE Pro wireless keyboard dongle (USB ID 0c45:fefe) becomes unresponsive after roughly one minute of idle. No error appears in dmesg; the only recovery is physically replugging the dongle. This has been reproduced across kernels 6.8, 6.14 and 7.1.3. Testing shows HID_QUIRK_ALWAYS_POLL alone resolves the issue, verified via usbhid.quirks=0x0c45:0xfefe:0x400. Signed-off-by: Yuxiang Lin <mclyxfdw@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: i2c-hid: goodix: Disable VDD on VDDIO enable failureChao Huang
If enabling VDDIO fails after VDD has been enabled, the power-up path returns without disabling VDD. This leaves the regulator enabled and its enable count unbalanced. Disable VDD before returning the VDDIO error. Fixes: eb16f59e8e58 ("HID: i2c-hid: goodix: Add mainboard-vddio-supply") Signed-off-by: Chao Huang <huangchao@kylinos.cn> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: asus: support the Zenbook A16 (UX3607OA) keyboardKonrad Dybcio
The ASUS Zenbook A16 (UX3607OA), a Qualcomm Snapdragon X2 Elite Extreme (Glymur)-based laptop, carries its main keyboard on an I2C-HID device with the ID 0B05:4B42. Its Fn/media hotkeys are emitted as vendor-page (HID_UP_ASUSVENDOR) usages on report 0x5A. Match the device in hid-asus with the standard I2C keyboard quirks and add the three usage mappings observed on the hardware: 0x85 -> KEY_CAMERA (Fn+F11, camera toggle) 0x86 -> KEY_PROG1 (Fn+F12, MyASUS key) 0x5f -> KEY_PROG2 (extra programmable key) The camera-toggle key reports its usage (0x85) together with a companion state byte in the same array report ("5a 85 01" / "5a 85 10"). The 0x10 companion aliases the brightness-down vendor usage and spuriously dims the panel, so add QUIRK_FILTER_CAMERA_COMPANION to zero the companion slots for this device before input mapping. The quirk is device-gated so no other ASUS model is affected. Assisted-by: Claude Code:claude-opus-4-8 Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: quirks: Add ALWAYS_POLL quirk for Beitong BTP-KP20D dongleAaron Ma
The BTP-KP20D dongle in Direct/HID mode (20dd:5159) re-enumerates every few seconds because usbhid never submits its interrupt-IN URB: no HID driver binds to the vendor-specific report descriptor, so the device is never opened, and the firmware treats the idle endpoint as a lost link. Add HID_QUIRK_ALWAYS_POLL to keep the interrupt-IN URB submitted from probe time. Signed-off-by: Aaron Ma <mapengyu@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: hyperv: add KUnit coverage for device info boundsMichael Bommarito
Add KUnit coverage for Hyper-V synthetic HID initial device-info parsing. The tests cover zero bLength, a valid descriptor plus report descriptor, and a malformed report descriptor length that exceeds the received message. The same-translation-unit test uses a KUnit-only ACK bypass so parser coverage does not require a live VMBus channel. Assisted-by: Codex:gpt-5-5-xhigh Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: hyperv: validate initial device info boundsMichael Bommarito
The Hyper-V synthetic HID host supplies SYNTH_HID_INITIAL_DEVICE_INFO messages that contain a HID descriptor followed by the report descriptor bytes. mousevsc_on_receive_device_info() trusts bLength and wDescriptorLength without checking that the received packet contains both byte ranges. A malformed host or backend message can therefore make the guest read past the received VMBus packet while copying the report descriptor. Pass the received initial-device-info size into the parser and reject descriptor lengths that exceed the packet. Impact: A malicious Hyper-V host or backend can crash a guest by sending a short initial device-info message with an oversized HID report descriptor length. Fixes: b95f5bcb811e ("HID: Move the hid-hyperv driver out of staging") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5-5-xhigh Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: sony: add missing __packed to struct with static_assert()Rosalie Wanders
Fixes: 4b9c410e7d6d ("HID: sony: fix style issues") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202607091026.R9Pxd3PG-lkp@intel.com/ Signed-off-by: Rosalie Wanders <rosalie@mailbox.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: appletb-kdb: Replace system_wq with system_dfl_wqMarco Crivellari
Currently the code enqueue work items using mod_delayed_work(), using system_wq, the old per-CPU Workqueue. The function end up calling __queue_delayed_work(), which set a global timer that could fire anywhere, enqueuing the work where the timer fired. Unbound works could benefit from scheduler task placement, to optimize performance and power consumption. Since the workqueue work doesn't rely on per-cpu variables, there is no obvious reason that justify the use of a per-cpu workqueue. So change the workqueue with the new unbound version, system_dfl_wq. Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03HID: hid-oxp: Replace system_wq with system_dfl_wqMarco Crivellari
The function end up calling __queue_delayed_work(), which set a global timer that could fire anywhere, enqueuing the work where the timer fired. Unbound works could benefit from scheduler task placement, to optimize performance and power consumption. Since the workqueue work doesn't rely on per-cpu variables, there is no obvious reason that justify the use of a per-cpu workqueue. So change the workqueue with the new unbound version, system_dfl_wq. Cc: Derek J. Clark <derekjohn.clark@gmail.com> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-03ASoC: sdw_utils: Use auto-cleanup for put_device()Takashi Iwai
A temporary refcount management of a struct device can be done gracefully with __clean(put_device) for avoiding potential leaks. No functional change but just a code cleanup. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260803135648.917760-1-tiwai@suse.de Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-03HID: magicmouse: fix battery reporting for Bluetooth Magic Trackpad USB-CAndrei Fed
The Apple Magic Trackpad 2 (USB-C) reports a wildly wrong battery capacity over Bluetooth, for example a constant 4% for a pack that is actually at 74%. The device's battery input report (0x90) is laid out as [report-id][status][charge]. hid-input's synchronous capacity query, hidinput_query_battery_capacity(), assumes the common [report-id][capacity] layout and returns buf[1], which for this device is the status byte rather than the charge (buf[2]). magicmouse_fetch_battery(), which requests the battery report through hid_hw_request() so the reply is decoded via the report descriptor at the correct field offset, is gated to the USB models and never runs over Bluetooth. The device does not push battery reports on its own either, except a single one at connect time, which is delivered while probe holds driver_input_lock and is silently dropped. All userspace reads therefore go through the misparsing query, and the device is stuck reporting its status byte as the capacity. Enabling the fetch for Bluetooth is not sufficient on its own: user space reacts to the power_supply registration immediately, so a query is typically already in flight when the fetch reply is parsed. hidinput_get_battery_property() stores the query result and marks the battery as queried without rechecking whether a report arrived while it was waiting, clobbering the just-reported correct value with the misparsed one. Fix this by adding HID_BATTERY_QUIRK_AVOID_QUERY for the Bluetooth Magic Trackpad USB-C so the misparsing query path is never used, and by fetching the battery at the end of probe for this device. hidp has no asynchronous request() callback, so the fetch is serviced synchronously via __hid_request() while probe still holds driver_input_lock; call hid_device_io_start() first so the reply is processed instead of being discarded. Tested with a Magic Trackpad USB-C (004c:0324) over Bluetooth on 6.18.37: the reported capacity now matches the device (verified against a raw GET_REPORT of report 0x90) and updates on reconnect. Fixes: 87a2f10395c8 ("HID: magicmouse: Apple Magic Trackpad 2 USB-C driver support") Cc: stable@vger.kernel.org Signed-off-by: Andrei Fed <andfed.net@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>