kernel/linux.git, branch v5.15.217

Linux 5.15.217

2026-08-23T12:17:32+00:00

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

ring-buffer: Use current_context for safe per-CPU buffer swap

2026-08-23T12:17:32+00:00

[ Upstream commit f27bdc43077e4fcb5557dfc315ee8d91e741f483 ] The ring_buffer_swap_cpu() function currently checks the per-CPU committing counter to determine if a buffer is actively being written to before performing the swap. However, there exists a race window where this check can be bypassed: ring_buffer_lock_reserve cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_a rb_reserve_next_event rb_start_commit // inc committing if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) {...} __rb_reserve_next rb_move_tail rb_end_commit(cpu_buffer); // dec committing => 0 /* interrupt hits here, successfully swaps! */ local_inc(&cpu_buffer->committing); ring_buffer_unlock_commit cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_b rb_commit rb_end_commit RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing)) // triggers warning The committing counter can temporarily drop to 0 during a single write operation (within rb_move_tail), creating a window where swap can succeed even though the write is still in progress. This leads to inconsistent buffer state and triggers the RB_WARN_ON in rb_commit(). Replace the committing counter check with current_context checks, which are set at the entry of ring_buffer_lock_reserve() and remain valid throughout the entire write operation, providing a reliable indicator of buffer busy state during swap. Cc: stable@vger.kernel.org Fixes: 4239c38fe0b3 ("ring-buffer: Process commits whenever moving to a new page.") Link: https://patch.msgid.link/20260803005640.2445666-2-wutengda@huaweicloud.com Signed-off-by: Tengda Wu Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin

ring-buffer: Remove jump to out label in ring_buffer_swap_cpu()

2026-08-23T12:17:32+00:00

[ Upstream commit f115d2b70bff2665f67fa8e8dc5ed9452b696c44 ] The function ring_buffer_swap_cpu() has a bunch of jumps to the label out that simply returns "ret". There's no reason to jump to a label that simply returns a value. Just return directly from there. This goes back to almost the beginning when commit 8aabee573dff ("ring-buffer: remove unneeded get_online_cpus") was introduced. That commit removed a put_online_cpus() from that label, but never updated all the jumps to it that now no longer needed to do anything but return a value. Cc: Mathieu Desnoyers Link: https://lore.kernel.org/20250527145753.6b45d840@gandalf.local.home Reviewed-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Stable-dep-of: f27bdc43077e ("ring-buffer: Use current_context for safe per-CPU buffer swap") Signed-off-by: Sasha Levin

jiffies: Cast to unsigned long in secs_to_jiffies() conversion

2026-08-23T12:17:31+00:00

commit bb2784d9ab49587ba4fbff37a319fff2924db289 upstream. While converting users of msecs_to_jiffies(), lkp reported that some range checks would always be true because of the mismatch between the implied int value of secs_to_jiffies() vs the unsigned long return value of the msecs_to_jiffies() calls it was replacing. Fix this by casting the secs_to_jiffies() input value to unsigned long. Fixes: b35108a51cf7ba ("jiffies: Define secs_to_jiffies()") Reported-by: kernel test robot Signed-off-by: Easwar Hariharan Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20250130192701.99626-1-eahariha@linux.microsoft.com Closes: https://lore.kernel.org/oe-kbuild-all/202501301334.NB6NszQR-lkp@intel.com/ Signed-off-by: Greg Kroah-Hartman

drm/virtio: Unlock reservations on dma_resv_reserve_fences() error

2026-08-23T12:17:31+00:00

commit 0f877398d30e1df657a31a62f7c7de1869b072b5 upstream. Unlock reservations on dma_resv_reserve_fences() error to fix recursive locking of the reservations when this error happens. Cc: stable@vger.kernel.org Fixes: c8d4c18bfbc4 ("dma-buf/drivers: make reserving a shared slot mandatory v4") Reviewed-by: Thomas Hellström Signed-off-by: Dmitry Osipenko Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-5-dmitry.osipenko@collabora.com Signed-off-by: Gerd Hoffmann Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Reserve fence slots on buffer objects in cotables

2026-08-23T12:17:31+00:00

commit 544ccad739251b21dfa1e7f4b57aa9ea50d2d0f1 upstream. The buffer objects created by cotables were missing fence reservations. They are created from vmw_validation_res_validate which makes them miss the ttm_eu_reserve_buffers which is called from vmw_validation_bo_reserve. Cotables are the only resources which create a buffer object in the create callback so make sure the code also reserves the slots. Signed-off-by: Zack Rusin Co-developed-by: Christian König Reviewed-by: Christian König Fixes: c8d4c18bfbc4 ("dma-buf/drivers: make reserving a shared slot mandatory v4") Link: https://patchwork.freedesktop.org/patch/msgid/20220422161342.1142584-1-zack@kde.org Signed-off-by: Greg Kroah-Hartman

udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()

2026-08-23T12:17:31+00:00

