aboutsummaryrefslogtreecommitdiffstatshomepage
AgeCommit message (Collapse)AuthorFilesLines
2026-09-12bpf: Allow terminal gotox instructionsSiddharth Chintamaneni1-1/+4
check_subprogs() treats gotox as a direct jump and validates its reserved zero offset. When gotox is the final instruction, this produces a synthetic successor one instruction past the end of the subprogram and rejects an otherwise valid program. Skip direct-offset validation for gotox and accept it as a non-fallthrough terminal instruction. Its actual targets remain validated from the instruction-array jump table during CFG construction. Fixes: 493d9e0d6083 ("bpf, x86: add support for indirect jumps") Signed-off-by: Siddharth Chintamaneni <sidchintamaneni@gmail.com> Reviewed-by: Anton Protopopov <a.s.protopopov@gmail.com> Link: https://lore.kernel.org/r/20260902171414.96165-1-sidchintamaneni@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-12drm/msm/a6xx+: Increase GMU FW init timeoutRob Clark1-1/+1
We were using 10ms, kgsl uses 100ms. In practice it is usually takes less than 10ms, but very occasionally goes a bit above 10ms, leading to a "GMU firmware inialization timed out", from which point things go south. There are probably some things that could be done to speed up init, like increasing GMU freq. But to be safe, increase the timeout to match kgsl. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/753014/ Message-ID: <20260912150915.28700-1-robin.clark@oss.qualcomm.com>
2026-09-12Merge tag 'xfs-fixes-7.3-rc3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds59-287/+715
Pull xfs fixes from Carlos Maiolino: "More than the usual amount of fixes. The highlights here are a block under reservation fix which caused an assert to be triggered in non-default configurations. The assert, initially added on 7.3-rc2 just makes the problem explicit but is not the cause. Another highlight is a missed lock/unlock mutex in the xfs healthmonitor which was causing lockdeps warnings. Besides those two, this also contains a myriad of fixes for random bugs found by LLM tools in the healthmon, scrub and online repair. A few bug fixes for zoned xfs are also included. This also includes an accounting fix for our buffer slab cache where the memory payload associated to each object was not being properly accounted for. The remaining of the patches are a few lock context annotations added and/or fixed. They are mostly disabled by now, but still worth fixing before we get them enabled. And last but not least, a few clean ups" * tag 'xfs-fixes-7.3-rc3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: (75 commits) xfs: advance the findparent inode scan cursor while holding ILOCK xfs: reset parent pointer args before each dir tree unlink repair xfs: fix replaying dirent removals into the temporary directory xfs: fix termination logic in xchk_bmap xfs: fix rtrmap cross-referencing elision logic xfs: actually check internal-rtdev fields in the superblock xfs: fix under-reservation of blocks when repairing sf directories xfs: take hm->lock in xfs_ioc_health_monitor() before insert xfs: set IOMAP_F_INTEGRITY for zoned writes on integrity devices xfs: avoid extra cache flushes for multi-device file systems in xfs_fsync xfs: don't continue on error in xfs_fsync xfs: also flush the RT device cache in xlog_write_iclog xfs: bail out on bitmap errors in xrep_agfl_fill xfs: snapshot old AGFL before rewriting it xfs: remove redundant function declaration xfs: report runtime failures in scrub xfs: report healthy filesystem events in scrub stats xfs: snapshot scrub stats when rendering them xfs: remove several unused and never-implemented declarations xfs: count escaped corruption errors in scrub stats ...
2026-09-12Merge tag 'for-7.3-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linuxLinus Torvalds3-7/+56
Pull btrfs fixes from David Sterba: - tree-checker updates, validate values in b-tree item keys, other item length checks - don't do unnecessary transaction commit fallback when logging parent directories - in zoned mode, initialize space info of a block group early enough so it does not lead to NULL pointer dereference * tag 'for-7.3-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: tree-checker: validate name length for extref items btrfs: tree-checker: validate parent field for inode extref items btrfs: tree-checker: validate key offset for inode ref keys btrfs: fix unnecessary transaction commit fallback from btrfs_log_all_parents() btrfs: set space_info before adding new free space in btrfs_make_block_group()
2026-09-12Merge tag 'erofs-for-7.3-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofsLinus Torvalds8-73/+39
Pull erofs updates from Gao Xiang: "The most impactful fix here is to disable LZ4 rolling decompression for now. AWS folks recently found their systems could get corrupted data with some rare, specific LZ4 datasets, and after a deeper analysis, I found the root cause is that there could be uncontrolled backward memory copies in the current LZ4 implementation and it breaks the assumption of the rolling decompression optimization, since the kernel LZ4 codebase is out of our control and it needs more time to plan how to do next, so disable LZ4 rolling decompression for now to ensure data correctness for real production on these rare cases first. The technical details also see the corresponding commit. Other changes are random minor fixes. Summary: - Disable LZ4 rolling decompression for now due to the uncontrolled LZ4 implementation - Fix missing sysfs feature entry for xattr prefixes - Fix invalid LZMA decoders on resize failure - Rearrange the inode_share cache key to avoid potential collisions - Fix erofs_bread() when fsoffset is used on sub-page-block EROFS filesystems" * tag 'erofs-for-7.3-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs: erofs: add missing buf->off in erofs_bread() erofs: delimit inode_share cache key components erofs: disable LZ4 rolling decompression for now erofs: preserve LZMA decoders on resize failure erofs: add sysfs feature entry for xattr prefixes
2026-09-12Merge tag 'fbdev-for-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdevLinus Torvalds6-10/+32
Pull fbdev fixes from Helge Deller: "Two patches for VT core code and fbcon prevent potential out-of-bounds reads on font or screen size changes, one fix limits the Superblitter in atafb to supported modes only, and some minor fixes for vfb, ssd1307fb and omapfb" * tag 'fbdev-for-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev: fbdev: vfb: defer cleanup until the last reference fbdev: atafb: Restrict SuperBlitter to supported formats fbdev: ssd1307fb: fix NULL pointer dereference on missing match data fbcon: Fix KASAN slab-out-of-bounds Read in fbcon_prepare_logo fbdev: omapfb: Fix __be32 sparse warning in panel_enabled() vt: hide cursor prior to font changes to avoid out-of-bound reads
2026-09-12Merge tag 'iommu-fixes-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linuxLinus Torvalds11-88/+93
Pull IOMMU fixes from Joerg Roedel: "RISC-V: - Serialize command queue publication to prevent concurrent producers from exposing incomplete or out-of-order commands to hardware - Wait for queue space outside the command queue lock - Avoid waiting for IOFENCE completion when command enqueue failed AMD: - Prevent GA log buffers from being reallocated and leaked during resume, where allocation also occurs in an unsuitable syscore callback context - Fix a regression on older systems whose firmware advertises incorrect IOMMU features - Preserve allocation errors when assigning host domain IDs to nested domains s390: - Prevent a NULL dereference when translating an unmapped IOVA with five-level ZPCI translation tables Misc: - Remove a stale MAINTAINERS entry and clean up unused or redundant AMD IOMMU declarations, macros, and checks" * tag 'iommu-fixes-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux: iommu/amd: Remove unused macro iommu/amd: Remove redundant checks from interrupt handler path iommu/amd: Remove redundant check in irq_remapping_select() iommu/amd: Make iommu_sva_set_dev_pasid as static MAINTAINERS: Drop the nonexistent vsi-iommu.h file entry iommu/amd: Fix ineffective error check in nested domain allocation iommu/amd: Fix premature break in init_iommu_one() again iommu/amd: Do not reallocate GA log buffers on resume iommu/s390: Fix NULL dereference in iova_to_phys() with ZPCI_TABLE_TYPE_RFX iommu/riscv: Avoid waiting on failed command enqueue iommu/riscv: Serialize command queue publishing iommu/riscv: Add command queue lock
2026-09-12Merge tag 'powerpc-7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds9-15/+38
Pull powerpc fixes from Madhavan Srinivasan: - powerpc/entry: Fix double accounting of user time on interrupt entry - Fix leak in htmdump_init_debugfs - KVM: PPC: Book3S HV: Set irqfd->producer only on success - powerpc/kexec_file: print configured kernel command line - Remove redundant early_init_dt_scan_root() call - misc fixes and cleanup Thanks to Aboorva Devarajan, Amit Machhiwal, Athira Rajeev, Christophe Leroy, Christophe Leroy (CS GROUP), Kunwu Chan, leixiang, longlong yan, Michail Tatas, Mukesh Kumar Chaurasiya (IBM), Ritesh Harjani (IBM), Shivang Upadhyay, Sourabh Jain, Thibault Ferrante, Vaibhav Jain, and Venkat Rao Bagalkote * tag 'powerpc-7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/pasemi: Add a null pointer check to the pas_setup_mce_regs powerpc/prom: Remove redundant early_init_dt_scan_root() call selftests/powerpc: use MAP_FAILED instead of (void *)-1 in tm-signal-context-force-tm powerpc/kexec_file: print configured kernel command line KVM: PPC: Book3S HV: Set irqfd->producer only on success powerpc/pseries/htmdump: Fix leak in htmdump_init_debugfs selftests/powerpc/tm: Fix tcheck() reading uninitialised CR value selftests/powerpc/pmu/ebb: fix lost_exception_test hang with sched yield change powerpc/entry: Fix double accounting of user time on interrupt entry
2026-09-12drm/gud: fix out-of-bounds write in gud_plane_atomic_check()Sajal Gupta1-2/+2
The plane property loop uses req->properties[num_properties + i] as write index while simultaneously incrementing `num_properties` inside the loop. At iteration i, num_properties has also incremented by i, so the write is done at `initial_num_properties + 2*i`, skipping every other index and advancing by 2 per iteration. With just 2 connector and 32 plane properties the last write happens at index 64, one slot past the end of the 64-slot (indices 0–63) allocation. A USB device can trigger OOB by advertising the maximum number of properties. Fix by dropping the redundant `+ i`; num_properties is already the correct running index, as gud_connector_fill_properties() fills the preceding slots. Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://sashiko.dev/#/patchset/20260821071812.16500-1-sajal2005gupta%40gmail.com?part=1 Signed-off-by: Sajal Gupta <sajal2005gupta@gmail.com> Cc: <stable@vger.kernel.org> Acked-by: Ruben Wauters <rubenru09@aol.com> Signed-off-by: Ruben Wauters <rubenru09@aol.com> Link: https://patch.msgid.link/20260902123254.36987-1-sajal2005gupta@gmail.com
2026-09-12drm/gud: Ignore damage clips in full update modeSophie D1-0/+3
When running in full update mode, previously small updates (such as moving the mouse across the screen) would cause many full frames to be generated. This would bog down the bus and lower the effective framerate significantly - I was seeing a drop from 60 FPS to 2 FPS. Set ignore_damage_clips in full update mode so the damage iterator yields a single full-plane rectangle instead of one per clip. Fixes: 73cfd166e045 ("drm/gud: Replace simple display pipe with DRM atomic helpers") Cc: <stable@vger.kernel.org> # 6.18.x Signed-off-by: Sophie D <patches@scd31.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Ruben Wauters <rubenru09@aol.com> Signed-off-by: Ruben Wauters <rubenru09@aol.com> Link: https://patch.msgid.link/20260910014910.8564-1-patches@scd31.com
2026-09-12ALSA: bcd2000: Fix race between rawmidi and disconnectTakashi Iwai1-7/+26
Although we tried to fix the potential UAF issues at USB disconnect on bcd2000 driver, there is still an overlooked case -- namely, when a rawmidi trigger callback has been already running at USB disconnect handling, the in-flight function (e.g. bcd2000_midi_send()) could still access the URB, because the previous URB NULL-check & clearance was considered only for the URB complete callbacks, but not about the parallel rawmidi operations. For addressing the race, this patch introduced a new spinlock that covers each rawmidi operation as well as the rawmidi handling in the complete callback. The URB is cleared with the lock, so it guarantees that the pending rawmidi task already finished or a NULL check is effective. Fixes: 459d3a64766f ("ALSA: bcd2000: clear the URB pointers on disconnect") Link: https://patch.msgid.link/20260910155227.996210-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-09-12ALSA: hda/realtek: Add quirk for HP Victus 15-fa1xxx (MB 8BB1) mute LEDKrish Gulati1-0/+1
The mute LED on this board does not respond to mute state changes because no fixup is matched for SSID 103c:8bb1. The reporter verified the LED can be toggled manually via COEF index 0x0B. Reported-by: Mazen Ahmed <mazen001.ahmed001@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221982 Tested-by: Mazen Ahmed <mazen001.ahmed001@gmail.com> Signed-off-by: Krish Gulati <krishgulati7@gmail.com> Link: https://patch.msgid.link/20260912070618.21272-1-krishgulati7@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-09-129p: Fix v9fs_issue_write() to update i_size and remote_i_sizeDavid Howells1-1/+27
Fix v9fs_issue_write() to update i_size and remote_i_size to the new size of the server file if we made it larger, using the start fpos and the count returned by p9_client_write() to calculate the new minimum file size. This assumes that if the 9P server makes a short write (say it hits ENOSPC), a reduced count is returned. Fixes: 5fb70e7275a6 ("netfs, 9p: Implement helpers for new write code") Reported-by: Michael Mulqueen <mike@method-b.uk> Closes: https://lore.kernel.org/r/fbb9e395-1e07-4212-8f70-23f3cd498074@method-b.uk/ Cc: stable@vger.kernel.org Signed-off-by: David Howells <dhowells@redhat.com> Message-ID: <2226525.1789118704@warthog.procyon.org.uk> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-11Merge branch 'neighbour-small-fixes-for-rtm_-get-set-neightbl'Jakub Kicinski3-10/+30
Kuniyuki Iwashima says: ==================== neighbour: Small fixes for RTM_{GET,SET}NEIGHTBL. While working on the follow-up suggested here, https://lore.kernel.org/20260902143023.GA3966681@shredder I found a few bugs in RTM_GETNEIGHTBL and RTM_SETNEIGHTBL, which this series fixes. Patch 1, 3, 4 will conflict with net-next in neightbl_dump_info() due to removal of net_eq() below: p = list_next_entry(&tbl->parms, list); list_for_each_entry_from_rcu(p, &tbl->parms_list, list) { if (!net_eq(neigh_parms_net(p), net)) continue; Note also that currently neigh_proc_dointvec_ms_jiffies_positive() is buggy and does not enforce min/max, and it needs this fix: https://lore.kernel.org/20260905233819.1064529-2-kuniyu@google.com ==================== Link: https://patch.msgid.link/20260909233143.2401847-1-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-11neighbour: Skip default parms when resumed in neightbl_dump_info().Kuniyuki Iwashima1-3/+8
neightbl_dump_info() calls neightbl_fill_info() in each loop to render the default parms. If there are many devices and neightbl_fill_param_info() failed, neightbl_fill_info() is called again when the dump resumes: # ynl --family rt-neigh --dump getneightbl --output-json | jq '.[] | {name: .name, ifindex: .parms.ifindex}' ... { "name": "ndisc_cache", "ifindex": null } ... { "name": "ndisc_cache", "ifindex": 6 } { "name": "ndisc_cache", "ifindex": null } { "name": "ndisc_cache", "ifindex": 5 } Let's skip neightbl_fill_info() if it is already called in neightbl_dump_info(). Note that we cannot use !neigh_skip instead of !default_skip because default_skip == 1 && neigh_skip == 0 could be true if the first neightbl_fill_param_info() fails. Also, nidx must be cleared at the end of each table loop; otherwise, if neightbl_fill_info() for a subsequent table fails, the leftover nidx from the previous table would be saved in cb->args[1], resulting in erroneously skipping parms of the subsequent table in the next dump. Fixes: c7fb64db001f ("[NETLINK]: Neighbour table configuration and statistics via rtnetlink") Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260909233143.2401847-5-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-11neighbour: Don't render blackhole_netdev via RTM_GETNEIGHTBL.Kuniyuki Iwashima1-1/+1
The cited commits started to initialise blackhole_netdev with neigh_parms_alloc(). This is visible in init_net as the ifindex==0 entries via RTM_GETNEIGHTBL: # ynl --family rt-neigh --dump getneightbl --output-json \ | jq '.[] | select(.parms.ifindex == 0) | {name: .name, ifindex: .parms.ifindex}' { "name": "arp_cache", "ifindex": 0 } { "name": "ndisc_cache", "ifindex": 0 } For RTM_SETNEIGHTBL, ifindex being 0 means wildcard. Let's skip blackhole_netdev's parms in neightbl_dump_info(). Note that lookup_neigh_parms() does not need the same change because the default parms is always the first entry and matches with ifindex == 0. Fixes: e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev") Fixes: 22600596b675 ("ipv4: give an IPv4 dev to blackhole_netdev") Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260909233143.2401847-4-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-11neighbour: Enforce min/max to NDTPA_INTERVAL_PROBE_TIME_MS.Kuniyuki Iwashima3-5/+17
NDTPA_INTERVAL_PROBE_TIME_MS sets .type and .min but misses .validation_type, so no validation is applied: # ynl --family rt-neigh --do setneightbl \ --json '{"name": "arp_cache", "parms": {"interval-probe-time-ms": 0}}' # ynl --family rt-neigh --dump getneightbl --output-json | \ jq '.[] | select(.name == "arp_cache" and has("config")) | .parms["interval-probe-time-ms"]' 0 Moreover, nla_get_msecs() uses msecs_to_jiffies(), and u64 is silently cast to u32, so a larger value can bypass the min check: e.g. 4294967296 == 0x100000000 # ynl --family rt-neigh --do setneightbl \ --json '{"name": "arp_cache", "parms": {"interval-probe-time-ms": 4294967296}}' # ynl --family rt-neigh --dump getneightbl --output-json | \ jq '.[] | select(.name == "arp_cache" and has("config")) | .parms["interval-probe-time-ms"]' 0 msecs_to_jiffies() returns MAX_JIFFY_OFFSET if the value is larger than INT_MAX. Also, INT_MAX ms overflows int NEIGH_VAR() when HZ > 1000 (Alpha, MIPS), and passing a negative integer to queue_delayed_work(unsigned long delay) causes sign extension, which wraps around the expiry time to the past, resulting in it being handled as 0 delay in the timer wheel. Let's use NLA_POLICY_FULL_RANGE() and limit the max to 1 day. The same max check is applied to sysctl as well. Note that this controls the probe interval for NTF_MANAGED entries, so the max of 1 day is unlikely to break any deployments. Fixes: 211da42eaa45 ("net, neigh: introduce interval_probe_time_ms for periodic probe") Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260909233143.2401847-3-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-11neighbour: Add missing RCU annotation for neightbl_dump_info().Kuniyuki Iwashima1-2/+5
neightbl_dump_info() fetches the first non-default neigh_parms with list_next_entry(&tbl->parms, ...) and iterates through the list with list_for_each_entry_from_rcu(). However, list_next_entry() does not use RCU helper. Let's use list_for_each_entry_rcu() and skip the default parms. Fixes: 4ae34be50064 ("neighbour: Convert RTM_GETNEIGHTBL to RCU.") Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260909233143.2401847-2-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-11mailmap: update entry for Jens AxboeJens Axboe1-0/+1
I recently changed jobs, let's update the .mailmap entry so that patches are attributed to the right (current) company. Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-09-11Merge tag 'regulator-fix-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulatorLinus Torvalds2-42/+41
Pull regulator fixes from Mark Brown: "One fix for pf1550 which checked for errors on multiple regulators but always notified via one of them regardless of which one had the problem, plus one device ID addition in the fan53555 DT bindings" * tag 'regulator-fix-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: pf1550: fix which regulator is notified regulator: dt-bindings: fan53555: add tcs,tcs4526
2026-09-11Merge tag 'spi-fix-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spiLinus Torvalds1-0/+16
Pull spi fix from Mark Brown: "New device ID for v7.3: update the DesignWare DT binding to say how to describe the UltraRISC DP1000 instance of the controller" * tag 'spi-fix-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: dt-bindings: snps,dw-apb-ssi: Add compatible for UltraRISC DP1000 SoC
2026-09-12KEYS: encrypted: fix integer overflow of datablob_lenCen Zhang1-6/+14
encrypted_key_alloc() stores datablob_len in a u16. It is computed from multiple string and payload lengths. If the result exceeds U16_MAX, the assignment truncates the allocation size. KASAN reports a 32760-byte slab-out-of-bounds write when __ekey_init() copies the master key description into the undersized buffer. The total payload length stored in key->datalen is also a u16. Use check_add_overflow() to reject values that do not fit either destination, and use kzalloc_flex() for the flexible-array allocation. Fixes: 7e70cb497850 ("keys: add new key-type encrypted") Cc: stable@vger.kernel.org Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Cen Zhang <cenzhang@linux.microsoft.com> Signed-off-by: Francis Perron <francis@akrites.dev> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: R Nageswara Sastry <rnsastry@linux.ibm.com> Link: https://lore.kernel.org/r/20260909153433.83117-1-cenzhang@linux.microsoft.com Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2026-09-12KEYS: trusted: Fix tpm2_load_cmd() boundary checkJarkko Sakkinen1-5/+7
tpm2_load_cmd() does boundary checks against the ASN.1 size i.e., payload->blob_len. Address this by passing the decoded blob size to tpm2_load_cmd(), and use it for the boundary checks. Cc: stable@vger.kernel.org # v5.13+ Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs") Reported-by: co+6a581c4284f721d4@bugs.sh Closes: https://bugs.sh/b/6a581c4284f721d4/ Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Tested-by: Srish Srinivasan <ssrish@linux.ibm.com> Link: https://lore.kernel.org/r/20260901205809.2028454-1-jarkko@kernel.org Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2026-09-12keys: translate request_key_auth pid for the reading procfs instanceMaoyi Xie2-4/+10
request_key_auth_describe() prints rka->pid into /proc/keys as a raw pid_t in the initial pid namespace. A reader can open /proc/keys through a mount in another pid namespace. That reader sees a number with no meaning there. The number can even name an unrelated task. The line needs VIEW on the key. So the reader either shares the key owner's uid or possesses the key. The fix keeps a struct pid. Commit 4f82f45730c6 ("net ip6 flowlabel: Make owner a union of struct pid * and kuid_t") gave /proc/net/ip6_flowlabel the same storage. The print goes through pid_nr_ns(). It renders against the pid namespace of the procfs instance the line is read through. Commit ad08978ab41c ("ipv6/flowlabel: simplify pid namespace lookup") moved that print to the same anchor. Output through an initial namespace /proc does not change. The line shows 0 for a requestor with no number in that namespace. Translating at read time was the alternative. find_pid_ns() can resolve a recycled number. The line would then name a live task with no connection to the key. A stored struct pid gives 0 instead when the requestor has no number there. Link: https://lore.kernel.org/keyrings/20260809110202.2180410-1-maoyixie.tju@gmail.com/ Fixes: 78b7280cce23 ("KEYS: Improve /proc/keys") Cc: stable@vger.kernel.org # v5.10+ Assisted-by: Claude:claude-opus-5 codeql Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com> Link: https://lore.kernel.org/r/20260821095935.1864998-1-maoyixie.tju@gmail.com Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2026-09-12keys: fix lost wakeup when reaping a dead key typeKarl Mehltretter1-3/+1
clear_bit() is atomic with respect to the word it modifies, but it is an unordered operation: it implies no memory barrier on either side (Documentation/atomic_bitops.txt). key_garbage_collector() clears KEY_GC_REAPING_KEYTYPE with clear_bit() and calls wake_up_bit() after reaping a dead key type. wake_up_bit() uses a lockless waitqueue check and requires a full barrier after the clear. The existing smp_mb() is before clear_bit(), so nothing orders the clear against that check. The GC can see an empty waitqueue while unregister_key_type() still sees the bit set. The final wakeup is then lost, leaving module unload stuck in wait_on_bit(). Use clear_and_wake_up_bit(). Its clear_bit_unlock() has RELEASE semantics, so the completed GC work stays ordered before the clear, and its smp_mb__after_atomic() orders the clear before the waitqueue check. Fixes: 0c061b5707ab ("KEYS: Correctly destroy key payloads when their keytype is removed") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Link: https://lore.kernel.org/r/20260821025327.61488-1-kmehltretter@gmail.com Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2026-09-11debugfs: don't warn about uninitialized debugfs for an error parentMikhail Gavrilov1-3/+3
Since commit c3a280ff728a ("debugfs: warn if file creation failed due to uninitialized debugfs") every boot with CONFIG_REF_TRACKER=y and CONFIG_DEBUG_FS=y prints two errors before the root filesystem is mounted: debugfs: Unable to create file 'net_refcnt@(____ptrval____)', debugfs is not initialized yet debugfs: Unable to create file 'net_notrefcnt@(____ptrval____)', debugfs is not initialized yet Nothing is actually wrong. Both files show up under /sys/kernel/debug/ref_tracker/ once the system is up. The kernel is reporting an error for a condition the caller has already accounted for. net_ns_init() runs directly from start_kernel(), before any initcall, and calls ref_tracker_dir_init() for init_net's two trackers. debugfs_init() is a core_initcall, so debugfs cannot possibly be up at that point. That is by design: ref_tracker_dir_debugfs() is documented as safe to call again later, and net/core/net_namespace.c has a late_initcall() that re-registers both directories once debugfs exists. ref_tracker also states that intent to debugfs. ref_tracker_debug_dir is initialised to ERR_PTR(-ENOENT) and only gets a real dentry in a late_initcall, so the early call hands debugfs_create_file() a parent that is already an error. debugfs_start_creating() honours that and returns the parent error, but only after the new pr_err() has fired. Move the IS_ERR(parent) check above the debugfs_initialized() test. A caller passing an error parent is propagating an earlier failure, which is the pattern debugfs documents and which the warning is not aimed at. A caller passing a valid or NULL parent too early - the case the warning was added for - still gets it. One behaviour change: an early caller with an error parent now gets PTR_ERR(parent) back instead of -ENOENT. All callers of these interfaces are documented to ignore the return value. Fixes: c3a280ff728a ("debugfs: warn if file creation failed due to uninitialized debugfs") Link: https://lore.kernel.org/all/6d1dc775f7d5e754d734907514534054f682bac5.1781171918.git.yk@y-koj.net/ Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Tested-by: Yohei Kojima <yk@y-koj.net> Link: https://patch.msgid.link/20260903115135.63210-1-mikhail.v.gavrilov@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-09-11Merge tag 'drm-fixes-2026-09-12' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds38-115/+312
Pull drm fixes from Dave Airlie: "Weekly fixes pull, this seems relatively quiet for the new world, scattered fixes, mostly amdgpu leading the way, but lots of minor fixes in other drivers. drm_exec: - fix 0 object handling sched: - null ptr deref fix in kunit tests amdgpu: - Freesync fix - GPUVM fix - Debugfs fixes - HDMI fixes - IPS fix - GPU reset fix - RGB quantization fixes - SMU 13.0.x fixes xe: - runtime PM guard fix - cache flushing fix i915: - Fix a memleak on perf config query error path - Fix UHBR SST SDP splitting when sink doesn't support it bridge: - fix ti-sn65dsi83 error handling - tc358768: Enforce input bus flags via atomic_check ast: - fix blend mode property on cursor plane qxl: - fix blend mode property on primary/cursor planes virtio: - fix blend mode property on cursor plane vboxvideo: - fix blend mode property on planes rockchip: - fix endpoint name length - fix Kconfig issues ivpu: - limit firmware log prints to field size - validate buffer range in ivpu address translation - validate fw log buffers ethosu: - ensure SRAM sizing - ensure cmd stream formatting - drop IRQF_SHARED - fix open return value adp: - fix Kconfig logicvc: - fix Kconfig" * tag 'drm-fixes-2026-09-12' of https://gitlab.freedesktop.org/drm/kernel: (38 commits) drm/amd/pm: report energy accumulator for smu 13.0.0 drm/amd/pm: fix gpu metrics energy accumulator for smu 13.0.0/13.0.7 drm/amd/display: Rebuild InfoFrames on output color space changes drm/amd/display: Honor Broadcast RGB for BT.2020 RGB output drm/amd/display: Propagate HDMI RGB quantization selectability Revert "drm/amdgpu: debugfs: avoid extra EOLs in amdgpu_gem_info" drm/amdgpu: skip gfx switch_power_profile during GPU reset drm/amd/display: Fix HF-VSDB DSC bpc detection to be cumulative drm/amd/display: Exit IPS before connector detection on resume drm/amd/display: Shorten hdmi_frl_status_polling_workqueue dm/amdgpu: fix malformed link_settings debugfs output drm/amdgpu: skip the VMID 0 flush for VRAM drm/amd/display: Consult MCCS FreeSync cap only if requested & supported drm/i915: Fix memory leak in query_perf_config_list() drm/i915/dp: Gate UHBR SST SDP splitting on sink capability drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches drm/xe: Guard page-fault worker with runtime PM check drm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work() drm/bridge: tc358768: Enforce input bus flags via atomic_check drm/drm_exec: fix up contended obj when num_objects is 0 ...
2026-09-11Merge tag 'riscv-for-linus-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linuxLinus Torvalds18-74/+169
Pull RISC-V fixes from Paul Walmsley: "From a RISC-V point of view, there's one notable fix here, reverting an earlier bogus fix to the pointer masking code. Fortunately the practical impact appears to be small. - Revert a bad fix, likely LLM-generated, in the pointer masking code that confused the RISC-V hardware pointer masking implementation with the Linux kernel tagged address feature - Fix unexpected faults caused by kprobe instruction slot writes when !CONFIG_STRICT_MODULE_RWX - Fix unexpected faults on minimal configurations during runtime code patching on !CONFIG_STRICT_MODULE_RWX systems - Fix a misplaced variable clear causing incorrect reuse of previous values in the RISC-V hardware feature probing code - Fix two bugs in the PMU SBI perf code on rv32: use BIT_ULL rather than BIT on 64-bit masks; and use a bitmap rather than an unsigned long on a quantity that can exceed 32 bits And a few miscellaneous cleanups: - Avoid a potential dereference-before-NULL-pointer-check bug in the PMU SBI perf driver - Use CONFIG_GENERIC_BUG_RELATIVE_POINTERS to simplify the rv32 bug table code (like x86 and PPC) - Report the RISC-V standard ISA extensions Z[v]fhmin when support is claimed for the superset RISC-V standard ISA extensions Z[v]fh; and simplify our FPU test code to only check for the presence of the D extension - Use an existing kernel string helper in place of some open-coded code in kernel/usercfi.c - Fix some yamllint issues in the RISC-V DT bindings for CPUs - Convert one use of __ASSEMBLY__ to __ASSEMBLER__ that snuck into the RISC-V CFI selftest code - Update the translation for the simplified Chinese translation of the RISC-V kernel patch acceptance policy" * tag 'riscv-for-linus-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: skip software algning code for HAVE_EFFICIENT_UNALIGNED_ACCESS kselftest/riscv: Replace __ASSEMBLY__ with __ASSEMBLER__ docs/zh_CN: Update arch/riscv/patch-acceptance.rst translation dt-bindings: riscv: cpus: Fix yamllint style issues riscv: hwprobe: simplify has_fpu() to check D extension only perf: RISC-V: check cpu_hw_evt before dereference in overflow IRQ riscv: report Zfhmin/Zvfhmin when Zfh/Zvfh are present perf: RISC-V: store available counter mask as bitmap perf: RISC-V: use BIT_ULL for u64 overflow masks riscv: bug: Make RV32 use GENERIC_BUG_RELATIVE_POINTERS riscv: hwprobe: initialize pair->value in hwprobe_one_pair() riscv: use string helper in setup_global_riscv_enable() Revert "riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set" riscv: patch: skip fixmap mapping when kernel text is already writable riscv: mm: make EXECMEM_KPROBES writable without CONFIG_STRICT_MODULE_RWX
2026-09-11Merge tag 'platform-drivers-x86-v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86Linus Torvalds7-40/+53
Pull x86 platform driver fixes from Ilpo Järvinen: - amd/pmf: Fix build on !CONFIG_AMD_PMF_DEBUG - asus-laptop: Fix ACPI event handling - hp-wmi: Fix board_params typo for 8DD6 board - x86-android-tablets: Fix Arizona and Crystal Cove GPIO lookups * tag 'platform-drivers-x86-v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: MAINTAINERS: fix sysfs-platform-ayaneo-ec documentation path platform/x86: x86-android-tablets: fix gpio_secondary_fwnode_init() not working platform/x86: x86-android-tablets: use shared battery swnode group on Yoga Tab 2 platform/x86: x86-android-tablets: drop redundant swnode group on YT3 platform/x86: x86-android-tablets: add Crystal Cove GPIO swnode support platform/x86: x86-android-tablets: pass node group to gpio_secondary_fwnode_init() platform/x86: x86-android-tablets: hold device reference for secondary fwnode teardown platform/x86: x86-android-tablets: fix Arizona GPIO swnode references platform/x86/amd/pmf: fix build on !CONFIG_AMD_PMF_DEBUG platform/x86: asus-laptop: Fix ACPI event handling platform/x86: hp-wmi: Fix board_params typo for 8DD6 board
2026-09-11Merge tag 'ata-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linuxLinus Torvalds1-37/+0
Pull ata fix from Niklas Cassel: - Drop documentation for no longer existing pata_legacy kernel parameters (Ethan) * tag 'ata-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux: ata: pata_legacy: remove documentation for removed module parameters
2026-09-11Merge tag 'block-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linuxLinus Torvalds5-3/+49
Pull block fixes from Jens Axboe: - Fix the start and length check added to iov_iter_extract_bvecs(), which used iter_iov_addr()/iter_iov_len() helpers that aren't safe for the ITER_BVEC/FOLIOQ/etc iterator types passed - sunvdc fixes for an -EIO issue from lack of retries, and unmapping LDC cookies when the descriptor send fails - Clear force_abort in ublk_queue_reset_io_flags() - ublk selftest install fix * tag 'block-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: selftests: ublk: add batch IO cases to recover_03 ublk: clear force_abort in ublk_queue_reset_io_flags() sunvdc: fix -EIO issue due to lack of retries sunvdc: unmap LDC cookies when the descriptor send fails block: Fix start and length check added to iov_iter_extract_bvecs() selftests: ublk: install test_common.sh and trace/ scripts
2026-09-11Merge tag 'io_uring-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linuxLinus Torvalds2-23/+60
Pull io_uring fixes from Jens Axboe: - Fix a deadlock in the write path with superblock freezing - Fix an issue where a provided buffer ring would overconsume when using MSG_TRUNC - Keep the CQE flags on iopoll requests when adding kbuf flags * tag 'io_uring-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: io_uring/rw: keep CQE flags on iopoll requests when adding kbuf flags io_uring/net: don't overconsume buffers when using MSG_TRUNC io_uring/net: let io_recv_buf_select return the length of the buffer region io_uring/rw: end write accounting from ->ki_complete
2026-09-11smb/client: send lease break ACKs thru correct session for multiuser mountsApril Cardenas1-2/+2
Currently, when cifs_oplock_break handles a break request from the server it searches for the appropriate tlink to handle the request but incorrectly uses the current fsuid as the search key, eventually causing read errors for users with multiuser mounts on NetApp. Fix this by using the tlink from the cfile struct instead to respond through the correct session. As breaks are handled in a worker thread, the current fsuid isn't guaranteed to match the session that the break is intended for. This means that cifs_sb_tlink may search the rbtree using the wrong fsuid, and return a tlink with an incorrect session than the lease break was intended for. As a result, the breaks may be ACKed through an incorrect session. While it seems that Samba/Windows Servers 2016-2025 ignore this as long as the lease key is correct, we ran into a case where if you're using NetApp ONTAP or Azure NetApp Files they will reject the ACK and return `STATUS_LOCK_NOT_GRANTED` errors on any future read requests a user may initiate through their still held open file handle, and the server will eventually close the file. In the dmesg logs, the user may see errors like these: CIFS: Status code returned 0xc0000128 STATUS_FILE_CLOSED CIFS: VFS: Send error in read = -9 With a multiuser mount using NetApp, this issue is really easy for users to hit on a wide variety of kernel versions by attempting to copy a file from the share to the local machine through GNOME Files/Nautilus. This copy will always result in Nautilus throwing a `Bad File Descriptor` error to the user and fail. With this fix, you can copy files through Nautilus without issue. >From looking at the traces, it seems that glib will open the file first, and call listxattr before actually attempting to copy the file data. The listxattr call always triggers a break, causing the copy to fail. The proposed fix returns to the way the client grabbed the tlink before commit e8f5f849ffce2 ("cifs: fix potential oops in cifs_oplock_break"). The bulk of that commit (checking for list empty) remains untouched, and I think the change to using cifs_sb_tlink was intended to avoid a NULL/ERR deference on the tlink as well as update the reference count. I believe this fix should preserve those safety properties, but of course I'd appreciate any corrections here. Fixes: e8f5f849ffce2 ("cifs: fix potential oops in cifs_oplock_break") Cc: stable@vger.kernel.org Signed-off-by: April Cardenas <april.cardenas@canonical.com> Reviewed-by: Namjae Jeon <linkinjeon@kernel.org> Reviewed-by: Bharath S M <bharathsm@microsoft.com> Signed-off-by: Paulo Alcantara <pc@manguebit.org>
2026-09-11KVM: Never clear KVM_REQ_VM_DEAD from a vCPU's requestsSean Christopherson5-6/+11
Use kvm_test_request() instead of kvm_check_request() when querying KVM_REQ_VM_DEAD, i.e. don't clear KVM_REQ_VM_DEAD, as the entire purpose of KVM_REQ_VM_DEAD is to prevent the vCPU from enterring the guest ever again, even if userspace insists on redoing KVM_RUN. Ensuring KVM_REQ_VM_DEAD is never cleared will allow relaxing KVM's rule that ioctls can't be invoked on dead VMs, to only disallow ioctls if the VM is bugged, i.e. if KVM hit a KVM_BUG_ON(). Opportunistically add compile-time assertions to guard against clearing KVM_REQ_VM_DEAD through the standard APIs. Reviewed-by: Kai Huang <kai.huang@intel.com> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260806214618.82180-1-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Use __GLIBC__, not _GNU_SOURCE, to detect actual glibcSean Christopherson1-3/+3
Use __GLIBC__ in the hardware disable test to detect when selftests are being built/linked against glibc and thus pthread_attr_setaffinity_np() is (hopefully) available. As pointed out by Sashiko and Hisam, _GNU_SOURCE is effectively a "request" macro to enable functionality, whereas __GLIBC__ is an announcement of support and selftests' idiomatic way of guarding code that's specific to glibc. Fixes: 496779b54943 ("KVM: selftests: Pre-set threads affinity in hardware disable test when possible") Reported-by: Sashiko Bot <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260731201140.5AF0C1F00AC4@smtp.kernel.org Suggested-by: Hisam Mehboob <hisamshar@gmail.com> Link: https://patch.msgid.link/20260826161430.714316-1-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: x86/pmu: Move Intel PMU global MSRs to intel_is_valid_msr()Jim Mattson2-8/+3
Commit c85cdc1cc1ea ("KVM: x86/pmu: Move handling PERF_GLOBAL_CTRL and friends to common x86") moved the existence check for the following Intel PMU MSRs to kvm_pmu_is_valid_msr(): - MSR_CORE_PERF_GLOBAL_STATUS - MSR_CORE_PERF_GLOBAL_CTRL - MSR_CORE_PERF_GLOBAL_OVF_CTRL That commit deemed these MSRs valid whenever pmu->version > 1. It intended to share the check with AMD PerfMonV2 because both vendor implementations require version 2 or greater for global PMU controls. However, as noted in the commit message, AMD uses different MSR indices for its global PMU registers. Commit 4a2771895ca6 ("KVM: x86/svm/pmu: Add AMD PerfMonV2 support") subsequently added AMD PerfMonV2 support and set pmu->version = 2. Because kvm_pmu_is_valid_msr() validated the Intel MSRs whenever pmu->version > 1, KVM incorrectly permitted AMD guests with PerfMonV2 to access these Intel MSRs without a #GP. Move the validation of these Intel MSRs to intel_is_valid_msr() and remove the common switch statement from kvm_pmu_is_valid_msr(). AMD already validates its own global PMU MSRs in amd_is_valid_msr(). Fixes: 4a2771895ca6 ("KVM: x86/svm/pmu: Add AMD PerfMonV2 support") Signed-off-by: Jim Mattson <jmattson@google.com> Reviewed-by: Like Xu <likexu@tencent.com> Reviewed-by: Sandipan Das <sandipan.das@amd.com> Link: https://patch.msgid.link/20260902184711.138538-1-jmattson@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11Merge tag 'slab-for-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/slabLinus Torvalds2-19/+24
Pull slab fixes from Vlastimil Babka: - Stable fix for an ABA issue causing slab list corruption introduced in 7.2 (Harry Yoo, with big thanks to Hyunwoo Kim for the thorough report and initial version of the fix) - Fix for 7.3 regression of kvfree_rcu() on PREEMPT_RT which can cause a deadlock from the set_cpus_allowed_force() caller (Vlastimil Babka) * tag 'slab-for-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/slab: mm/slab: take n->list_lock in __slab_try_return_freelist() to avoid race mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again
2026-09-11drm/msm/a6xx: Use CX AO Counter register for timestamp on a750 GPUsNeil Armstrong1-3/+9
The a750 uses the GMU CX AO Counters instead of the GMU_ALWAYS_ON_COUNTER register on A6xx and other A7xx GPUs, use it when running a A750 GPU. The GMU_ALWAYS_ON_COUNTER at offset 0x1f888 doesn't seem to exist on the SM8650 A750 GMU and returns 0, but the CX AO counter at offset 0x1f880 returns some proper timestamp data. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/752235/ Message-ID: <20260909-topic-sm8650-gmu-a750-timestamp-reg-v2-2-091d74958951@linaro.org> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-09-11drm/msm/a6xx: Add CX AO Counter registers used for a750 GPUsNeil Armstrong1-0/+2
The a750 uses the CX AO Counters instead of the GMU_ALWAYS_ON_COUNTER register on A6xx and other A7xx GPUs. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/752234/ Message-ID: <20260909-topic-sm8650-gmu-a750-timestamp-reg-v2-1-091d74958951@linaro.org> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-09-11drm/msm: remove stale perf counter XML TODOGeorge Emmanuel Thomas1-1/+0
The adreno_perfcntrs macro already takes the XML file stem as its second argument, allowing each perf counter JSON file to select the appropriate register XML. The a2xx and a5xx entries already pass their respective XML file stems. Remove the stale TODO comment. Signed-off-by: George Emmanuel Thomas <georgeemmanuelthomas@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/746745/ Message-ID: <20260815164335.158958-1-georgeemmanuelthomas@gmail.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-09-11ring-buffer: Acquire the lock with irqsave in rb_wake_up_waiters()Sebastian Andrzej Siewior1-7/+6
rb_wake_up_waiters() is a irq_work callback which is initialized with init_irq_work(). As such it will be invoked in thread context on PREEMPT_RT. Invoking the callback in IRQ context on PREEMPT_RT is not an option due its usage of wake_up_all(). Since this callback may run in thread context, it needs to acquire ring_buffer_per_cpu::reader_lock with disabling interrupts and may not assume that they are disabled. Use raw_spinlock_irqsave() to acquire ring_buffer_per_cpu::reader_lock. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260911102152.YEtwkBj9@linutronix.de Fixes: 68282dd930ea3 ("ring-buffer: Fix resetting of shortest_full") Reviewed-by: Vincent Donnefort <vdonnefort@google.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11smb: client: validate absolute native symlink targets before NT fixupsJérémy Jean1-7/+17
With symlinkroot unset, an absolute target is copied without conversion to an NT drive path. Later code still assumes an NT prefix is present when modifying the target and calculating the print name length. For "/ab", this causes two failures: sym[5] and path[5] are written past their allocations, and plen -= 2 * poff subtracts an assumed 8-byte prefix from a 6-byte UTF-16 target, wrapping u16 plen to 65534. That underflow causes another overflow: memcpy() copies 65534 bytes into a 24-byte buffer. A user with write access to a mounted share can trigger these bugs with default settings. Validate the NT drive prefix, including an ASCII drive letter, before accessing fixed offsets or subtracting the prefix length. Fixes: 3363da82e02f ("smb: client: fix native SMB symlink traversal") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr> Reviewed-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Paulo Alcantara <pc@manguebit.org>
2026-09-11tracing: Take trace_array reference when opening a tracer options fileSteven Rostedt2-1/+46
When a tracer option file is opened, it is passed a descriptor that points to an element on the trace_array's topts array. This element has information to find the trace array and other information. It uses this element to take a reference of the trace_array so that the trace_array does not get removed while this file is opened. Unfortunately, there's a race condition where the element itself could be freed by the removal of the instance the trace_array represents causing a use-after-free as this element that is used to find the trace_array to increment its reference counter is also freed when the instance is removed. To solve this, add a trace_array_tracer_options_get() helper function that will take the address of the element that is passed to the open function by the inode->i_private pointer and search all the trace_arrays under a lock to find the one that the element's address is in the range of the trace_arrays topts array elements. When a match happens, that trace_array's reference would be increased. Note, there's a race where if an admin was deleting and creating trace instances at the same time and the memory of the old trace_array's array matched the memory of the new trace_array that it could in theory open the option from the wrong trace array. But we do not care because it would be stupid to perform that kind of action. As long as the only thing that can happen is that the option from the wrong trace array is used and doesn't crash the kernel it will only make the user confused. But if they are doing something stupid like this, they are already confused, so no harm done. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260910221209.62dad8d3@robin Fixes: 7e2cfbd2d3c86 ("tracing: Have option files inc the trace array ref count") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/linux-trace-kernel/20260902121918.5a9e9d1b@gandalf.local.home/ Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11tracing: Fix ring_buffer_read_page_size() kernel-docKarl Mehltretter1-1/+1
ring_buffer_read_page_size() takes a parameter named rpage, but its kernel-doc describes page. As a result, kernel-doc reports rpage as undescribed and page as an excess parameter description. Rename the documentation entry to match the function. Link: https://patch.msgid.link/20260909062917.89482-1-kmehltretter@gmail.com Fixes: dae8dda341d2 ("tracing: Fix subbuf resize races with trace_pipe_raw readers") Assisted-by: LLM Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Reviewed-by: Vincent Donnefort <vdonnefort@google.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11tracing: Restore :mod: trailer after parsing in ftrace_set_clr_event()Thomas Weißschuh1-0/+2
While ftrace_set_clr_event() modifies its input buffer during parsing, before returning to the caller the buffer is supposed to be restored to its original state. This works correctly for the colon between the subsystem and event but not the colon at the beginning of :mod:. Restore the colon, so the :mod: trailer is not stripped after ftrace_set_clr_event(). Cc: stable@vger.kernel.org Fixes: 4c86bc531e60 ("tracing: Add :mod: command to enabled module events") Link: https://patch.msgid.link/20260908-tracing-cli-event-filter-v2-1-05396a3fb663@linutronix.de Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11tracing: Fix memory corruption from a "STACKTRACE" histogram keyDonggeun Yoo1-0/+1
"cpu", "CPU", "stacktrace" and "STACKTRACE" are generic fields, defined with an offset and a size of zero so that the filter code can match them by name. parse_field() maps them onto their common_* equivalents for backward compatibility, but unlike the common_* names it hands the placeholder back to the caller instead of NULL. create_hist_field() takes a non-NULL field as a promise that the record carries a stacktrace and picks HIST_FIELD_FN_STACK, so the __data_loc word is read from offset 0, that is from common_type, and its low 16 bits are followed as an offset into the record. What is found there becomes the length of an unbounded memcpy. Pick an event whose id is small enough that the offset stays inside its own record and the length is a kernel text address: # cd /sys/kernel/tracing # echo 'hist:keys=STACKTRACE' > events/ftrace/print/trigger # echo hello > trace_marker Oops: general protection fault, probably for non-canonical address RIP: 0010:rb_next+0x23/0x60 </IRQ> RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x2e7/0x12c0 Kernel panic - not syncing: Fatal exception in interrupt Leave the field NULL, which is what the comment above the branch says the code does and what common_stacktrace already does. FILTER_CPU and FILTER_COMM are left alone, their create_hist_field() branches never look at the field. Cc: stable@vger.kernel.org Fixes: 4b512860bdbd ("tracing: Rename stacktrace field to common_stacktrace") Link: https://patch.msgid.link/20260907155045.692664-3-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11tracing: Fix memory corruption from the histogram stacktrace modifierDonggeun Yoo1-2/+10
parse_field() sets HIST_FIELD_FL_STACKTRACE from the ".stacktrace" modifier before it looks the field name up, and nothing afterwards checks that the name resolved to a field which holds a stacktrace. create_hist_field() picks HIST_FIELD_FN_STACK on the strength of the field pointer alone, which reads a __data_loc word from the record and follows its low 16 bits as an offset into the same record. event_hist_trigger() takes the first word there as an entry count and copies that many longs into a 31 entry array: n_entries = *stack; memcpy(entries, ++stack, n_entries * sizeof(unsigned long)); Neither end of that copy is bounded, and the count is whatever the event holds at the offset, so any field will do: # cd /sys/kernel/tracing/events/sched/sched_process_fork # echo 'hist:keys=parent_pid.stacktrace' > trigger # (true) BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:rb_insert_color+0x18/0x130 timerqueue_linked_add+0x7e/0xd0 enqueue_hrtimer+0x39/0xb0 __hrtimer_run_queues+0x10f/0x1f0 </IRQ> RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x165/0x690 The timer interrupt landed on the rbtree the copy had already run over. No debug options are needed for this; KASAN reports the same write as an out-of-bounds read of 13835058055416381440 bytes. Documentation/trace/histogram.rst already states the rule, "must be a long[] type", so enforce it once the name has been resolved. Names which resolve to no field at all, "hitcount.stacktrace" and the common_* pseudo-fields, are refused for the same reason: they hold no stacktrace to read. Cc: stable@vger.kernel.org Fixes: cc5fc8bfc961 ("tracing/histogram: Add stacktrace type") Link: https://patch.msgid.link/20260907155045.692664-2-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11tracing: Undo the registration when enabling the histogram trigger failsDonggeun Yoo1-7/+10
Commit 6f86bdeab633 ("tracing: Fix bad hist from corrupting named_triggers list") described how a trigger that is registered but not on file->triggers ends up freed while still on the global named_triggers list, and moved the registration down so that hist_trigger_enable() follows it immediately. One path still gets there. hist_trigger_enable() adds the trigger and takes it straight back out when the event cannot be enabled: list_add_tail_rcu(&data->list, &file->triggers); update_cond_flag(file); if (trace_event_trigger_enable_disable(file, 1) < 0) { list_del_rcu(&data->list); update_cond_flag(file); ret--; } so the list walk in hist_unregister_trigger() matches nothing, test stays NULL, and the ->free() that would call del_named_trigger() is skipped. out_unreg falls through to out_free, which frees the trigger anyway: BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff8880091d3160 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0xa00 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 69: kfree+0x154/0x420 trigger_kthread_fn+0xfd/0x160 Leave the trigger where hist_unregister_trigger() can find it and let that undo the registration, which is the only code that knows all of what cmd_ops->init() took: the named list entry, the hist_pad reference, the reference on the trigger a named histogram is shared with, and the copied cmd_ops. It also pairs the failed trace_event_trigger_enable_disable(), whose sm_ref and buffered event reference are otherwise left behind. Since ->free() releases trigger_data and, for a trigger that does not share its histogram, hist_data with it, out_unreg can no longer fall through to out_free. For a trigger that does share, hist_register_trigger() has already destroyed the caller's hist_data, so the fall-through was reading freed memory there as well. Move the enable_timestamps check in hist_unregister_trigger() above the ->free() call for the same reason: hist_data does not outlive it once the trigger being removed is the one that owns it. Cc: stable@vger.kernel.org Fixes: 067fe038e70f ("tracing: Add variable reference handling to hist triggers") Reported-by: Sashiko AI <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/linux-trace-kernel/20260907092944.3950E1F00A3D@smtp.kernel.org/ Link: https://patch.msgid.link/20260907124420.607097-3-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11tracing: Take the reference before publishing the named histogram triggerDonggeun Yoo1-5/+6
event_hist_trigger_named_init() puts the trigger on the global named_triggers list and only then takes the reference on the trigger it shares its histogram with: data->ref++; save_named_trigger(data->named_data->name, data); ret = event_hist_trigger_init(data->named_data); if (ret < 0) { kfree(data->cmd_ops); data->cmd_ops = &trigger_hist_cmd; } return ret; event_hist_trigger_init() fails when alloc_hist_pad() cannot allocate, and nothing takes the trigger back off the list on the way out. event_hist_trigger_parse() frees it, and the next lookup by name reads the freed object: BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff888009346860 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0xa00 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 67: kfree+0x154/0x420 trigger_kthread_fn+0xfd/0x160 Do the reference first and publish once it has succeeded, so that nothing which can fail runs after the trigger becomes findable. Cc: stable@vger.kernel.org Fixes: 7ab0fc61ce73 ("tracing: Move histogram trigger variables from stack to per CPU structure") Reported-by: Sashiko AI <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/linux-trace-kernel/20260907092944.3950E1F00A3D@smtp.kernel.org/ Link: https://patch.msgid.link/20260907124420.607097-2-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com> Acked-by: Tom Zanussi <zanussi@kernel.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11tracing: Set the trace clock before registering the histogram triggerDonggeun Yoo1-6/+9
hist_register_trigger() puts the trigger on the global named_triggers list in cmd_ops->init(), and only then sets the trace clock: if (data->cmd_ops->init) { ret = data->cmd_ops->init(data); if (ret < 0) goto out; } if (hist_data->enable_timestamps) { ret = tracing_set_clock(file->tr, hist_data->attrs->clock); if (ret) { hist_err(tr, HIST_ERR_SET_CLOCK_FAIL, errpos(clock)); goto out; } The clock string is not checked anywhere before that call, so a named trigger using common_timestamp with an unknown clock fails after it has already become findable. event_hist_trigger_parse() then frees it without taking it off the list, and the next lookup by name reads the freed object: ~# cd /sys/kernel/tracing/events/sched/sched_switch ~# echo 'hist:name=foo:keys=common_pid:ts=common_timestamp:clock=bogus' > trigger bash: echo: write error: Invalid argument ~# echo 'hist:name=foo:keys=common_pid' > trigger BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff88800915d760 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0x900 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 63: kfree+0x154/0x420 trigger_kthread_fn+0xfd/0x160 Set the clock before the trigger is registered, so that nothing which can fail runs after it is published, the way commit 6f86bdeab633 ("tracing: Fix bad hist from corrupting named_triggers list") moved the registration below the rest of the setup. tracing_set_filter_buffering() is reference counted, so the init failure path has to drop the reference that the clock block now takes first. Cc: stable@vger.kernel.org Fixes: a4072fe85ba3 ("tracing: Add a clock attribute for hist triggers") Link: https://patch.msgid.link/20260907091415.554535-1-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>