| Age | Commit message (Collapse) | Author | Files | Lines |
|
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>
|
|
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>
|
|
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
...
|
|
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()
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
...
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
"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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|