kernel/linux.git, branch v5.15.218

Linux 5.15.218

2026-08-27T12:28:23+00:00

Link: https://lore.kernel.org/r/20260825132541.568214149@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Signed-off-by: Greg Kroah-Hartman

Revert "ALSA: aoa: Use guard() for mutex locks"

2026-08-27T12:28:23+00:00

This reverts commit d956208576ad0dbed1d6145a797144c03e31e9eb. Commit d956208576ad0 ("ALSA: aoa: Use guard() for mutex locks", upstream commit 1cb6ecbb37200) was picked up for 5.15.y only as a Stable-dep-of for 5ed060d54915 ("ALSA: aoa: i2sbus: clear stale prepared state"). 5.15.y still builds with '-std=gnu89' and '-Wdeclaration-after-statement', so the guard() and scoped_guard() helpers cannot be used here at all: the CLASS() declaration that guard() expands to is a declaration in the middle of a block, and scoped_guard() declares its variable in a for() init clause. With CONFIG_WERROR=y (allmodconfig) this breaks the powerpc build: sound/aoa/core/gpio-pmf.c: In function 'pmf_set_notify': ./include/linux/cleanup.h:86:9: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] sound/aoa/codecs/tas.c: In function 'tas_switch_clock': ./include/linux/cleanup.h:112:9: error: 'for' loop initial declarations are only allowed in C99 or C11 mode Revert the cleanup so that sound/aoa goes back to explicit mutex_lock()/mutex_unlock() pairs. As it was a pure refactoring with no behaviour change, nothing is lost. The two fixes that were queued on top of it are kept and re-adapted to the explicit locking in sound/aoa/soundbus/i2sbus/pcm.c: - 2c38191380740 ("ALSA: aoa: i2sbus: clear stale prepared state"): i2sbus_pcm_clear_active() now takes and drops i2sdev->lock explicitly, and i2sbus_pcm_prepare() sets pi->active only on the success paths, which are now reached via 'goto out_unlock' with result == 0. - d17c282163b70 ("ALSA: aoa: Skip devices with no codecs in i2sbus_resume()"): the list_first_entry() conversion in i2sbus_pcm_prepare() is kept. Signed-off-by: Sasha Levin

HID: hyperv: validate initial device info bounds

2026-08-27T12:28:23+00:00

commit 934b7778aa7b7c8f6bb073d2a73ba3674885bae0 upstream. 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 Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

HID: sensor: custom: Fix use-after-free in enable_sensor

2026-08-27T12:28:23+00:00

commit ad8fb82b04422f49530d2aa2753cc81d1c60102c upstream. enable_sensor_store() can call set_power_report_state(), which dereferences sensor_inst->power_state and sensor_inst->report_state. These pointers refer to entries in sensor_inst->fields. Create the field attributes before exposing the enable_sensor sysfs attribute, so enable_sensor cannot be accessed before the state it depends on has been initialized. On remove, delete enable_sensor before freeing the field attributes, so a concurrent sysfs write cannot dereference freed memory through power_state or report_state. Reported-by: Sashiko AI Review Link: https://sashiko.dev/#/patchset/20260623021950.1736413-1-haoxiang_li2024@163.com?part=1 Fixes: 4a7de0519df5 ("HID: sensor: Custom and Generic sensor support") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

HID: core: fix number/pointer type confusion on long items

2026-08-27T12:28:23+00:00

commit 28abce951343fcec26e397610868efa4e1395c3f upstream. When fetch_item() is called by hid_scan_report() on an item with HID_ITEM_TAG_LONG, it stores a pointer to the item data in item->data.longdata instead of storing a value directly in item->data.{u8/u16/u32}. When item_udata() or item_sdata() encounters such an item, it incorrectly assumes that the item is in short format, and therefore returns the lower part of a kernel pointer reinterpreted as a number. When a HID device is connected whose descriptor contains a HID_GLOBAL_ITEM_TAG_REPORT_SIZE encoded in long format with size=4, this causes the lower half of a kernel pointer to be printed into dmesg as a number, like this: hid (null): invalid report_size 107953555 To fix it, let item_udata() and item_sdata() verify that the item is in short format. Note that this bug only affects hid_scan_report(), while the main parsing pass hid_parse_collections() will always bail out when encountering a long item. Sidenote: There are currently no users of data.longdata; maybe we should just remove any parsing of long-format descriptors as a follow-up. Fixes: 3dc8fc083dbf ("HID: Use hid_parser for pre-scanning the report descriptors") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

can: isotp: fix timer drain order, wakeup handling and tx_gen ordering

2026-08-27T12:28:22+00:00