commit 1d0e25c1ddf2063c499264fb2ba0fa6a3e4f8a00 upstream. The message of commit 504e2b4ab97a ("dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning") says: > The CPU sync at map/unmap time is also redundant for udmabuf: > begin_cpu_udmabuf() and end_cpu_udmabuf() already perform explicit > cache synchronization via dma_sync_sgtable_for_cpu/device() when CPU > access is requested through the dma-buf interface. This, however, does not apply to the first time begin_cpu_udmabuf() is called on an udmabuf, in which case the implementation previously relied on get_sg_table() to perform the cache synchronisation. Ensure to call dma_sync_sgtable_for_cpu() in that case as well. Fixes: 504e2b4ab97a ("dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning") Signed-off-by: Robert Mader Reviewed-by: Mikhail Gavrilov Signed-off-by: Vivek Kasireddy Link: https://patch.msgid.link/20260627105725.9083-1-robert.mader@collabora.com Signed-off-by: Greg Kroah-Hartman

binfmt_misc: use exe_file_deny_write_access() for the interpreter clone

2026-08-23T12:17:31+00:00

commit fa5990ca8fd917003e526036bcc50413edb9722c upstream. For MISC_FMT_OPEN_FILE entries load_misc_binary() clones the registered interpreter file and denies write access to the clone via plain deny_write_access(). The clone is installed as bprm->interpreter and later released by the exec machinery through exe_file_allow_write_access() which skips the i_writecount increment for files with FMODE_FSNOTIFY_HSM set. The deny and allow side can therefore come to different conclusions when pre-content watches are in play: if a pre-content watch is added to the interpreter after registration every subsequent exec through that entry takes a write denial on the clone that is never paired with a write allowance, driving the interpreter inode's i_writecount further down with each exec and leaving the interpreter unwritable even after the entry and all its users are gone. Take the write denial via exe_file_deny_write_access() so both sides of the pairing base their decision on the same file mode, and propagate failure instead of silently ignoring it: an interpreter that is concurrently open for writing now fails the exec with ETXTBSY, exactly like an interpreter freshly opened via open_exec() would. Link: https://patch.msgid.link/20260710-work-binfmt_misc-locking-v3-2-a162f7cb58d6@kernel.org Fixes: 0357ef03c94e ("fs: don't block write during exec on pre-content watched files") Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman

net/x25: fix use-after-free of the socket by its timers

2026-08-23T12:17:31+00:00

commit 2195424c3da2ef1829a63b807e3a900a90e57d85 upstream. The x25 timers are armed with mod_timer() and cancelled with timer_delete(), so a pending timer holds no reference on the socket and a cancel does not wait for a callback already running on another CPU. x25_heartbeat_expiry() also rearms unconditionally, so it can reinstall sk->sk_timer after __x25_destroy_socket() has passed its cancel point. The following __sock_put() frees the socket while the timer is still queued, and the next expiry uses freed memory. KASAN reports a slab-use-after-free on the kmalloc-2k object freed by close(). timer_delete_sync() cannot be used here: x25_heartbeat_expiry() and x25_timer_expiry() both reach the cancels from inside the timer they would wait on, through __x25_destroy_socket() and x25_disconnect(). Arm the timers with sk_reset_timer() and cancel them with sk_stop_timer() so that an armed timer owns a reference, and release it in both expiry handlers. Rearm the heartbeat only while sk_hashed(sk) is still true, since __x25_destroy_socket() unlinks the socket before dropping it. Arm the deferred destroy timer the same way and drop its reference in x25_destroy_timer(). Reproduced on net with KASAN, with the heartbeat period shortened so the window recurs. With this patch the reproducer no longer triggers a report and /proc/net/x25 drains. Discovered by XBOW, triaged by Baul Lee Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260726220342.47245-1-baul.lee@xbow.com Signed-off-by: Jakub Kicinski [ adjusted context due to `del_timer()` not yet renamed to `timer_delete()` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG

2026-08-23T12:17:31+00:00

[ Upstream commit 36a05d2820077bb3955acb8111e1041d39148037 ] On the packet reception path, the ID of the MAC Port on which the packet was received, is embedded in the RX DMA Descriptor's metadata. The ID is extracted using the helper function cppi5_desc_get_tags_ids() which fills in the 16-bit Source Tag into the 'port_id' variable. However, it is only the lower 8-bits of the 16-bit Source Tag that represent the MAC Port ID, while the upper 8-bits are Hardware-Reserved and carry an arbitrary value. With the existing logic, sporadic kernel crash is observed due to the subsequent driver code accessing out-of-bound memory because of an invalid port_id. Hence, fix the port_id extraction logic to use only the lower 8-bits of the Source Tag as the MAC Port ID. Fixes: 93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver") Signed-off-by: Siddharth Vadapalli Reviewed-by: Chintan Vankar Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260807111738.2055900-1-s-vadapalli@ti.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin