Merge/sound upstream 20260528#5791
Open
bardliao wants to merge 820 commits into
Open
Conversation
If a kcontrol update comes to a control right at the same time when the PCM containing the control is started up then there is a small window when a race can happen: while the widget is set up the swidget->setup_mutex is taken in topology level and if the control update comes at this point, it will be stopped within sof_ipc4_set_get_kcontrol_data() with the mutex and it will be blocked until the swidget setup is done, which will clear the control's IPC message payload. To avoid such race, use local copy of the template IPC message instead of the template directly. This will ensure data integrity in case of concurrent updates during initialization. Link: thesofproject#5734 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/20260520141349.9625-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
When there is no more space to queue an incoming packet, the packet is silently dropped. This causes data loss without any notification to either peer, since there is no retransmission. Under normal circumstances, this should never happen. However, it could happen if the other peer doesn't respect the credit, or if the skb overhead, which we recently began to take into account with commit 059b7db ("vsock/virtio: fix potential unbounded skb queue"), is too high. Fix this by resetting the connection and setting the local socket error to ENOBUFS when virtio_transport_recv_enqueue() can no longer queue a packet, so both peers are explicitly notified of the failure rather than silently losing data. Fixes: ae6fcfb ("vsock/virtio: discard packets if credit is not respected") Cc: stable@vger.kernel.org Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Link: https://patch.msgid.link/20260518090656.134588-2-sgarzare@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
After commit 059b7db ("vsock/virtio: fix potential unbounded skb queue"), virtio_transport_inc_rx_pkt() subtracts per-skb overhead from buf_alloc when checking whether a new packet fits. This reduces the effective receive buffer below what the user configured via SO_VM_SOCKETS_BUFFER_SIZE, causing legitimate data packets to be silently dropped and applications that rely on the full buffer size to deadlock. Also, the reduced space is not communicated to the remote peer, so its credit calculation accounts more credit than the receiver will actually accept, causing data loss (there is no retransmission). With this approach we currently have failures in tools/testing/vsock/vsock_test.c. Test 18 sometimes fails, while test 22 always fails in this way: 18 - SOCK_STREAM MSG_ZEROCOPY...hash mismatch 22 - SOCK_STREAM virtio credit update + SO_RCVLOWAT...send failed: Resource temporarily unavailable Fix by allowing at most `buf_alloc * 2` as the total budget for payload plus skb overhead in virtio_transport_inc_rx_pkt(), similar to how SO_RCVBUF is doubled to reserve space for sk_buff metadata. This preserves the full buf_alloc for payload under normal operation, while still bounding the skb queue growth. With this patch, all tests in tools/testing/vsock/vsock_test.c are now passing again. Fixes: 059b7db ("vsock/virtio: fix potential unbounded skb queue") Cc: stable@vger.kernel.org Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Link: https://patch.msgid.link/20260518090656.134588-3-sgarzare@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
…ll-buf_alloc' Stefano Garzarella says: ==================== vsock/virtio: fix skb overhead accounting to preserve full buf_alloc Patch 1 resets the connection when we can no longer queue packets, this prevents silent data loss, and both peers are notified. Patch 2 increases the total budget to `buf_alloc * 2` for payload plus skb overhead similar to how SO_RCVBUF is doubled to reserve space for sk_buff metadata. This preserves the full buf_alloc for payload under normal operation, while still bounding the skb queue growth. In the future, we plan to improve how we handle the merging of packets to minimize overhead and avoid closing connections. v3: https://lore.kernel.org/netdev/20260513105417.56761-1-sgarzare@redhat.com/ v2: https://lore.kernel.org/netdev/20260512080737.36787-1-sgarzare@redhat.com/ v1: https://lore.kernel.org/netdev/20260508092330.69690-1-sgarzare@redhat.com/ ==================== Link: https://patch.msgid.link/20260518090656.134588-1-sgarzare@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
A remove callback that does nothing has the same semantic (apart from a
debug output) as no such callback at all as i2c_device_remove() just does:
if (driver->remove) {
dev_dbg(dev, "remove\n");
driver->remove(client);
}
Remove these useless callbacks.
While touching the driver structs, unify indention.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/3afd8230634dd68ac7c1885ee2b01da377349f89.1778692164.git.u.kleine-koenig@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
While being less compact, using named initializers allows to more easily see which members of the structs are assigned which value without having to lookup the declaration of the struct. And it's also more robust against changes to the struct definition. The mentioned robustness is relevant for a planned change to struct i2c_device_id that replaces .driver_data by an anonymous union. While touching all these arrays, unify indention and usage of commas. This patch doesn't modify the compiled arrays, only their representation in source form benefits. The former was confirmed with x86 and arm64 builds. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/ae2ff4898eb340bd8bcafb7b75443eb4a0ce3e76.1778692164.git.u.kleine-koenig@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> says: This series is a preparation for diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h index 23ff240..aebd3a5e90af 100644 --- a/include/linux/mod_devicetable.h +++ b/include/linux/mod_devicetable.h @@ -477,7 +477,11 @@ struct rpmsg_device_id { struct i2c_device_id { char name[I2C_NAME_SIZE]; - kernel_ulong_t driver_data; /* Data private to the driver */ + union { + /* Data private to the driver */ + kernel_ulong_t driver_data; + const void *driver_data_ptr; + }; }; /* pci_epf */ and this requires that .driver_data is assigned via a named initializer for static data. This requirement isn't a bad one because named initializers are also much better readable than list initializers. The union added to struct i2c_device_id enables further cleanups like: diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c index 8a082ff..b2aac7348d22 100644 --- a/drivers/iio/accel/kxcjk-1013.c +++ b/drivers/iio/accel/kxcjk-1013.c @@ -1429,7 +1429,7 @@ static int kxcjk1013_probe(struct i2c_client *client) if (id) { name = id->name; - data->info = (const struct kx_chipset_info *)(id->driver_data); + data->info = id->driver_data_ptr; } else { name = iio_get_acpi_device_name_and_data(&client->dev, &ddata); data->info = ddata; @@ -1630,11 +1630,11 @@ static const struct dev_pm_ops kxcjk1013_pm_ops = { }; static const struct i2c_device_id kxcjk1013_id[] = { - { .name = "kxcjk1013", .driver_data = (kernel_ulong_t)&kxcjk1013_info }, - { .name = "kxcj91008", .driver_data = (kernel_ulong_t)&kxcj91008_info }, - { .name = "kxtj21009", .driver_data = (kernel_ulong_t)&kxtj21009_info }, - { .name = "kxtf9", .driver_data = (kernel_ulong_t)&kxtf9_info }, - { .name = "kx023-1025", .driver_data = (kernel_ulong_t)&kx0231025_info }, + { .name = "kxcjk1013", .driver_data_ptr = &kxcjk1013_info }, + { .name = "kxcj91008", .driver_data_ptr = &kxcj91008_info }, + { .name = "kxtj21009", .driver_data_ptr = &kxtj21009_info }, + { .name = "kxtf9", .driver_data_ptr = &kxtf9_info }, + { .name = "kx023-1025", .driver_data_ptr = &kx0231025_info }, { } }; MODULE_DEVICE_TABLE(i2c, kxcjk1013_id); that are an improvement for readability (again!) and it keeps some properties of the pointers (here: being const) without having to pay attention for that. (I didn't find a good example in sound/soc, so an iio driver was used to demonstrate the gain.) My additional motivation for this effort is CHERI[1]. This is a hardware extension that uses 128 bit pointers but unsigned long is still 64 bit. So with CHERI you cannot store pointers in unsigned long variables. The first patch drops a few empty remove callbacks that I found while working on patch #2. The second converts all hwmon drivers to use named initializers. Link: https://patch.msgid.link/cover.1778692164.git.u.kleine-koenig@baylibre.com
When a buffer is freed either by LRU eviction or because it is unset, the lockref is marked as dead instantly, which prevents the buffer from being used after finding it in the buffer hash in xfs_buf_lookup and xfs_buf_find_insert. But the latter will then not add the new buffer to the hash because it already found an existing buffer. Fix this using in two places: Remove the buffer from the hash before marking the lockref dead so that that no buffer with a dead lockref can be found in the hash, but if we find one in xfs_buf_find_insert due to store reordering, handle this case correctly instead of returning an unhashed buffer. Fixes: 67fe430 ("xfs: don't keep a reference for buffers on the LRU") Reported-by: Andrey Albershteyn <aalbersh@redhat.com> Reported-by: Carlos Maiolino <cem@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
When tracing is active while reading the trace file, if the iterator reading the buffer detects that the writer has passed the iterator head, it will reset and set a "missed events" flag. This flag is passed to the output processing to show the user that events were missed: CPU:4 [LOST EVENTS] The problem is that the flag is reset after it is checked in ring_buffer_iter_dropped(). But the "trace" file iterates over all the CPU ring buffers and it will check if they are dropped when figuring out which buffer to print next. This prematurely clears the missed_events flag if the CPU buffer with the missed events is not the one that is printed next. On the iteration where the CPU buffer with the missed events is printed, the check if it had missed events would return false and the output does not show that events were missed. Do not reset the missed_events flag when checking if there were missed events, but instead clear it when moving the iterator head to the next event. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Link: https://patch.msgid.link/20260520220801.4fd09d13@fedora Fixes: c9b7a4a ("ring-buffer/tracing: Have iterator acknowledge dropped events") Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
On real hardware, panic and machine reboot may not flush hardware cache to memory. This means the persistent ring buffer, which relies on a coherent state of memory, may not have its events written to the buffer and they may be lost. Moreover, there may be inconsistency with the counters which are used for validation of the integrity of the persistent ring buffer which may cause all data to be discarded. To avoid this issue, stop recording of the ring buffer on panic and flush the cache of the ring buffer's memory. Fixes: e645535 ("tracing: Add option to use memmapped memory for trace boot instance") Cc: stable@vger.kernel.org Cc: Will Deacon <will@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Ian Rogers <irogers@google.com> Link: https://patch.msgid.link/177751969602.2136606.12031934362587643488.stgit@mhiramat.tok.corp.google.com Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
nr_subbufs in the ring buffer metadata is always initialized to zero because it is assigned from cpu_buffer->nr_pages before the page initialization loop has run. While nr_subbufs is not currently read by the kernel, it should reflect the actual buffer geometry in the meta page for correctness. Move the assignment after the page loop so that cpu_buffer->nr_pages holds the final count. Link: https://patch.msgid.link/20260512135420.99194-1-devnexen@gmail.com Fixes: 34e5b95 ("tracing: Introduce simple_ring_buffer") Reviewed-by: Vincent Donnefort <vdonnefort@google.com> Assisted-by: Claude:claude-opus-4-7 Signed-off-by: David Carlier <devnexen@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The unload_page callback expects the return value of load_page() as its argument: ret = load_page(va); unload(ret). Fix the rollback code in simple_ring_buffer_init_mm() where the descriptor's VA is used instead of the loaded page address. Link: https://patch.msgid.link/20260512141614.1759430-1-vdonnefort@google.com Fixes: 6359230 ("tracing: load/unload page callbacks for simple_ring_buffer") Signed-off-by: Vincent Donnefort <vdonnefort@google.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
As the output file is currently never created, the check will run every time, even if the inputs have not changed. Create an empty output file which allows make to skip the execution when it is not necessary. Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Vincent Donnefort <vdonnefort@google.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260520-tracing-ringbuffer-check-v1-1-d979cfab1338@weissschuh.net Fixes: 1211907 ("tracing: Generate undef symbols allowlist for simple_ring_buffer") Fixes: 58b4bd1 ("tracing: Adjust cmd_check_undefined to show unexpected undefined symbols") Reviewed-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The kerneldoc for device_is_bound() says it must be called with the device lock taken. Add missing synchronization to this driver. Fixes: 7fb3287 ("gpio: sim: stop using dev-sync-probe") Link: https://patch.msgid.link/20260518-gpio-dev-lock-v1-1-cc4736f3ff0b@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
The kerneldoc for device_is_bound() says it must be called with the device lock taken. Add missing synchronization to this driver. Fixes: 3a27f40 ("gpio: aggregator: stop using dev-sync-probe") Link: https://patch.msgid.link/20260518-gpio-dev-lock-v1-2-cc4736f3ff0b@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
The kerneldoc for device_is_bound() says it must be called with the device lock taken. Add missing synchronization to this driver. Fixes: c3e2a8a ("gpio: virtuser: stop using dev-sync-probe") Link: https://patch.msgid.link/20260518-gpio-dev-lock-v1-3-cc4736f3ff0b@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Introduce efi_get_kimg_kaslr_address() helper to compute the preferred kernel image load address dynamically when CONFIG_RANDOMIZE_BASE is enabled. The function derives a random offset by using the EFI-provided randomness combined with the timer tick value, and constrains it within CONFIG_RANDOMIZE_BASE_MAX_OFFSET. Update EFI_KIMG_PREFERRED_ADDRESS to call this helper so that the EFI stub can select a randomized load address when KASLR is active, while preserving the original base address behavior when KASLR is disabled or "nokaslr" is specified. Note: LoongArch can't KASLR for hibernation, so set efi_nokaslr to true if "resume=<devname>" is explicitly specified in cmdline. Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: WANG Rui <wangrui@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
When the kernel is relocated during early boot (efistub or kexec_file), a randomized load address may has already been selected and applied. In this case, performing KASLR again in relocate.c is unnecessary. Note: strictly-defined KASLR means the kernel's final runtime address has a random offset from the kernel's load address, which is implemented in relocate.c; broadly-defined KALSR means the kernel's final runtime address has a random offset from the kernel's link address (a.k.a. VMLINUX_LOAD_ADDRESS), which also include the efistlub implementation, kexec_file implementation and QEMU direct kernel boot. kaslr_disabled() return true only means strictly-defined KASLR is disabled. Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: WANG Rui <wangrui@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Validate the relocation address against the initrd region specified via "initrd=" or "initrdmem=" on the command line. Reject relocation targets that overlap the initrd to prevent memory corruption during early boot. Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: WANG Rui <wangrui@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
After commit feee6b2 ("mm/memory_hotplug: shrink zones when offlining memory"), __remove_pages() doesn't need the "zone" parameter so the "page" variable is also unused. Remove the unused code to avoid such build warning: arch/loongarch/mm/init.c: In function 'arch_remove_memory': arch/loongarch/mm/init.c:134:22: warning: variable 'page' set but not used [-Wunused-but-set-variable=] 134 | struct page *page = pfn_to_page(start_pfn); Cc: <stable@vger.kernel.org> Reviewed-by: Guo Ren <guoren@kernel.org> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Use flush_work() instead of cancel_work_sync() to terminate pending IRQ work in cs35l56_sdw_remove(). And flush_work() again after masking the interrupts to flush any queueing that was racing with the masking. This is the same sequence as cs35l56_sdw_system_suspend(). cs35l56_sdw_interrupt() takes the pm_runtime to prevent the bus powering- down before the interrupt status can be read and handled. The work releases this pm_runtime. So cancelling it, instead of flushing, could leave an unbalanced pm_runtime. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: e496112 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56") Link: https://patch.msgid.link/20260521123057.988732-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
Replace manual request_region()/release_region() with devm_request_region(). This lets the device-managed framework handle I/O region lifetime automatically and fixes: - A double release_region() when probe fails after acquiring the I/O region: the probe error path releases it, and then lenovo_ec_init() releases it again on the same error path. - A release-after-use window in lenovo_ec_exit() where release_region() was called before platform_device_unregister(), leaving the hwmon device active with a released I/O region. - Missing release_region() in lenovo_ec_probe() if devm_hwmon_device_register_with_info() fails. Remove all four manual release_region() calls that are now handled automatically and replace request_region with devm_request_region, use dev_err replace pr_err. Also remove the now-unnecessary braces around the single-statement if body. Fixes: 70118f8 ("hwmon: Add EC Chip driver for Lenovo ThinkStation motherboards") Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Kean Ren <rh_king@163.com> Link: https://lore.kernel.org/r/20260521035228.533317-2-rh_king@163.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The EC signature check uses && instead of || between the four byte comparisons. With &&, the condition is true only when ALL four bytes fail to match simultaneously, meaning the driver accepts a device as a valid Microchip EC if ANY single byte of the 4-byte "MCHP" signature happens to match. Due to short-circuit evaluation, if the first byte reads back as 'M' (0x4D, a very common register value), the remaining three comparisons are skipped entirely and the device is accepted. Change && to || so the check rejects devices that do not fully match the expected EC signature, as originally intended. Fixes: 70118f8 ("hwmon: Add EC Chip driver for Lenovo ThinkStation motherboards") Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Kean Ren <rh_king@163.com> Link: https://lore.kernel.org/r/20260521035228.533317-3-rh_king@163.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
adm1266_set_rtc() seeds the chip's SET_RTC register from ktime_get_seconds(), which returns CLOCK_MONOTONIC -- i.e. seconds since the host last booted, not seconds since the Unix epoch. The chip stamps that value into every blackbox record it captures. Userspace reading those timestamps back expects wall-clock seconds: that's what the SET_RTC frame layout documents (datasheet Rev. D, Table 84) and what every other consumer of "seconds since epoch" assumes. Seeding from CLOCK_MONOTONIC gives blackbox records a timestamp that is only meaningful within a single boot of the host and silently resets to small values on every reboot. Switch to ktime_get_real_seconds() so the seed matches what the register is documented to hold. Fixes: 15609d1 ("hwmon: (pmbus/adm1266) read blackbox") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai> Link: https://lore.kernel.org/r/20260515-adm1266-fixes-v1-1-1c1ea1349cfe@nexthop.ai Signed-off-by: Guenter Roeck <linux@roeck-us.net>
adm1266_nvmem_read_blackbox() declares a 5-byte stack buffer and passes it to i2c_smbus_read_block_data() to retrieve the 4-byte BLACKBOX_INFO response. i2c_smbus_read_block_data() does not honour caller buffer sizes -- it memcpy()s data.block[0] bytes from the SMBus transaction (where data.block[0] is the length byte returned by the slave device, up to I2C_SMBUS_BLOCK_MAX = 32): memcpy(values, &data.block[1], data.block[0]); If the device returns any block length above 5, the call overflows the caller's 5-byte stack buffer before the post-call if (ret != 4) return -EIO; check has a chance to reject the response. Widen the local buffer to I2C_SMBUS_BLOCK_MAX so the helper has room for any well-formed SMBus block response, matching the convention used by the other i2c_smbus_read_block_data() callers in this driver. Fixes: 15609d1 ("hwmon: (pmbus/adm1266) read blackbox") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai> Link: https://lore.kernel.org/r/20260515-adm1266-fixes-v1-2-1c1ea1349cfe@nexthop.ai Signed-off-by: Guenter Roeck <linux@roeck-us.net>
adm1266_nvmem_read_blackbox() loops over a record_count that comes straight from byte 3 of the BLACKBOX_INFO response. The destination buffer is data->dev_mem, sized for the nvmem cell's declared 2048 bytes (ADM1266_BLACKBOX_MAX_RECORDS * ADM1266_BLACKBOX_SIZE = 32 * 64). A device that reports a record_count greater than 32 -- whether due to firmware bugs, bus corruption, or a non-responsive slave returning 0xff -- would walk read_buff past the end of the dev_mem allocation on the trailing iterations. Cap record_count at ADM1266_BLACKBOX_MAX_RECORDS (introduced here) before entering the loop and return -EIO on any larger value, so a malformed BLACKBOX_INFO response cannot drive the loop out of bounds. Fixes: 15609d1 ("hwmon: (pmbus/adm1266) read blackbox") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai> Link: https://lore.kernel.org/r/20260515-adm1266-fixes-v1-3-1c1ea1349cfe@nexthop.ai Signed-off-by: Guenter Roeck <linux@roeck-us.net>
adm1266_pmbus_block_xfer() sets up the read transaction with .buf = data->read_buf, .len = ADM1266_PMBUS_BLOCK_MAX + 2, but read_buf in struct adm1266_data is declared as u8 read_buf[ADM1266_PMBUS_BLOCK_MAX + 1]; For a max-length block response (length byte = 255 + up to 1 PEC byte), the i2c controller is told to write 257 bytes into a 256-byte buffer, putting one byte past the end of read_buf. The same response also makes the subsequent PEC compare if (crc != msgs[1].buf[msgs[1].buf[0] + 1]) read a byte beyond the array. Bump the read_buf declaration to ADM1266_PMBUS_BLOCK_MAX + 2 so the buffer can hold the length byte, up to 255 payload bytes, and the PEC byte the i2c_msg length already accounts for. Fixes: 407dc80 ("hwmon: (pmbus/adm1266) Add Block process call") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai> Link: https://lore.kernel.org/r/20260515-adm1266-fixes-v1-4-1c1ea1349cfe@nexthop.ai Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In xe_oa_stream_open_ioctl(), when param.exec_q->width > 1 the function returns -EOPNOTSUPP directly, skipping the existing err_exec_q cleanup path. The exec_queue reference obtained by xe_exec_queue_lookup() is leaked. The exec queue holds a reference on the xe_file, which is only dropped during queue teardown. The leaked lookup ref is not on the file's exec_queue xarray, so file close cannot release it. This keeps both the exec queue and the file private state pinned indefinitely. Jump to err_exec_q instead of returning directly so the reference is released. Fixes: f0ed398 ("xe/oa: Fix query mode of operation for OAR/OAC") Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20260514203210.593488-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> (cherry picked from commit 339fa0b) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Platforms that fit more than one ADM1266 on different I2C buses at the same 7-bit slave address (a common shelf-management pattern, e.g. one device per power domain) end up with duplicate GPIO line labels because the existing format only includes the slave address. Including the adapter number disambiguates them. The adapter number is formatted as decimal to match the i2c-N convention used elsewhere in Linux (sysfs paths, dev nodes); the slave address keeps its conventional hexadecimal form. The label is purely informational (visible via gpioinfo and the gpiochip /sys/class/gpio name); no DT or ABI consumer parses it. Fixes: d98dfad ("hwmon: (pmbus/adm1266) Add support for GPIOs") Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai> Link: https://lore.kernel.org/r/20260512-adm1266-v3-5-a81a479b0bb0@nexthop.ai Signed-off-by: Guenter Roeck <linux@roeck-us.net>
…ed buffer adm1266_pmbus_block_xfer() copies the device-supplied block payload into the caller-provided buffer using the device-supplied length: memcpy(data_r, &msgs[1].buf[1], msgs[1].buf[0]); The helper does not know how large data_r is and trusts the device to return at most one record's worth of bytes. adm1266_nvmem_read_blackbox() violates that contract: it advances read_buff inside data->dev_mem in ADM1266_BLACKBOX_SIZE (64-byte) strides while the helper is willing to write up to ADM1266_PMBUS_BLOCK_MAX (255) bytes. A device that returns more than 64 bytes on the trailing record (read_buff offset 1984 in the 2048-byte dev_mem allocation) overflows dev_mem by up to 191 bytes before the post-call if (ret != ADM1266_BLACKBOX_SIZE) return -EIO; can reject the response. Contain the fix in the caller without changing the helper signature: read each record into a 255-byte local bounce buffer that matches the helper's maximum output, validate the returned length, and only then copy exactly ADM1266_BLACKBOX_SIZE bytes into the dev_mem slot. Fixes: 407dc80 ("hwmon: (pmbus/adm1266) Add Block process call") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai> Link: https://lore.kernel.org/r/20260515-adm1266-fixes-v1-5-1c1ea1349cfe@nexthop.ai Signed-off-by: Guenter Roeck <linux@roeck-us.net>
…rc/asrc SRC and ASRC modules must have at least one input and on one output formats to be usable. Do a sanity check during setup type and fail if either the number of input or output formats are 0. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://patch.msgid.link/20260526105748.26149-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
…utput The SRC module can only change the rate, it keeps the format and channels intact, but this does not mean the num_output_formats must be 0: The SRC module can support different formats/channels, we just need to check if the output format lists the correct combination of out rate and the input format/channels. Change the logic to prioritize the sink_rate of the module as target rate, then the rate of the FE in case of capture or in case of playback check the single rate specified in the output formats. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://patch.msgid.link/20260526105748.26149-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> says: SRC can only change the rate, we can still allow different bit depth and channels to be handled, the only restriction is that the input and output must have matching bit depth and channel format. In a separate patch do a sanity check for the number of formats on the input and output side as SRC/ASRC must have at least one of them. Link: https://patch.msgid.link/20260526105748.26149-1-peter.ujfalusi@linux.intel.com
xen_snd_front_evtchnl_pair_clear() resets evt_next_id for both channels. That is correct for the request channel, where evt_next_id is used to allocate the next request id. It is wrong for the event channel: incoming events are validated against evt_id, and evt_id is incremented by evtchnl_interrupt_evt(). This leaves the expected event id from the previous stream instance. A backend that restarts event ids for a reopened stream can then have valid current-position events dropped until the stale frontend id catches up. Reset evt_id for the event channel. Also advance the event-page consumer to the current producer while clearing the stream, so obsolete events queued for the previous stream instance are not delivered to the next ALSA runtime. Fixes: 1cee559 ("ALSA: xen-front: Implement ALSA virtual sound driver") Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260526-alsa-xen-event-channel-fixes-v1-1-91d3a6a50778@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
The request channel must be connected from ALSA .open(), because hw-rule queries and the stream open request use it. The event channel is different: XENSND_EVT_CUR_POS handling uses ALSA runtime buffer and period geometry, and the corresponding Xen stream parameters are not submitted to the backend until .prepare() sends XENSND_OP_OPEN. Currently .open() connects both channels. A backend current-position event, or a stale event queued for an earlier stream instance, can therefore reach xen_snd_front_alsa_handle_cur_pos() before runtime->buffer_size and runtime->period_size are valid. Add a per-channel connection helper, connect only the request channel in .open(), connect the event channel after a successful stream prepare, and disconnect it before stream close/free. Re-check the event-channel state after taking ring_io_lock so disconnecting the event channel synchronizes against a threaded IRQ that passed the initial lockless state test. Keep defensive runtime geometry checks in the position handler. Fixes: 1cee559 ("ALSA: xen-front: Implement ALSA virtual sound driver") Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260526-alsa-xen-event-channel-fixes-v1-2-91d3a6a50778@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
The OSS sequencer processes the input MIDI bytes into a sequencer
event to be dispatched later (in snd_seq_oss_midi_putc() called from
snd_seq_oss_process_event()). When it's a SysEx data, the event
record contains data.ext.ptr pointer to the original SysEx bytes, and
the referred data is copied into the pool afterwards at dispatching.
The problem is that, if the sequencer port gets closed concurrently
before the dispatch, the OSS sequencer core also releases the
resources (in snd_seq_oss_midi_check_exit_port()), while the pending
event may hold a stale pointer, eventually leading to a UAF at a later
dispatch.
Fortunately, there is already a refcounting mechanism (snd_use_lock_t)
for the OSS MIDI device access, and for addressing the issue above, we
just need to extend the refcount until the event gets dispatched.
This patch extends snd_seq_oss_process_event() to give back the
refcount object, which is in turn released after calling the sequencer
dispatcher with the given event in the caller side.
According to the original report, KASAN report as below:
KASAN slab-use-after-free in snd_seq_event_dup+0x40c/0x470
RIP: 0033:0x7f2cb66a6340
Read of size 6
Call trace:
dump_stack_lvl+0x73/0xb0 (?:?)
print_report+0xd1/0x650 (?:?)
srso_alias_return_thunk+0x5/0xfbef5 (?:?)
__virt_addr_valid+0x1a7/0x340 (?:?)
kasan_complete_mode_report_info+0x64/0x200 (?:?)
kasan_report+0xf7/0x130 (?:?)
snd_seq_event_dup+0x40c/0x470 (?:?)
kasan_check_range+0x10c/0x1c0 (?:?)
__asan_memcpy+0x27/0x70 (?:?)
snd_seq_event_dup+0x9/0x470 (?:?)
snd_seq_client_enqueue_event+0x139/0x240 (?:?)
_raw_spin_unlock_irqrestore+0x4b/0x60 (?:?)
snd_seq_kernel_client_enqueue+0x102/0x120 (?:?)
snd_seq_oss_write+0x416/0x4e0 (?:?)
apparmor_file_permission+0x20/0x30 (?:?)
odev_write+0x3b/0x60 (?:?)
vfs_write+0x1ce/0x850 (?:?)
lock_release+0xc8/0x2a0 (?:?)
__kasan_check_write+0x18/0x20 (?:?)
__mutex_unlock_slowpath+0x129/0x510 (?:?)
ksys_write+0xe1/0x180 (?:?)
mutex_unlock+0x16/0x20 (?:?)
odev_ioctl+0x65/0xc0 (?:?)
__x64_sys_write+0x46/0x60 (?:?)
x64_sys_call+0x7d/0x20d0 (?:?)
do_syscall_64+0xc1/0x360 (arch/x86/entry/syscall_64.c:87)
entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-and-tested-by: Zhang Cen <rollkingzzc@gmail.com>
Closes: https://lore.kernel.org/20260521233900.478153-1-rollkingzzc@gmail.com
Link: https://patch.msgid.link/20260526152843.617503-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add a device-specific quirk for the Novation Mininova synthesizer (USB ID 1235:001e) to enable proper recognition and functionality as a MIDI device. Signed-off-by: Uwe Küchler <uwe@kuechler.org> Link: https://patch.msgid.link/20260526162033.7513-1-uwe@kuechler.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
QUIRK_FLAG_IFB_SILENCE_ON_EMPTY was introduced into usb-audio before without appropriate documentation, so add it. Fixes: a238120 ("ALSA: usb-audio: add IFB_SILENCE_ON_EMPTY quirk for Behringer Flow 8") Signed-off-by: Rong Zhang <i@rong.moe> Link: https://patch.msgid.link/20260527-uac-quirk-get-cur-vol-v1-1-e9362b712e5e@rong.moe Signed-off-by: Takashi Iwai <tiwai@suse.de>
Use a flexible array member to combine allocations. Clean up surrounding code and allocate based on afe_priv and not platform_priv which is a void pointer. struct_size needs a properly typed pointer to work. Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260519010413.629214-1-rosenp@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, CONFIG_SND_SOC_SDCA is a hidden Kconfig symbol, so it must be
selected by a user selectable symbol to be enabled. However, it may not
be possible for configurations to select this symbol without running
into a recursive dependency issue:
error: recursive dependency detected!
symbol SOUNDWIRE depends on SND_SOC_SDCA_OPTIONAL
symbol SND_SOC_SDCA_OPTIONAL default value contains SND_SOC_SDCA
symbol SND_SOC_SDCA is selected by SND_SOC_ES9356
symbol SND_SOC_ES9356 depends on SOUNDWIRE
Turn CONFIG_SND_SOC_SDCA into a user selectable symbol so that drivers
can depend on it and allow the user to enable it explicitly.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://patch.msgid.link/20260526-es9356-dep-fixes-v1-1-39ac16f43d54@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The indentation of CONFIG_SND_SOC_ES9356 uses spaces, instead of the Kconfig standard using tabs. Adjust it. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260526-es9356-dep-fixes-v1-2-39ac16f43d54@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
When building without CONFIG_SND_SOC_SDCA, there is an error at link time when building the es9356-sdca driver: ERROR: modpost: "sdca_asoc_q78_get_volsw" [sound/soc/codecs/snd-soc-es9356.ko] undefined! ERROR: modpost: "sdca_asoc_q78_put_volsw" [sound/soc/codecs/snd-soc-es9356.ko] undefined! Add an explicit dependency on CONFIG_SND_SOC_SDCA to ensure these symbols are always present when building the driver. Fixes: 5d9cb74 ("ASoC: es9356-sdca: Add ES9356 SDCA driver") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260526-es9356-dep-fixes-v1-3-39ac16f43d54@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
Nathan Chancellor <nathan@kernel.org> says: This series addresses the build failure I reported at [1]. The first patch allows CONFIG_SND_SOC_SDCA to be selected by a user. The third patch fixes the actual build failure by requiring CONFIG_SND_SOC_SDCA to enable CONFIG_SND_SOC_ES9356. The second patch is a standalone clean up to make the third patch diff cleaner. If there are any issues, please let me know. [1]: https://lore.kernel.org/20260518224657.GA536765@ax162/ Link: https://patch.msgid.link/20260526-es9356-dep-fixes-v1-0-39ac16f43d54@kernel.org
event_process_midi() borrows msynth->output_rfile.output and then
passes the substream to dump_midi() and snd_rawmidi_kernel_write()
without synchronizing with the output open/close transition.
midisynth_use() also publishes output_rfile before
snd_rawmidi_output_params() has finished.
The last midisynth_unuse() can therefore release the same rawmidi file
and free substream->runtime before snd_rawmidi_kernel_write1() takes
its runtime buffer reference. That leaves the event_input path using a
stale substream or runtime and can end in a NULL-deref or use-after-free.
Fix this with two pieces of synchronization. Keep a short IRQ-safe
spinlock only for publishing or clearing output_rfile and for pairing
the output snapshot with an snd_use_lock_t reference. Once
event_process_midi() has taken that in-flight reference, it drops the
spinlock before calling snd_seq_dump_var_event(), dump_midi(), or
snd_rawmidi_kernel_write(). midisynth_unuse() now detaches the visible
rawmidi file under the same spinlock, waits for the in-flight writers
to drain, and only then drains and releases the saved file.
midisynth_use() likewise opens into a local snd_rawmidi_file and
publishes it only after snd_rawmidi_output_params() succeeds.
The buggy scenario involves two paths, with each column showing the
order within that path:
event_input path: last unuse path:
1. event_process_midi() snapshots 1. midisynth_unuse() starts
output_rfile.output. tearing down output_rfile.
2. dump_midi() reaches 2. snd_rawmidi_kernel_release()
snd_rawmidi_kernel_write() closes the output file.
before runtime is pinned. 3. close_substream() frees
3. The callback keeps using substream->runtime.
the borrowed substream.
Validation reproduced this kernel report:
KASAN null-ptr-deref in snd_rawmidi_kernel_write1+0x56/0x360
RIP: 0033:0x7fde7dd0837f
RIP: 0010:snd_rawmidi_kernel_write1+0x56/0x360
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Assisted-by: Codex:gpt-5.5
Signed-off-by: Zhang Cen <rollkingzzc@gmail.com>
Link: https://patch.msgid.link/20260527062948.3614025-1-rollkingzzc@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Use a weak reverse selection to suggest the config SERIAL_MULTI_INSTANTIATE just like cs35l56 did. Signed-off-by: Johny Lin <johnylin@google.com> Link: https://patch.msgid.link/20260527023350.3067547-1-johnylin@google.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
simple_mux_control_put() rejects values greater than e->items, but enum control values are zero based. For the two-entry mux used by this driver, valid values are 0 and 1, so value 2 must be rejected as well. Accepting e->items can store an invalid mux state, pass it to the GPIO setter, and pass it on to the DAPM mux update path where it is used as an index into the enum text array. Use the same >= e->items check used by the ASoC enum helpers. Fixes: 342fbb7 ("ASoC: add simple-mux") Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260527-asoc-simple-mux-enum-bounds-v1-1-3f805b9fc671@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
bardliao
requested review from
dbaluta,
kv2019i,
lgirdwood,
plbossart,
ranj063,
shumingfan and
ujfalusi
as code owners
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Upstream merge