commit 050f010f920da17c1044a4f174766ad553e770b6 upstream. This patch is a follow-up to commit cf070fe33bfb ("can: isotp: serialize TX state transitions under so->rx_lock") which addresses following sashiko-bot findings: - isotp_sendmsg(): drain so->txfrtimer first so a stale callback can't re-arm echotimer after the claim - isotp_release(): wake so->wait after forcing ISOTP_SHUTDOWN so a sleeping sendmsg() claim isn't stranded - isotp_sendmsg(): have both wait_event_interruptible() calls in isotp_sendmsg() also wake on ISOTP_SHUTDOWN and do not return claim to IDLE to avoid corrupting a concurrent isotp_release() process. - isotp_sendmsg(): handle potential claim of a new transfer when the wait_event_interruptible() call returns in CAN_ISOTP_WAIT_TX_DONE mode. Don't touch timers and states of the new transfer if a new thread incremented so->tx_gen before getting the lock at err_event_drop. - isotp_sendmsg(): handle a stuck can_send() and omit timer and state changes if a new transfer was claimed. wait_tx_done() returns the error recorded in so->tx_result[], tagged with the caller's own generation. - isotp_tx_timeout(): on a claimed timeout, record the ECOMM error for the timed-out transfer's own generation in so->tx_result[]; sk->sk_err is raised unconditionally, same as every other error path here. - isotp_tx_gen_done()/isotp_tx_timeout(): always read tx.state (acquire) before tx_gen - the reverse order let a weakly ordered CPU pair a fresh tx.state with a stale tx_gen/tx_result slot. - isotp_sendmsg(): wait_tx_done: drain sk_err via sock_error() once we have read the result from so->tx_result[], so an already-reported error doesn't stay latched for a later poll()/SO_ERROR. Also align the remaining lock-free so->tx.state/rx.state/cfecho accesses and use skb->hash as unique loopback echo frame indicator. Fixes: cf070fe33bfb ("can: isotp: serialize TX state transitions under so->rx_lock") Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260724181525.43556-1-socketcan@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Oliver Hartkopp Signed-off-by: Greg Kroah-Hartman

can: use skb hash instead of private variable in headroom

2026-08-27T12:28:22+00:00

commit d4fb6514ff8ed6912a71294e6b66a5d59ee88007 upstream. The can_skb_priv::skbcnt variable is used to identify CAN skbs in the RX path analogue to the skb->hash. As the skb hash is not filled in CAN skbs move the private skbcnt value to skb->hash and set skb->sw_hash accordingly. The skb->hash is a value used for RPS to identify skbs. Use it as intended. Signed-off-by: Marc Kleine-Budde Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260201-can_skb_ext-v8-1-3635d790fe8b@hartkopp.net Signed-off-by: Paolo Abeni Signed-off-by: Oliver Hartkopp Signed-off-by: Greg Kroah-Hartman

mptcp: pm: fix data race in add_addr timer callback

2026-08-27T12:28:22+00:00

[ Upstream commit a7aad5b69d3bdaec20a3ed9284e184502450c0cd ] The timer callback reads entry->retrans_times outside pm.lock to decide whether to call mptcp_pm_subflow_established(). Since mptcp_pm_announced_del_timer() can concurrently set retrans_times = ADD_ADDR_RETRANS_MAX under pm.lock, a race condition exists. I discovered this issue while studying the code. AI tools helped me to verify the issue can potentially happen under race conditions. Use a local 'retransmit' flag set inside pm.lock to capture whether retransmission is still possible when the lock is taken. This allows to call mptcp_pm_subflow_established() accordingly, and not depending on the situation that can be different when checked outside the pm.lock. Fixes: 348d5c1dec60 ("mptcp: move to next addr when timeout") Cc: stable@vger.kernel.org Signed-off-by: Qing Luo Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-4-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski [ applied hunk to mptcp_pm_add_timer() in net/mptcp/pm_netlink.c instead of pm.c, dropping the absent adaptive-timeout shift line ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

mptcp: pm: ADD_ADDR rtx: free sk if last

2026-08-27T12:28:22+00:00

[ Upstream commit b7b9a461569734d33d3259d58d2507adfac107ed ] When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(), and released at the end. If at that moment, it was the last reference being held, the sk would not be freed. sock_put() should then be called instead of __sock_put(). But that's not enough: if it is the last reference, sock_put() will call sk_free(), which will end up calling sk_stop_timer_sync() on the same timer, and waiting indefinitely to finish. So it is needed to mark that the timer is done at the end of the timer handler when it has not been rescheduled, not to call sk_stop_timer_sync() on "itself". Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-5-fca8091060a4@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: a7aad5b69d3b ("mptcp: pm: fix data race in add_addr timer callback") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

mptcp: pm: ADD_ADDR rtx: always decrease sk refcount

2026-08-27T12:28:22+00:00

[ Upstream commit 9634cb35af17019baec21ca648516ce376fa10e6 ] When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(). It should then be released in all cases at the end. Some (unlikely) checks were returning directly instead of calling sock_put() to decrease the refcount. Jump to a new 'exit' label to call __sock_put() (which will become sock_put() in the next commit) to fix this potential leak. While at it, drop the '!msk' check which cannot happen because it is never reset, and explicitly mark the remaining one as "unlikely". Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-4-fca8091060a4@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: a7aad5b69d3b ("mptcp: pm: fix data race in add_addr timer callback") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman