summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
14 daysHID: bpf: Fix hid_bpf_get_data() range checkYiyang Chen
hid_bpf_get_data() returns a pointer into the HID-BPF context data when the caller-provided offset and size fit inside ctx->allocated_size. The current check adds rdwr_buf_size and offset before comparing the result against ctx->allocated_size. Since both values are unsigned, a very large size can wrap the sum below ctx->allocated_size and make the helper return a pointer even though the requested range is not contained in the backing buffer. Use check_add_overflow() to reject wrapped range ends before comparing the requested range end against ctx->allocated_size. Fixes: 658ee5a64fcf ("HID: bpf: allocate data memory for device_event BPF programs") Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
14 daysxen/front-pgdir-shbuf: free grant reference head on errorsYousef Alhouseen
grant_references() allocates a private grant-reference head before claiming references for the page directory and, for guest-owned buffers, the data pages. The success path frees the remaining head, but claim failures and grant_refs_for_buffer() errors return immediately. Unwind through a common exit path so the private grant-reference head is released even when granting fails part-way through setup. The caller still tears down any references already stored in buf->grefs. Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Juergen Gross <jgross@suse.com> Message-ID: <20260629160517.29340-1-alhouseenyousef@gmail.com>
14 daysxen/gntdev: fix error handling in ioctlWentao Liang
When gntdev_ioctl_map_grant_ref() fails to copy the operation result back to userspace after successfully adding the mapping to the list, the error path returns -EFAULT without releasing the reference acquired by gntdev_alloc_map(). The mapping remains in priv->maps with a refcount of 1, causing a memory leak and a dangling list entry. Additionally, gntdev_add_map() may modify map->index to avoid overlap with existing mappings. Therefore, the index returned to userspace must be obtained after gntdev_add_map() completes. Fix this by holding the mutex across gntdev_add_map(), retrieving the correct index, and copy_to_user(). If copy_to_user() fails, remove the mapping from the list and release the reference while still holding the lock. Cc: stable@vger.kernel.org Fix these issues by properly handling all error cases. Fixes: 1401c00e59ea ("xen/gntdev: convert priv->lock to a mutex") Fixes: 68b025c813c2 ("xen-gntdev: Add reference counting to maps") Signed-off-by: Wentao Liang <vulab@iscas.ac.cn> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com> Message-ID: <20260622112541.38194-1-vulab@iscas.ac.cn>
14 daysxen: Replace __ASSEMBLY__ with __ASSEMBLER__ in header filesThomas Huth
While the GCC and Clang compilers already define __ASSEMBLER__ automatically when compiling assembly code, __ASSEMBLY__ is a macro that only gets defined by the Makefiles in the kernel. This can be very confusing when switching between userspace and kernelspace coding, or when dealing with uapi headers that rather should use __ASSEMBLER__ instead. So let's standardize now on the __ASSEMBLER__ macro that is provided by the compilers. This is a completely mechanical patch (done with a simple "sed -i" statement). Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com> Message-ID: <20260619114547.159637-1-thuth@redhat.com>
14 daysxen/pvcalls: bound backend response req_id before indexing rsp[]Michael Bommarito
pvcalls_front_event_handler() takes req_id directly from the backend-supplied ring response and uses it to index the fixed-size bedata->rsp[] array for a memcpy() and a store, with no range check. A malicious or buggy backend can set req_id past PVCALLS_NR_RSP_PER_RING and drive an out-of-bounds write past the bedata allocation. req_id was also declared int while the wire field rsp->req_id is u32, so a range check on the signed value alone is insufficient: a backend req_id of 0xffffffff becomes -1, passes a >= PVCALLS_NR_RSP_PER_RING test and indexes bedata->rsp[-1]. Declare req_id as u32 so a single bound covers both ends. A backend that sends an out-of-range req_id has violated the wire protocol, so rather than silently dropping the response, log once and stop trusting the backend: set bedata->disabled. The event handler then ignores further responses, and the request paths that wait for a response return -EIO instead of blocking forever. This mirrors the fatal-error handling xen-netback uses (xenvif_fatal_tx_err()). The pvcalls frontend currently trusts its backend, so this is not a classic-Xen security issue, but it matters for hardening PV frontends against malicious backends (confidential and disaggregated deployments). Fixes: 2195046bfd69 ("xen/pvcalls: implement socket command and handle events") Suggested-by: Juergen Gross <jgross@suse.com> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com> Message-ID: <20260617014149.2647404-1-michael.bommarito@gmail.com>
2026-07-01pinctrl: meson: restore non-sleeping GPIO accessViacheslav Bocharov
Commit 28f240683871 ("pinctrl: meson: mark the GPIO controller as sleeping") set gpio_chip.can_sleep = true to work around gpio-shared-proxy holding a spinlock across a sleeping pinctrl config path. That locking bug is now fixed in the shared-proxy itself ("gpio: shared-proxy: always serialize with a sleeping mutex"), so the controller-wide workaround is no longer needed; the meson GPIO controller does not sleep. meson_gpio_get/set/direction_* access MMIO through regmap. The regmap_mmio bus uses fast I/O (spinlock) locking, so these value callbacks do not contain sleeping operations. Since gpio_chip.can_sleep describes the get/set value path, restore can_sleep = false. Marking the controller sleeping also broke atomic value consumers such as w1-gpio (1-Wire bitbang): w1_io.c runs its read time slot under local_irq_save() and uses the non-cansleep gpiod_set_value() / gpiod_get_value(), which with can_sleep=true trigger WARN_ON(can_sleep) in gpiolib on every transferred bit (from w1_gpio_write_bit() / w1_gpio_read_bit() via w1_reset_bus() and w1_search()). The printk and stack dump inside the IRQs-off, microsecond-scale time slot destroy the bit timing, so reset/presence detection and ROM search fail: the bus master registers but w1_master_slave_count stays at 0 and no devices are found. Verified on an Amlogic A113X board (DS18B20 on GPIOA_14): with can_sleep restored to false the warnings are gone and the sensor is detected and read again. This must not be applied or backported without the shared-proxy locking fix above; otherwise the original Khadas VIM3 splat returns on boards that genuinely share a meson GPIO. Fixes: 28f240683871 ("pinctrl: meson: mark the GPIO controller as sleeping") Link: https://lore.kernel.org/all/20260105150509.56537-1-bartosz.golaszewski@oss.qualcomm.com/ Signed-off-by: Viacheslav Bocharov <v@baodeep.com> Acked-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260625115718.1678991-3-v@baodeep.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-07-01gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probeVladimir Zapolskiy
Out of memory situation on driver's probe is expected to be reported to the driver's framework with a proper -ENOMEM error code. Fixes: 35570ac6039e ("gpio: add GPIO driver for the Timberdale FPGA") Signed-off-by: Vladimir Zapolskiy <vz@kernel.org> Link: https://patch.msgid.link/20260630145148.4081967-1-vz@kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-07-01drm/i915/bios: range check LFP Data Block panel_type2Jani Nikula
While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: 6434cf630086 ("drm/i915/bios: calculate panel type as per child device index in VBT") Cc: stable@vger.kernel.org # v6.0+ Cc: Animesh Manna <animesh.manna@intel.com> Cc: Ville Syrjälä <ville.syrjala@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v1 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260626140155.1389655-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-07-01drm/i915/vrr: require valid min/max vfreq for VRRJani Nikula
Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: 117cd09ba528 ("drm/i915/display/dp: Compute VRR state in atomic_check") Cc: stable@vger.kernel.org # v5.12+ Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260625131040.1051272-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-06-30Merge tag 'probes-fixes-v7.2-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull probes fixes from Masami Hiramatsu: "fprobe fixes and spelling typos: - Fix NULL pointer dereference in fprobe_fgraph_entry(). Prevent general protection faults by checking shadow-stack reservation bounds. Skip mid-flight registered fprobes that were not counted during sizing. eprobe: fix string pointer extraction - Correct the casting of string pointers read from the ringbuffer to prevent truncation of base event pointer variables when dereferencing FILTER_PTR_STRING fields. tracing/probes: clean up argument parsing and BTF helper logic - Make the $ prefix mandatory for comm access: Require the $ prefix for special fetcharg variables like $comm and $COMM, preventing naming conflicts with regular BTF-based event fields. - Fix double addition of offset for @+FOFFSET: Clear the temporary offset variable after setting the FETCH_OP_FOFFS instruction to avoid applying the offset multiple times. - Remove WARN_ON_ONCE from parse_btf_arg: Prevent triggering a kernel warning via user-space input when creating a kprobe event on a raw address. - Fix typo in a log message: Correct a spelling error ("$-valiable") in trace probe log messages. samples/trace_events: improve error checking - Validate the thread pointer returned from kthread_run() in the trace events sample code to properly handle thread creation failures" * tag 'probes-fixes-v7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: tracing/probes: Make the $ prefix mandatory for comm access tracing/fprobe: Fix NULL pointer dereference in fprobe_fgraph_entry() tracing/probes: Fix double addition of offset for @+FOFFSET tracing: eprobe: read the complete FILTER_PTR_STRING pointer tracing/events: Fix to check the simple_tsk_fn creation tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg tracing: probes: fix typo in a log message
2026-06-30ksmbd: fix app-instance durable supersede session UAFNamjae Jeon
ksmbd_close_fd_app_instance_id() looks up a prior durable handle by AppInstanceId and closes it through opinfo->sess->file_table. This is unsafe after the original session has been torn down. session_fd_check() preserves reconnectable durable handles in the global table and clears opinfo->conn/fp->conn, but opinfo->sess can still point to the freed ksmbd_session. Use opinfo->conn as the orphan sentinel, but make the check reliable by serializing it with session_fd_check(). That path clears opinfo->conn under fp->f_ci->m_lock, so hold the same lock while testing opinfo->conn and while dereferencing opinfo->sess->file_table. Also avoid closing through the session file table if the volatile id has already been unpublished by session teardown. Durable reconnect must keep the two fields consistent. Rebinding only opinfo->conn leaves opinfo->sess pointing at the old freed session, so a later app-instance supersede can pass the conn check and write-lock the freed session's file table. Clear opinfo->sess when preserving a durable handle during session teardown, and set it to the reconnecting session when opinfo->conn is rebound in ksmbd_reopen_durable_fd(). Fixes: 16c30649709d ("ksmbd: handle durable v2 app instance id") Reported-by: Gil Portnoy <dddhkts1@gmail.com> Co-developed-by: Gil Portnoy <dddhkts1@gmail.com> Signed-off-by: Gil Portnoy <dddhkts1@gmail.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-06-30ksmbd: snapshot previous oplock state before durable checksNamjae Jeon
smb_grant_oplock() checks the previous oplock holder's o_fp to decide whether a durable handle should be invalidated when the oplock break cannot be delivered. prev_opinfo is obtained with opinfo_get_list(), which pins only the oplock_info. It does not pin the ksmbd_file stored in opinfo->o_fp. A concurrent last close can unlink the opinfo from ci->m_op_list under ci->m_lock and then free the ksmbd_file. The oplock_info can still be kept alive by the refcount taken by opinfo_get_list(), but o_fp may already point at freed memory by the time smb_grant_oplock() reads is_durable, conn, or tcon. Snapshot the previous holder's durable state while ci->m_lock is held, then use only the copied values after dropping the lock. This keeps the o_fp lifetime tied to the inode lock without taking an extra ksmbd_file reference. Taking such a reference is unsafe here because smb_grant_oplock() does not necessarily have the previous holder's session work, and dropping the temporary reference can otherwise become the final putter. Fixes: 26fa88dc877c ("ksmbd: invalidate durable handles on oplock break") Reported-by: Gil Portnoy <dddhkts1@gmail.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-06-30ksmbd: close superseded durable handles through refcount handoffGil Portnoy
ksmbd_close_disconnected_durable_delete_on_close() collects disconnected durable handles for a name being superseded by a new delete-on-close open, drops ci->m_lock, then closes each collected handle directly with __ksmbd_close_fd(). That bypasses the FP_CLOSED and refcount handoff used by the other close paths. If a durable reconnect or the durable scavenger already took a reference to the same fp, the direct __ksmbd_close_fd() can free the ksmbd_file while that other holder still owns a live reference. Claim the disconnected durable handle before unlinking it from m_fp_list. While holding ci->m_lock and global_ft.lock, only take ownership when the durable lifetime reference is the only remaining reference. Then take a transient reference, remove the fp from global_ft, mark it FP_CLOSED, and move it to the local dispose list. If another holder already has a reference, leave the fp linked and let that holder complete its path. The dispose loop then drops both references owned by the claim. This keeps the force-close path in the same refcount handoff model as the durable scavenger and avoids leaving a live reconnected fp detached from m_fp_list. Fixes: 166e4c07023b ("ksmbd: supersede disconnected delete-on-close durable handle") Signed-off-by: Gil Portnoy <dddhkts1@gmail.com> Co-developed-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-06-30ksmbd: fix use-after-free of fp->owner.name in durable handle owner checkGil Portnoy
Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d ("ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd") made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized. BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8 Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify. Fixes: 49110a8ce654 ("ksmbd: validate owner of durable handle on reconnect") Assisted-by: Henry (Claude):claude-opus-4 Signed-off-by: Gil Portnoy <dddhkts1@gmail.com> Co-developed-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-06-30smb/server: do not require delete access for non-replacing linksChenXiaoSong
Reproducer: 1. server: systemctl start ksmbd 2. client: mount -t cifs //${server_ip}/export /mnt 3. client: touch /mnt/file; ln /mnt/file /mnt/hardlink 4. client err log: ln: failed to create hard link 'hardlink' => 'file': Permission denied 5. server err log: ksmbd: no right to delete : 0x80 Fixes: 13f3942f2bf4 ("ksmbd: add per-handle permission check to FILE_LINK_INFORMATION") Cc: stable@vger.kernel.org Reported-by: Steve French <stfrench@microsoft.com> Signed-off-by: ChenXiaoSong <chenxiaosong@kylinos.cn> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-06-30ksmbd: don't hold ci->m_lock while waiting for a lease break ackNamjae Jeon
When a cifs.ko client caches a read-handle (RH) lease via deferred close and a conflicting open arrives, ksmbd breaks the lease and waits for the acknowledgment in wait_for_break_ack() for up to OPLOCK_WAIT_TIME (35s). __smb_break_all_levII_oplock() runs that wait while holding ci->m_lock for read. cifs.ko reacts to a handle-lease break by closing the deferred handle rather than sending a lease break acknowledgment. That close path (close_id_del_oplock() -> opinfo_del()) takes ci->m_lock for write and is exactly what would wake the waiter, but it blocks on the read lock held by the waiting thread. The break is then resolved only by the 35s timeout, so xfstests generic/001 takes ~78s with leases enabled versus ~4s with oplocks only. Collect the target opinfos (each pinned with a reference) while holding ci->m_lock, then break them after releasing it, matching how smb_grant_oplock() already breaks a conflicting lease using only a reference. The reference keeps the opinfo (and its conn and lease) alive across the unlocked window, and a close racing the break is handled by the existing OPLOCK_CLOSING state check. Apply the same fix to the parent lease break paths. Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-06-30ksmbd: doc: update feature support status for durable handles and compressionNamjae Jeon
Update ksmbd.rst to reflect the current implementation status of SMB features. Durable handles (v1, v2) and SMB3.1.1 Compression are now fully supported in ksmbd, so update their status from "Planned for future" to "Supported". Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-06-30ksmbd: annotate oplock list traversals under m_lockRunyu Xiao
session_fd_check() and ksmbd_reopen_durable_fd() walk ci->m_op_list with list_for_each_entry_rcu() while holding ci->m_lock for write. That is the local inode/oplock serializer, but the RCU-list iterator does not currently tell lockdep about it. Pass lockdep_is_held(&ci->m_lock) to these iterators so CONFIG_PROVE_RCU_LIST can see the rwsem protection already in place. This was found by our static analysis tool and then manually reviewed against the current tree. The dynamic triage evidence is a target-matched CONFIG_PROVE_RCU_LIST warning; the change is limited to documenting the existing protection contract. This is a lockdep annotation cleanup. It does not change oplock list lifetime or durable-handle behavior. Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-06-30ksmbd: fix outstanding credit leak on abort and error pathsNamjae Jeon
smb2_validate_credit_charge() adds the request's CreditCharge to conn->outstanding_credits when an SMB2 PDU is received, and smb2_set_rsp_credits() subtracts it again when the response is built. However smb2_set_rsp_credits() only runs on the normal response path: - __process_request() returning SERVER_HANDLER_ABORT (unimplemented command, command index out of range, signature check failure, or a handler that sets send_no_response such as a cancelled blocking lock) breaks out of the processing loop before set_rsp_credits() is called; - smb2_set_rsp_credits() itself returns early with -EINVAL (total credit overflow or insufficient credits) before the subtraction. On all of these paths the charge added at receive time is never returned, so conn->outstanding_credits only grows. Because a client can repeatedly trigger them (e.g. by sending unimplemented commands or by issuing and cancelling blocking locks), outstanding_credits eventually reaches total_credits and smb2_validate_credit_charge() then rejects every subsequent request, wedging the connection. Record the charge that was added in work->credit_charge and release any charge still pending at the single send. exit point of __handle_ksmbd_work(), which all abort and error paths fall through to. smb2_set_rsp_credits() clears work->credit_charge once it has returned the charge so the response path is unchanged and the credit is never released twice. Paths that never charged a credit (no multi-credit support, validation failure) leave work->credit_charge at zero and are unaffected. Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-06-30ksmbd: fix credit charge calculation for SMB2 QUERY_INFONamjae Jeon
smb2_validate_credit_charge() computes the credit charge a request is allowed to consume from the payload size: CreditCharge = (max(SendPayloadSize, ResponsePayloadSize) - 1)/65536 + 1 For SMB2 QUERY_INFO, the server must validate CreditCharge based on the *maximum* of InputBufferLength and OutputBufferLength. ksmbd instead summed the two lengths, which overestimates the required charge. As a result a single-credit QUERY_INFO whose InputBufferLength and OutputBufferLength each fit in 64KB but whose sum exceeds 64KB is rejected with STATUS_INVALID_PARAMETER, even though it is a valid request. IOCTL already uses max() of the request and response sizes; make QUERY_INFO consistent by feeding InputBufferLength as the request length and OutputBufferLength as the expected response length so that smb2_validate_credit_charge() takes their maximum. Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-06-30ksmbd: avoid zeroing the read buffer in smb2_read()Namjae Jeon
smb2_read() allocates the read payload buffer with kvzalloc(), zeroing up to max_read_size bytes (1MB or more with multichannel) on every read, only to immediately overwrite the region with file data via kernel_read(). The zero-fill is pure overhead: ksmbd_vfs_read() returns the number of bytes actually read ('nbytes'), and only those nbytes are ever consumed - they are pinned into the response iov (ksmbd_iov_pin_rsp_read()), sent over the RDMA channel (smb2_read_rdma_channel()), or copied by the compression path (ksmbd_compress_response() uses iov_len == nbytes). The ALIGN(length, 8) tail padding and any short-read remainder are never read or transmitted, so they need not be initialized. Use kvmalloc() instead to skip the redundant zeroing. This reduces CPU and memory-bandwidth usage on large sequential reads. Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-06-30ksmbd: validate num_subauth when copying ACE in set_ntacl_daclHaofeng Li
set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl(). Signed-off-by: Haofeng Li <lihaofeng@kylinos.cn> Reviewed-by: ChenXiaoSong <chenxiaosong@kylinos.cn> Suggested-by: Namjae Jeon <linkinjeon@kernel.org> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-06-30ksmbd: reject undersized DACLs before parsing ACEsHaofeng Li
parse_dacl() limits the attacker-controlled ACE count by comparing it with the number of minimal ACEs that fit in the DACL size. The DACL size field is 16 bits, but the expression subtracts sizeof(struct smb_acl). Because sizeof() is unsigned, a DACL size smaller than the ACL header underflows to a large size_t. A malicious client can reach this with: SMB2_SET_INFO (InfoType=SMB2_O_INFO_SECURITY) -> smb2_set_info_sec() -> set_info_sec() -> parse_sec_desc() -> parse_dacl() -> init_acl_state(..., 0xffff) -> init_acl_state(..., 0xffff) -> kmalloc_objs(..., 0xffff) Thus a malformed security descriptor can make num_aces pass the guard and drive large temporary ACL state and pointer-array allocations. Reject DACLs smaller than struct smb_acl before doing the subtraction, so the ACE count check cannot be bypassed by the underflow. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Haofeng Li <lihaofeng@kylinos.cn> Reviewed-by: ChenXiaoSong <chenxiaosong@kylinos.cn> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-06-30ksmbd: fix n.data memory leak in ksmbd_vfs_set_dos_attrib_xattrQiang Liu
Free ndr buffer data when ndr_encode_dos_attr() returns error to avoid memory leak. Signed-off-by: Qiang Liu <liuqiang@kylinos.cn> Reviewed-by: ChenXiaoSong <chenxiaosong@kylinos.cn> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-06-30ksmbd: Fix acl.sd_buf memory leak and invalid sd_size error handlingQiang Liu
1. When ndr_decode_v4_ntacl() fails, the code jumped to free_n_data which only freed n.data, skipping kfree(acl.sd_buf) and leaking the buffer. Zero-initialize struct xattr_ntacl acl, reorder error labels to out_free to release acl.sd_buf on all error paths. 2. if (acl.sd_size < sizeof(struct smb_ntsd)) is true, original code returned success without freeing sd_buf and left stale *pntsd. Set rc = -EINVAL before jumping to out_free to return error code and free buffer. Signed-off-by: Qiang Liu <liuqiang@kylinos.cn> Reviewed-by: ChenXiaoSong <chenxiaosong@kylinos.cn> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-06-30ksmbd: fix sd_ndr.data memory leak in ksmbd_vfs_set_sd_xattrQiang Liu
ndr_encode_v4_ntacl() allocates sd_ndr.data via kzalloc() at entry. If any subsequent ndr_write_*() call returns error during encoding, the allocated sd_ndr.data won't be freed and causes memory leak. Move kfree(sd_ndr.data) into out label to ensure the buffer gets released on all success and error return paths. Signed-off-by: Qiang Liu <liuqiang@kylinos.cn> Reviewed-by: ChenXiaoSong <chenxiaosong@kylinos.cn> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-06-30net/sched: act_bpf: use rcu_dereference_bh() to read the filterSechang Lim
tcf_bpf_act() can run from the tc egress path, which holds only rcu_read_lock_bh(), but reads prog->filter with rcu_dereference() and trips lockdep: WARNING: suspicious RCU usage net/sched/act_bpf.c:47 suspicious rcu_dereference_check() usage! 1 lock held by syz.2.1588/12756: #0: (rcu_read_lock_bh){....}-{1:3}, at: __dev_queue_xmit net/core/dev.c:4792 tcf_bpf_act+0x6ae/0x940 net/sched/act_bpf.c:47 tcf_classify+0x6e4/0x1080 net/sched/cls_api.c:1860 sch_handle_egress net/core/dev.c:4545 [inline] __dev_queue_xmit+0x2185/0x2c00 net/core/dev.c:4808 packet_sendmsg+0x3dfa/0x5120 net/packet/af_packet.c:3114 The other tc actions and cls_bpf already use rcu_dereference_bh() here. Do the same. Fixes: 1f211a1b929c ("net, sched: add clsact qdisc") Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com> Reviewed-by: Amery Hung <ameryhung@gmail.com> Link: https://patch.msgid.link/20260629154112.1164986-1-rhkrqnwk98@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-01iio: light: al3320a: add missing REGMAP_I2C to KconfigJoshua Crofts
The Kconfig entry for the al3320a is missing a `select REGMAP_I2C`, causing build failures. Fixes: 1850e6ae7f91 ("iio: light: al3320a: Implement regmap support") Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by: David Heidelberg <david@ixit.cz> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2026-07-01iio: light: al3010: add missing REGMAP_I2C to KconfigJoshua Crofts
The KConfig entry for the AL3010 is missing a `select REGMAP_I2C`, causing build failures. Fixes: 0e5e21e23dd6 ("iio: light: al3010: Implement regmap support") Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by: David Heidelberg <david@ixit.cz> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2026-07-01iio: light: al3000a: add missing REGMAP_I2C to KconfigJoshua Crofts
The KConfig entry for the al3000a is missing a `select REGMAP_I2C`, causing build failures. Fixes: d531b9f78949 ("iio: light: Add support for AL3000a illuminance sensor") Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by: David Heidelberg <david@ixit.cz> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2026-06-30riscv: probes: save original sp in rethook trampolineMartin Kaiser
Reading a word from the stack in a kretprobe crashes a risc-v kernel. $ cd /sys/kernel/tracing/ $ echo 'r n_tty_write $stack0' > dynamic_events $ echo 1 > events/kprobes/enable Unable to handle kernel paging request at virtual address 0000000200000128 ... [<ffffffff80016d16>] regs_get_kernel_stack_nth+0x26/0x38 [<ffffffff80177196>] process_fetch_insn+0x3ee/0x760 [<ffffffff80177836>] kretprobe_trace_func+0x116/0x1f0 [<ffffffff8017795a>] kretprobe_dispatcher+0x4a/0x58 [<ffffffff8013572e>] kretprobe_rethook_handler+0x5e/0x90 [<ffffffff80180838>] rethook_trampoline_handler+0x70/0x108 [<ffffffff8001ba32>] arch_rethook_trampoline_callback+0x12/0x1c [<ffffffff8001ba84>] arch_rethook_trampoline+0x48/0x94 [<ffffffff8067872a>] tty_write+0x1a/0x30 In regs_get_kernel_stack_nth, regs->sp contains an arbitrary value. arch_rethook_trampoline saves the registers from the probed function in a struct pt_regs. sp is not saved. Instead, sp is decremented for arch_rethook_trampoline's local stack. Fix this crash and save the original sp along with the other registers. Use a0 as a temporary register, it is overwritten anyway. Cc: stable@vger.kernel.org Fixes: c22b0bcb1dd02 ("riscv: Add kprobes supported") Signed-off-by: Martin Kaiser <martin@kaiser.cx> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Link: https://patch.msgid.link/20260630194010.1824039-1-martin@kaiser.cx [pjw@kernel.org: added Fixes tag; cc'ed stable] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-06-30selftests: drv-net: tso: don't touch dangerous feature bitsJakub Kicinski
query_nic_features() detects which offloads depend on tx-gso-partial by enabling everything, turning tx-gso-partial off, and seeing which active features drop out. Enabling all hw features is dangerous: we may end up enabling rx-fcs and loopback for example. For the ice driver we end up getting into problems with feature dependencies so the cleanup isn't successful either, and the test exits with rx-fcs and loopback enabled. Scope the feature probing just to segmentation bits. Fixes: 266b835e5e84 ("selftests: drv-net: tso: enable test cases based on hw_features") Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20260629233923.2151144-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-30cxgb4: Fix decode strings dump for T6 adaptersGleb Markov
Depending on the value of chip_version, the correct decode set is selected. However, the subsequent matching with the t4 encoding type in the if-else block results in a reassignment, which leads to the loss of support for t6_decode as well as reinitializing of values t4_decode and t5_decode. The component history shows that the if-else block previously used for this purpose, as well as the execution order, was not affected by the change. Furthermore, it is suggested by the execution order that the scenario with overwriting and loss of support will be implemented. Delete the if-else block. Fixes: 6df397539cb0 ("cxgb4: Update correct encoding of SGE Ingress DMA States for T6 adapter") Signed-off-by: Gleb Markov <markov.gi@npc-ksb.ru> Reviewed-by: Potnuri Bharat Teja <bharat@chelsio.com> Link: https://patch.msgid.link/20260629130856.1168-1-markov.gi@npc-ksb.ru Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-30virtio_net: disable cb when NAPI is busy-polledLongjun Tang
When busy-poll is active, napi_schedule_prep() returns false in virtqueue_napi_schedule(), so virtqueue_disable_cb() is skipped. The device may keep firing irqs until reaches virtqueue_napi_complete(). Under load (received == budget), it will lead to a large number of spurious interrupts. Fix it by disabling the callback at the virtnet_poll() entry. This keeps the callback off while we poll and it is re-enabled by virtqueue_napi_complete() when going idle. Fixes: ceef438d613f ("virtio_net: remove custom busy_poll") Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Longjun Tang <tanglongjun@kylinos.cn> Link: https://patch.msgid.link/20260629024230.37325-1-lange_tang@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-30sctp: fix addr_wq_timer race in sctp_free_addr_wq()Xin Long
sctp_free_addr_wq() previously removed addr_wq_timer using timer_delete() while holding addr_wq_lock. However, timer_delete() does not guarantee that a currently running timer handler has completed. This allows a race with sctp_addr_wq_timeout_handler(), where the handler may still run after addr_waitq has been freed, acquire addr_wq_lock, and access freed memory, leading to a use-after-free. Fix this by calling timer_shutdown_sync() before taking addr_wq_lock. This guarantees that any in-flight timer handler has finished and prevents the timer from being re-armed during teardown, making subsequent cleanup safe. Fixes: 4db67e808640 ("sctp: Make the address lists per network namespace") Reported-by: Sashiko <sashiko-bot@kernel.org> Signed-off-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/5dc95f295bdb5c3f60e880dd9aa5112dc5c071cc.1782757874.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-30selftests: net: bump default cmd() timeout to 20 secondsJakub Kicinski
We always used 5 sec as the default command timeout. But soon after it was introduced, David effectively made us ignore the timeout (it was passed to process.communicate() as the wrong argument). Gal recently fixed that, but turns out the 5 sec is not enough for a lot of tests and setups. The fix caused regressions. In particular running reconfig commands (e.g. XDP attach) on mlx5 with 32 rings and 9k MTU, on a heavily-debug-enabled kernel takes more than 5 sec. The XDP installation command will time out after 5 sec but since the sleeps in the kernel are non interruptible the command finishes anyway, leaving the XDP program attached, but with non-zero exit code. defer()ed cleanups are not installed, breaking the environment for subsequent tests. Since "install XDP" is a pretty normal command a "point fix" does not seem appropriate. 32 rings is a fairly reasonable config, too, so we should just increase the timeout to 20 sec. There's no real reason behind the value of 20. Fixes: 1cf270424218 ("net: selftest: add test for netdev netlink queue-get API") Fixes: f0bd19316663 ("selftests: net: fix timeout passed as positional argument to communicate()") Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Acked-by: Breno Leitao <leitao@debian.org> Reviewed-by: Nimrod Oren <noren@nvidia.com> Link: https://patch.msgid.link/20260629233348.2145841-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-01bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()Breno Leitao
xbc_snprint_cmdline() is meant to be called twice: first with buf=NULL, size=0 to probe the rendered length, then with a real buffer to fill it (the standard snprintf() two-pass pattern). The probe call makes the function compute "buf + size" (NULL + 0) and, on every iteration, advance "buf += ret" from that NULL base and pass the result back into snprintf(). Pointer arithmetic on a NULL pointer is undefined behavior. It is harmless in the in-kernel callers today, but the follow-up patches run this same code in the userspace tools/bootconfig parser at kernel build time, where host UBSan / FORTIFY_SOURCE abort the build. Track a running written length (size_t) instead of mutating @buf, and only form "buf + len" when @buf is non-NULL. snprintf(NULL, 0, ...) is itself well defined and returns the would-be length, so the two-pass "probe then fill" usage returns identical byte counts. Link: https://lore.kernel.org/all/20260626-bootconfig_using_tools-v7-1-24ab72139c29@debian.org/ Fixes: 51887d03aca1 ("bootconfig: init: Allow admin to use bootconfig for kernel command line") Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-06-30vfio: selftests: Add luuid to libvfio.mk's list of libraries, not to the ↵Sean Christopherson
Makefile Link to the uuid library as part of libvfio.mk instead of as only linking it via VFIO selftests' Makefile, as the whole point of providing libvfio.mk is to allow linking the VFIO library functionality into KVM selftests, without KVM selftests having to know the gory details or duplicate code. Cc: Raghavendra Rao Ananta <rananta@google.com> Cc: David Matlack <dmatlack@google.com> Cc: Vipin Sharma <vipinsh@google.com> Cc: Alex Williamson <alex@shazbot.org> Fixes: e65f1bf8a2db ("vfio: selftests: Extend container/iommufd setup for passing vf_token") Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: David Matlack <dmatlack@google.com> Link: https://lore.kernel.org/r/20260630212805.474418-1-seanjc@google.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-06-30audit: Fix data races of skb_queue_len() readers on audit_queueChi Wang
Multiple readers access audit_queue.qlen via skb_queue_len() without holding the queue lock or using READ_ONCE(), while kauditd writes to this field via the skb_dequeue() → __skb_unlink() path with WRITE_ONCE() protected by a spinlock. This constitutes data races. All affected skb_queue_len(&audit_queue) call sites: - kauditd_thread() wait_event_freezable() condition - audit_receive_msg() AUDIT_GET handler (s.backlog assignment) - audit_receive() backlog check - audit_log_start() backlog check and pr_warn() KCSAN reports the following conflicting access pattern (one example): ================================================================== BUG: KCSAN: data-race in audit_log_start / skb_dequeue write (marked) to 0xffffffff8512ee20 of 4 bytes by task 661 on cpu 57: skb_dequeue+0x70/0xf0 kauditd_send_queue+0x71/0x220 kauditd_thread+0x1cb/0x430 kthread+0x1c2/0x210 ret_from_fork+0x162/0x1a0 ret_from_fork_asm+0x1a/0x30 read to 0xffffffff8512ee20 of 4 bytes by task 36586 on cpu 1: audit_log_start+0x2a0/0x6b0 audit_core_dumps+0x64/0xa0 do_coredump+0x14b/0x1260 get_signal+0xeb2/0xf70 arch_do_signal_or_restart+0x41/0x170 exit_to_user_mode_loop+0xa2/0x1c0 do_syscall_64+0x1a3/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0xe0 value changed: 0x00000001 -> 0x00000000 ================================================================== Resolve the race by switching to lockless helper skb_queue_len_lockless(), which internally uses READ_ONCE() and properly pairs with the WRITE_ONCE() write accesses already present on the writer side. Cc: stable@vger.kernel.org Fixes: 3197542482df ("audit: rework audit_log_start()") Signed-off-by: Chi Wang <wangchi@kylinos.cn> Reviewed-by: Ricardo Robaina <rrobaina@redhat.com> [PM: line length tweak] Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-06-30spi: rzv2h-rspi: Fix DMA transfer error handling for signal interruptionFelix Gu
wait_event_interruptible_timeout() can return a negative error code when interrupted by a signal. The original code treated all non-zero return values as success, which would incorrectly synchronize DMA channels and return 0 instead of propagating the interruption error. Fixes: fa08b566860b ("spi: rzv2h-rspi: add support for DMA mode") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Reviewed-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com> Tested-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://patch.msgid.link/20260627-rspi-v1-1-170c93ee14da@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-30ASoC: amd: yc: Add Alienware m15 R7 AMD to DMIC quirk tableJetha Chan
The Alienware m15 R7 AMD exposes an ACP6x DMIC path, but its DMI product name is not present in the Yellow Carp ACP quirk table. As a result, the ACP machine driver does not enable the DMIC card on this system. Add the DMI product name for this machine. With this quirk applied, the kernel reports: acp_yc_mach acp_yc_mach.0: Enabling ACP DMIC support via DMI and ALSA exposes the ACP DMIC capture device: card 3: acp6x device 0: DMIC capture dmic-hifi-0 Tested on an Alienware m15 R7 AMD with product SKU 0B59. Link: https://jethachan.net/dev/2026/03/21/fixing-internal-microphone-alienware-linux.html Assisted-by: OpenAI-Codex:gpt-5.5 Signed-off-by: Jetha Chan <jethachan@gmail.com> Link: https://patch.msgid.link/20260630003328.15675-1-jethachan@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-30spi: dt-bindings: snps,dw-apb-ssi: add 'power-domains' propertyWolfram Sang
This SPI controller likely belongs to a power domain for all the SoCs listed. For sure, it belongs to one on the Renesas RZ/N1 SoC, so enable the property to be able to describe its power domain in DTs. Suggested-by: Herve Codina <herve.codina@bootlin.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Herve Codina <herve.codina@bootlin.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260626180326.9593-3-wsa+renesas@sang-engineering.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-30spi: dt-bindings: snps,dw-apb-ssi: drop superfluous RZ/N1 entryWolfram Sang
Commit 164c05f03ffa ("spi: Convert DW SPI binding to DT schema") added an RZ/N1 entry which was not in the original txt-file. It doesn't follow the usual "<soc entry>, <soc family entry>" style for Renesas SoCs which was properly added later with commit 029d32a892a8 ("spi: dw-apb-ssi: Integrate Renesas RZ/N1 SPI controller"). In that commit, removing the bogus entry was overlooked and is finally done now. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260626180326.9593-2-wsa+renesas@sang-engineering.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-30irqchip/ts4800: Fix missing chained handler cleanup on removeQingshuang Fu
The driver installs a chained handler for the parent interrupt during probe using irq_set_chained_handler_and_data(), but the remove function does not clear this handler. This leaves a dangling handler that may be called when the parent interrupt fires after the driver has been removed, potentially accessing freed memory and causing a kernel crash. Additionally, the parent_irq obtained via irq_of_parse_and_map() is not stored, making it inaccessible in the remove function. Moreover, interrupt mappings created during probe are not properly disposed. Fix this by: - Saving parent_irq in probe - Clearing the chained handler with NULL in ts4800_ic_remove() - Disposing all IRQ mappings before domain removal to prevent resource leaks Fixes: d01f8633d52e ("irqchip/ts4800: Add TS-4800 interrupt controller") Signed-off-by: Qingshuang Fu <fuqingshuang@kylinos.cn> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260623015211.109382-1-fffsqian@163.com
2026-06-30irqchip/gic-v3-its: Fix OF node reference leakYuho Choi
of_get_cpu_node() returns a referenced device node. In its_cpu_init_collection(), the Cavium 23144 workaround only uses the node to compare the CPU NUMA node, but the reference is never dropped. Use the device_node cleanup helper for the CPU node reference so it is released when leaving the workaround block, including the NUMA mismatch return path. Fixes: fbf8f40e1658 ("irqchip/gicv3-its: numa: Enable workaround for Cavium thunderx erratum 23144") Signed-off-by: Yuho Choi <dbgh9129@gmail.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev> Acked-by: Marc Zyngier <maz@kernel.org>
2026-06-30irqchip/irq-riscv-imsic-early: Fix fwnode leak on state setup failureHaoxiang Li
imsic_early_acpi_init() allocates a firmware node before setting up the IMSIC state. If imsic_setup_state() fails, the function returns without freeing the allocated fwnode. Free the fwnode and clear the global pointer on this error path, matching the cleanup already done when imsic_early_probe() fails. [ tglx: Use a common cleanup path instead of copying code around ] Fixes: fbe826b1c106 ("irqchip/riscv-imsic: Add ACPI support") Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260623073744.2009137-1-haoxiang_li2024@163.com
2026-06-30tracing/probes: Make the $ prefix mandatory for comm accessMasami Hiramatsu (Google)
Since $comm or $COMM are not event field but special fetcharg variables to access current->comm, It should not be accessed without '$' prefix even with typecast. Link: https://lore.kernel.org/all/178231209724.732967.12049805699091810641.stgit@devnote2/ Fixes: 69efd863a785 ("tracing/eprobes: Allow use of BTF names to dereference pointers") Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-06-30tracing/fprobe: Fix NULL pointer dereference in fprobe_fgraph_entry()Sechang Lim
fprobe_fgraph_entry() sizes a shadow-stack reservation in one walk of the per-ip fprobe list and fills it in a second walk, both under rcu_read_lock() only. A fprobe registered on an already-live ip can become visible between the two walks, so the fill walk processes an exit_handler the sizing walk did not count and used runs past reserved_words. If the sizing walk counted nothing, fgraph_data is NULL and the first write_fprobe_header() faults: Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:fprobe_fgraph_entry+0xa38/0xf10 kernel/trace/fprobe.c:167 Call Trace: <TASK> function_graph_enter_regs+0x44c/0xa10 kernel/trace/fgraph.c:677 ftrace_graph_func+0xc5/0x140 arch/x86/kernel/ftrace.c:671 __kernel_text_address+0x9/0x40 kernel/extable.c:78 arch_stack_walk+0x117/0x170 arch/x86/kernel/stacktrace.c:26 kmem_cache_free+0x188/0x580 mm/slub.c:6378 tcp_data_queue+0x18d/0x6550 net/ipv4/tcp_input.c:5590 [...] </TASK> The list cannot be frozen across the two walks, so skip a node that does not fit the reservation and count it as missed. Link: https://lore.kernel.org/all/20260619184425.3824774-1-rhkrqnwk98@gmail.com/ Fixes: 4346ba160409 ("fprobe: Rewrite fprobe on function-graph tracer") Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-06-30tracing/probes: Fix double addition of offset for @+FOFFSETMasami Hiramatsu (Google)
Since commit 533059281ee5 ("tracing: probeevent: Introduce new argument fetching code") wrongly use @offset local variable during the parsing, the offset value is added twice when dereferencing. Reset the @offset after setting it in FETCH_OP_FOFFS. Link: https://lore.kernel.org/all/178217905962.643090.1978577464942171332.stgit@devnote2/ Fixes: 533059281ee5 ("tracing: probeevent: Introduce new argument fetching code") Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Cc: stable@vger.kernel.org
2026-06-30tracing: eprobe: read the complete FILTER_PTR_STRING pointerMartin Kaiser
For a char * element in an event, the FILTER_PTR_STRING filter type is used. When the event occurs, a pointer is stored in the ringbuffer. If an eprobe references such a char * element of a "base event", the stored pointer is truncated when it's read from the ringbuffer. $ cd /sys/kernel/tracing $ echo 'e rcu.rcu_utilization $s:x64 $s:string' > dynamic_events $ echo 1 > tracing_on $ echo 1 > events/eprobes/enable $ sleep 1 $ echo 0 > events/eprobes/enable $ cat trace <idle>-0 ...: (rcu.rcu_utilization) arg1=0x4f arg2=(fault) <idle>-0 ...: (rcu.rcu_utilization) arg1=0x2 arg2=(fault) The problem is in get_event_field val = (unsigned long)(*(char *)addr); addr points to the position in the ringbuffer where the pointer was stored. The assignment reads only the lowest byte of the pointer. Fix the cast to read the whole pointer. The output of the test above is now <idle>-0 ... arg1=0xffffffff81c7d3f3 arg2="Start scheduler-tick" <idle>-0 ... arg1=0xffffffff81c57340 arg2="End scheduler-tick" Link: https://lore.kernel.org/all/20260620145339.3234726-1-martin@kaiser.cx/ Fixes: f04dec93466a ("tracing/eprobes: Fix reading of string fields") Signed-off-by: Martin Kaiser <martin@kaiser.cx> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>