pre_reset only force-completes fences of MAPPED queues. A queue in any
other state (e.g. mid-eviction) keeps its last_fence pending; after a
GPU reset that fence never signals, so the eviction/suspend worker and
process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and
wedge the machine:
INFO: task kworker/6:28 blocked for more than 120 seconds.
Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu]
Call Trace:
dma_fence_wait_timeout+0x7e/0x130
amdgpu_userq_evict+0x67/0x140 [amdgpu]
amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu]
process_scheduled_works+0xa6/0x420
Force-complete every queue's fence regardless of state. The unmap and
mark-hung step stays gated on MAPPED, since unmapping a queue that is
not mapped is invalid.
Fixes: 290f46cf57 ("drm/amdgpu: Implement user queue reset functionality")
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 9102b39fa9)
Cc: stable@vger.kernel.org
set_pipe_unlock_order needs to be set to true for the pipes to be unlocked
in correct order to avoid det overallocation
Reviewed-by: Charlene Liu <charlene.liu@amd.com>
Signed-off-by: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 183bbded99)
set_pipe_unlock_order needs to be set to true for the pipes to be unlocked
in correct order to avoid det overallocation
Reviewed-by: Taimur Hassan <syed.hassan@amd.com>
Signed-off-by: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 198663d035)
[Why]
FWTS autobrightness fails on eDP panels because actual_brightness can
read higher than the advertised max_brightness (e.g. 63576 vs 62451).
The conversion helpers expose the firmware PWM range to userspace as
[0..max]. But max_brightness is advertised as (max - min), which is
smaller. So reading the level can return a value above max_brightness.
This regressed in commit 4b61b8a390 ("drm/amd/display: Add debugging
message for brightness caps"), which changed max_brightness to
(max - min) and undid commit 8dbd72cb79 ("drm/amd/display: Export full
brightness range to userspace").
[How]
Advertise max_brightness as max, and scale the initial AC/DC brightness
against max too. Update the KUnit expectations to match.
Fixes: 4b61b8a390 ("drm/amd/display: Add debugging message for brightness caps")
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit bd9e2b5b04)
Cc: stable@vger.kernel.org
[why]
The 8K120/8K240 timings live in DisplayID extension blocks 2 and 3
of this EDID. The EDID is a 4-block (512-byte) HDMI 2.1 EDID
that uses HF-EEODB.
drm core reads and parses this correctly, but amdgpu rebuilds its own copy.
Only 2 of 4 blocks were copied into sink->dc_edid, that leads to
drm_edid_connector_add_modes() never sees blocks 2 and 3.
[how]
Directly populate edid_blob_ptr with a blob whose length is the full,
and HF-EEODB-aware size.
Reviewed-by: Sun peng (Leo) Li <sunpeng.li@amd.com>
Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 11a90eaf5c)
No functional changes. Just clean up a conceptual mismatch.
Based on feedback on the NUTMEG code in DC, the
preferred_link_setting is meant to force the DP link to a
specific setting, meaning both the link rate and lane count
should be locked to an exact value. What NUTMEG needs is
a lower bound on the link rate, which is not the same concept.
Implement this as a HW workaround flag instead.
Suggested-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 871ceb8538)
Cc: stable@vger.kernel.org
When there is a preferred link rate setting, it needs to be
applied to both the current and initial link rate.
This was regressed by a "coding style" fix, which caused
the current link rate to not respect the preferred value.
This commit restores the functionality of NUTMEG,
the DP bridge encoder found on old APUs such as Kaveri.
Fixes: a62346043a ("drm/amd/display: Fix coding style issue")
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5465
Cc: Chuanyu Tseng <Chuanyu.Tseng@amd.com>
Reviewed-by: Fangzhi Zuo <Jerry.Zuo@amd.com>
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit e78b0a367f)
Cc: stable@vger.kernel.org
total_cwsr_size was computed in 32-bit before being used as a BO/SVM
allocation size.
With large ctx_save_restore_area_size and debug_memory_size
multiplied by the XCC count, the product can wrap,
yielding an undersized CWSR save area that firmware later overruns.
Promote total_cwsr_size to u64 and use check_add_overflow()/
check_mul_overflow() in both kfd_queue_acquire_buffers() and
kfd_queue_release_buffers().
Signed-off-by: Yongqiang Sun <Yongqiang.Sun@amd.com>
Reviewed-by: Philip Yang <philip.yang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 319f7e1342)
Cc: stable@vger.kernel.org
[why]
DCN42B is missing some register masks, which are causing errors in dmesg.
[how]
Make DCN42B reuse the DCN42 register lists, and add the missing defines manually.
Fixes: 64142f9d51 ("drm/amd/display: Fix DCN42 null registers & register masks")
Reviewed-by: Ovidiu (Ovi) Bunea <ovidiu.bunea@amd.com>
Signed-off-by: Matthew Stewart <Matthew.Stewart2@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit b7d6914590)
GC 11.7.0 and 11.7.1 should map to AMDGPU_FAMILY_GC_11_5_4 for DCN42.
Fixes: cf591e67c0 ("drm/amdgpu: add support for GC IP version 11.7.0")
Fixes: a928d8d81e ("drm/amdgpu: add support for GC IP version 11.7.1")
Signed-off-by: Roman Li <Roman.Li@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit f8ee6447e7)
on plane disable) along with couple of GT selftests fixes.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEbSBwaO7dZQkcLOKj+mJfZA7rE8oFAmpadygACgkQ+mJfZA7r
E8prkQf/anrvKC+XNFx1PHSBwHiuzuCDCCGm+M4guTs1WxUi0m9yAhD7YWKXnC8r
8j2SUB3Vcm6rEYTEspd+BktN3WdGFymDQ+LTuxZNb84pm0fkpHat0VlX7RBib373
OgaiDK0odXWedPoaOglGMmTY0KS6BMuBFFZMHdFfoK06fjkeZO18aFw+eyh9NBLH
CqZkbMygXBRKUfAT81V2+IUKeiTQ5DZTjTrysx9ywA7+6l6zlH85B0c3bGGZHQE1
YzQVnRbqStMfCdkzJ1Tj9RLA6iygCcRrA7taOwIep5plDCA0x7j7ZKWSNvePcmQJ
YSaZ7wr/wUdyl5aPsSyBZQ0dGBIb6w==
=Y8Vk
-----END PGP SIGNATURE-----
Merge tag 'drm-intel-fixes-2026-07-17' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes
Couple of display fixes (NV12 for bigjoiner and Watermark clear
on plane disable) along with couple of GT selftests fixes.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/alp3ks0K1ZsxUC05@intel.com
The device's last busy timestamp was set in a wrapper function since
the commit 08071e64cb ("PM: runtime:
Mark last busy stamp in pm_runtime_autosuspend()").
Thus delete a pm_runtime_mark_last_busy() call before
a pm_runtime_autosuspend() call.
The source code was transformed by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/e3631a8e-b4a4-4e14-822d-2199f1576cc9@web.de
check_kfunc_call() reads meta.func_name when bpf_fetch_kfunc_arg_meta()
returns -EACCES, but that error can come from fetch_kfunc_meta() (e.g.
fd_array_get_btf() rejecting BTF binding for a signed program) before
meta is memset(), leaving it uninitialized and risking a garbage deref
in verbose().
Move the memset() to the start of bpf_fetch_kfunc_arg_meta() so meta is
zeroed on every error return. The intended "not allowed" -EACCES path
still sets func_name first, so its message is unchanged.
Signed-off-by: Amery Hung <ameryhung@gmail.com>
Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://patch.msgid.link/20260715172127.2416388-3-ameryhung@gmail.com
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
For a bloom filter, the value argument of bpf_map_peek_elem() is always
an input. Therefore, the verifier should not allow passing uninitialized
stack memory to it to avoid information leak.
bpf_map_peek_elem() tags its value argument ARG_PTR_TO_MAP_VALUE |
MEM_UNINIT, telling the verifier the callee fills the buffer. This holds
for queue/stack maps, but not for a bloom filter, which reads the buffer
as an input to test set membership and never writes it.
As a result, a program can pass an uninitialized stack buffer to
bpf_map_peek_elem() on a bloom filter. The verifier accepts it and marks
the buffer initialized on return, letting the program read back leftover
kernel stack memory. Bloom maps require CAP_BPF to create, so this is a
CAP_BPF-gated stack infoleak that bypasses the boundary CAP_BPF is meant
to enforce (arbitrary kernel reads are gated behind CAP_PERFMON).
Signed-off-by: Amery Hung <ameryhung@gmail.com>
Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://patch.msgid.link/20260715172127.2416388-2-ameryhung@gmail.com
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
- Fix a UAF in socket clone early bailout paths (Matt Bobrowski)
- Reject unhashed UDP sockets on sockmap update to prevent refcount leaks
(Michal Luczaj)
- Account for receive queue data in FIONREAD on sockmap sockets without a
verdict program (Mattia Meleleo)
- Reject negative constant offsets for verifier buffer pointers (Sun Jian)
- Fix for tracing of kfuncs with implicit arguments (Ihor Solodrai)
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQR0/74CM8h5+1E9pgtHLTd7Y1QvgwUCalp3/AAKCRBHLTd7Y1Qv
g9J/AQCJzidAmStp1i074sZC7sC1uq+aYIvwycpMTp6hVgyP+AEAw7oKcnGkPGXs
jeEDctaLtxBnPMXGAR5UaeqdNqu9ywQ=
=zQgn
-----END PGP SIGNATURE-----
Merge tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf
Pull bpf fixes from Kumar Kartikeya Dwivedi:
- Fix a UAF in socket clone early bailout paths (Matt Bobrowski)
- Reject unhashed UDP sockets on sockmap update to prevent refcount
leaks (Michal Luczaj)
- Account for receive queue data in FIONREAD on sockmap sockets without
a verdict program (Mattia Meleleo)
- Reject negative constant offsets for verifier buffer pointers (Sun
Jian)
- Fix for tracing of kfuncs with implicit arguments (Ihor Solodrai)
* tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
selftests/bpf: Cover tracing implicit kfunc args
bpf: Fix tracing of kfuncs with implicit args
selftests/bpf: Cover negative buffer pointer offsets
bpf: Reject negative const offsets for buffer pointers
selftests/bpf: Test FIONREAD on a sockmap socket without a verdict program
bpf, sockmap: Account for receive queue in FIONREAD without a verdict program
selftests/bpf: Fail unbound UDP on sockmap update
selftests/bpf: Adapt sockmap update error handling
bpf, sockmap: Reject unhashed UDP sockets on sockmap update
selftests/bpf: Ensure UDP sockets are bound
bpf: Fix UAF in sock clone early bailouts
Respell the vio launch loop to use the existing vio_count
value. The repair completion is not guaranteed to persist
after all of the metadata_vios are launched. This can not
currently cause problems due to the way vio callbacks are
handled, but it is technically not safe to access those
fields.
Signed-off-by: Matthew Sakai <msakai@redhat.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
get_cache_segment() scans the segment map up to cache->n_segs, the
physical device segment count, but cache_segs_init() only initializes
the first cache_info->n_segs segments. A crafted image with
cache_info->n_segs smaller than the device count leaves the remaining
pcache_cache_segment structs zeroed (segment.data == NULL), and the
allocator can hand one to cache_kset_close(), which writes through the
returned segment's data pointer with no NULL check.
Bound the allocator's search to cache_info->n_segs so only initialized
segments are ever returned. A conforming cache sets n_segs equal to the
device segment count, so this rejects nothing legitimate.
Fixes: 1d57628ff9 ("dm-pcache: add persistent cache target in device-mapper")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
The writeback worker follows the persisted dirty_tail chain, which is
decoded from the cache device independently of the key_tail chain that
cache_replay() walks and bounds. A crafted image, whose on-media fields are
authenticated only by a crc32c with a fixed seed, can aim dirty_tail at a
chain of last ksets that never terminates, so cache_writeback_fn() re-arms
itself with no delay forever.
Walk the dirty_tail chain once at load with the same hop cap cache_replay()
uses and fail the table load with -EIO if it does not reach an end within
n_segs hops.
Fixes: 1d57628ff9 ("dm-pcache: add persistent cache target in device-mapper")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
seg_num is read from the crc32c-only superblock, so whoever supplies the
cache device on a table load (CAP_SYS_ADMIN) controls it. It sizes
cache->segments[] and is the value every later on-media segment id is
bounded against, yet it is never checked against the device. Because
cache_dev->mapping is the direct map of the pmem, CACHE_DEV_SEGMENT() for
a segment id past the device resolves to ordinary kernel memory beyond
the mapping; a new-cache init reaching such an id has cache_seg_init() ->
cache_dev_zero_range() memset() 12 KiB over that memory -- an
out-of-bounds write into the kernel heap at table load. A zero seg_num
makes the segment allocations ZERO_SIZE_PTR.
Reject a seg_num that is zero, larger than the device can hold, or larger
than PCACHE_CACHE_SEGS_MAX before it is used.
Fixes: 1d57628ff9 ("dm-pcache: add persistent cache target in device-mapper")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
The tail-kset read in cache_replay(), the writeback worker and the GC
worker bounds its length by PCACHE_SEG_SIZE - seg_off, the raw segment
size rather than the data region. A tail near the segment end reads past
the segment data into the following control area.
Clamp the read to cache_seg_remain(), the data region.
Fixes: 1d57628ff9 ("dm-pcache: add persistent cache target in device-mapper")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
cache_key_decode() takes a key's logical off from the cache device and
later indexes req_key_tree->subtrees[] by it in get_subtree(). An off
past the device forms a subtree pointer outside the array, which
rb_insert() writes through during replay.
Reject a key of zero length, or whose off+len (computed in 64 bits)
exceeds the device size, before it is used.
Fixes: 1d57628ff9 ("dm-pcache: add persistent cache target in device-mapper")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
cache_replay() follows the on-media last-kset chain by next_cache_seg_id
with no cond_resched(). A forged chain that points back into a segment it
has already visited makes the replay loop follow it forever.
Cap the last-kset hops at cache->n_segs; a valid chain visits each segment
at most once.
Fixes: 1d57628ff9 ("dm-pcache: add persistent cache target in device-mapper")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
cache_replay(), the writeback worker and the GC worker read a kset of
get_kset_onmedia_size() bytes and advance the position by it. A forged
key_num makes that size exceed the segment's remaining space, so the
advance walks past the segment and trips the cache_pos_advance() BUG_ON.
Reject a kset whose on-media size exceeds cache_seg_remain() before use.
Fixes: 1d57628ff9 ("dm-pcache: add persistent cache target in device-mapper")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
cache_pos_decode() takes the persisted key_tail and dirty_tail seg_off from
the cache device and addresses within the segment with it. A seg_off at or
past the segment data_size, controllable by whoever supplies the device
(CAP_SYS_ADMIN), reads past the segment data.
Reject a decoded seg_off that is not below the segment data_size.
Fixes: 1d57628ff9 ("dm-pcache: add persistent cache target in device-mapper")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Two more fields decoded from the cache device go unbounded. The kset
key_num drives cache_kset_crc() and the replay loop in cache_replay(),
the writeback worker and the GC worker, but only the magic and a
fixed-seed CRC are checked first, so a non-last kset whose key_num exceeds
the PCACHE_KSET_KEYS_MAX buffer reads past its end before the CRC compare.
A key's intra-segment offset and length in cache_key_decode() are taken
verbatim, so a key running past its segment is replayed into the cache
tree and the data CRC check and every later read hit then copy adjacent
persistent memory into the caller's bio -- an out-of-bounds read that
leaks to user space. Both fields are controlled by whoever supplies the
cache device (CAP_SYS_ADMIN); the CRC seed is public.
Add kset_onmedia_valid() to bound key_num before any kset read, and
reject a key whose offset plus length, computed in 64 bits, exceeds the
segment data_size. Valid metadata is unaffected.
Fixes: 1d57628ff9 ("dm-pcache: add persistent cache target in device-mapper")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
cache_segs_init() iterates cache_info->n_segs times indexing
cache->segments[], which is sized to the cache device geometry, and
get_seg_id() takes each segment id from the on-media cache_info and the
per-segment next_seg link. Both come from cache device metadata that is
only CRC-protected with a fixed public seed, so whoever supplies the
cache device on a table load (CAP_SYS_ADMIN) controls them: an oversized
n_segs or an out-of-range id drives an out-of-bounds access of
cache->segments[] and a wild CACHE_DEV_SEGMENT() pointer into the device
mapping -- an out-of-bounds read and write from on-disk data.
Reject an n_segs that exceeds the device segment count and a segment id
that is out of range before either is used. Valid metadata is unaffected.
Fixes: 1d57628ff9 ("dm-pcache: add persistent cache target in device-mapper")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
cache_pos_decode(), cache_key_decode() and the last-kset branches of
cache_replay(), the writeback worker and the GC worker take a cache
segment id from the cache device metadata and index cache->segments[]
with it without checking it against cache->n_segs. That metadata is only
CRC-protected with a fixed public seed, so whoever supplies the cache
device on a table load (CAP_SYS_ADMIN) controls the id; an out-of-range
value forms a wild pcache_cache_segment pointer that is dereferenced and
written through -- an out-of-bounds read and write driven by on-disk data.
Add cache_seg_id_valid() and reject an out-of-range id at each decode
site, failing the operation with -EIO instead of indexing past the array.
Bound the id against the initialized-segment count (cache_info.n_segs)
rather than the physical device total. A forged cache_info.n_segs below
seg_num otherwise leaves segments[cache_info.n_segs..seg_num) as zeroed
structs whose data pointer is NULL, so a forged id in that window would
still be dereferenced. A later patch guarantees cache_info.n_segs <=
seg_num, and a driver-created cache sets the two equal, so valid images
are unaffected.
Fixes: 1d57628ff9 ("dm-pcache: add persistent cache target in device-mapper")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQJIBAABCgAyFiEES0KozwfymdVUl37v6iDy2pc3iXMFAmpaXtgUHHBhdWxAcGF1
bC1tb29yZS5jb20ACgkQ6iDy2pc3iXPAGxAAyCWrUecMqUOJTSYbTl5hjRqR6w9U
+h1hfFaiukGgEokG9qrFBR7MTgei0ybcyt2d/Mn8r2Mz1C0kK4tBjtT8ho1tqVZD
5ANfti4ffhw6H83ZHRf5h18vwNXldHjBsEwjthySRYwlK2KsV4tW/+WFCStdWzCH
TOpUShUlkIMvibNbKf6vvqk75jP/SCZLpjsRBD+gdRSkXqcFLLqXrK+FiAw4NKXE
z7nRc0KK161eT4GM+KPBYkC9hE6+PntamYL10nDgrz1r3hp/B2Wx66bO36NR7XvA
5omsa/hJW7aXoQtXTxlf2+AuhYKjig+KYdxhidU8jKVXc16fUn4UmeUZJRvoDQKW
ryjPALVnbBIrw/e+nDYV0wsJD6q8xAE3LuIQIMir661ZMtf7umdmm6G1anyhKYHe
oLgjKyOiaGaY9WeW+g+bO29pmcpnmPPyiNI2KRkLsfgeCB2JKECDLyjZboCNjWGV
ykdmt3kXndlaEwpmxvJBFCb4WlB2mKpCz6HxgNhM2jPu5X4MwS6fkrvIlBNHcdTg
o2Sz5cuQLcnpD9A91AhKmKdxNYNeT7H4KlMm8x/8vRHNQbmi72WE7kkuEj09augt
qeO8kbeq7dm13wY72MzNOQXwiNtmeCUDPwehud86Hqg0iZDDyB2RGWtn14AWQhGb
Kmpyx9QglgeUEyc=
=4P+L
-----END PGP SIGNATURE-----
Merge tag 'selinux-pr-20260717' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux
Pull selinux fix from Paul Moore:
"A single SELinux patch to correct a problem with the overlayfs mmap()
and mprotect() fixes from earlier this year where we inadvertenly
included an additional SELinux execmem permission check on some
operations"
* tag 'selinux-pr-20260717' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux:
selinux: fix incorrect execmem checks on overlayfs
A kprobe can be hit while another kprobe is in KPROBE_HIT_SS state. This
can happen when tracing or perf code runs from the debug exception path
while the first kprobe is preparing or executing its out-of-line
single-step instruction.
Currently arm64 treats a kprobe hit in KPROBE_HIT_SS as unrecoverable,
the same as a hit in KPROBE_REENTER. This is too strict. A hit in
KPROBE_HIT_SS is still a one-level reentry and can be handled by saving
the current kprobe state and setting up single-step for the new probe,
just like reentry from KPROBE_HIT_ACTIVE or KPROBE_HIT_SSDONE.
The truly unrecoverable case is hitting another kprobe while already in
KPROBE_REENTER, because the reentry save area has already been consumed.
Move KPROBE_HIT_SS to the recoverable reentry cases and leave
KPROBE_REENTER as the unrecoverable nested reentry case.
This change also requires saving saved_irqflag in struct prev_kprobe.
When a nested kprobe calls kprobes_save_local_irqflag(), it overwrites
kcb->saved_irqflag with the currently masked DAIF value, losing the
outer kprobe's original DAIF state. Without this fix, when the outer
kprobe's single-step finishes, kprobes_restore_local_irqflag() applies
the wrong DAIF mask and leaves interrupts permanently disabled.
Extend struct prev_kprobe with a saved_irqflag field and save/restore it
alongside kp and status. This ensures the outer kprobe's original
interrupt state is preserved across reentry.
This mirrors the x86 fix in commit 6a5022a56a
("kprobes/x86: Allow to handle reentered kprobe on single-stepping").
Signed-off-by: Pu Hu <hupu@transsion.com>
Signed-off-by: Hongyan Xia <hongyan.xia@transsion.com>
Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
kprobe_fault_handler() currently treats any page fault taken while in
KPROBE_HIT_SS or KPROBE_REENTER state as a kprobe single-step fault. This
assumption does not hold: perf or tracing code may run from the debug
exception path during the single-step window and take its own page fault.
When the fault is handled as a kprobe fault, the PC is rewritten to the
probe address, corrupting the exception recovery context for the real
fault. A typical reproducer is running perf with preemptirq tracepoints
and dwarf callchains while a kprobe is installed on a frequently
executed function.
Fix this in two layers:
1. At function entry, bail out immediately for simulated kprobes
(ainsn.xol_insn == NULL), since they have no XOL slot and any fault
taken during their execution cannot be a single-step fault.
2. For kprobes with an XOL slot, only handle the fault when the
faulting PC matches the XOL instruction address. Faults from any
other PC are left to the normal page fault handler.
This follows the same principle as the x86 fix in commit 6381c24cd6
("kprobes/x86: Fix page-fault handling logic").
Signed-off-by: Pu Hu <hupu@transsion.com>
Signed-off-by: Hongyan Xia <hongyan.xia@transsion.com>
Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
- Fix a build error in certain configurations
- Clarify some parts of the documentation
- Remove unused code that I forgot to remove in commit cf52058dcd
-----BEGIN PGP SIGNATURE-----
iIoEABYIADIWIQSacvsUNc7UX4ntmEPzXCl4vpKOKwUCalpR7hQcZWJpZ2dlcnNA
a2VybmVsLm9yZwAKCRDzXCl4vpKOK0FsAP4g1ERoX/xslpz++c9GQPK3QhXGjug5
B1nGMnqDJPQmewD/eAloShBc5VYxnCeDDN24txP2RZeRK9XSG/mGTsdv2wk=
=Dtak
-----END PGP SIGNATURE-----
Merge tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux
Pull crypto library fixes from Eric Biggers:
- Fix a build error in certain configurations
- Clarify some parts of the documentation
- Remove unused code that I forgot to remove in commit cf52058dcd
("lib/crypto: powerpc/md5: Drop powerpc optimized MD5 code")
* tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux:
crypto: aes - Fix conditions for selecting MAC dependencies
lib/crypto: docs: Improve introduction sentence
lib/crypto: docs: Fix some sentence fragments
lib/crypto: md5: Remove support for md5_mod_init_arch()
Sashiko (locally) reports a logical issues in mmio_guard_ioremap_hook()
mmio_guard_ioremap_hook() attempts to handle unaligned addresses and
sizes. However, aligning the start address before adding the size, might
shift the end to the page before.
Fixes: 0f12694958 ("drivers/virt: pkvm: Intercept ioremap using pKVM MMIO_GUARD hypercall")
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
io_install_bpf() only rejects a second registration on the ctx side
(ctx->bpf_ops) and sets the per-map back-pointer ops->priv
unconditionally. The struct_ops link path never advances a map past
BPF_STRUCT_OPS_STATE_READY, so the same io_uring_bpf_ops map can be
registered more than once, and bpf_io_reg() re-resolves the target ring
via fget(ops->ring_fd) on every call. A caller can therefore point the
same ring_fd at a different io_ring_ctx between two BPF_LINK_CREATE
calls.
The second registration passes the ctx->bpf_ops check (the new ctx has
none) and overwrites ops->priv, orphaning the first ctx. Teardown
(io_eject_bpf()/bpf_io_unreg()) only reaches a ctx through ops->priv, so
the orphaned ctx is never torn down: its ctx->loop_step keeps pointing
into the struct_ops trampoline, which is freed once the map is gone. A
later io_uring_enter() on the orphaned ring then calls the dangling
ctx->loop_step from io_run_loop() -- a use-after-free of freed
executable memory, reachable by a task with CAP_BPF + CAP_PERFMON.
Reject registration when ops->priv is already set, as hid_bpf_reg()
does for its struct_ops.
Cc: stable@vger.kernel.org
Fixes: 98f37634b1 ("io_uring/bpf-ops: implement bpf ops registration")
Signed-off-by: Woraphat Khiaodaeng <worapat.kd2@gmail.com>
Reviewed-by: Gabriel Krisman Bertazi <krisman@suse.de>
Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://patch.msgid.link/20260717154537.129736-1-worapat.kd2@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The io.latency doc says the io.stat delay field counts microseconds. The
field is delay_nsec and is reported in nanoseconds. Refer to it by its
real name and correct the unit.
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Acked-by: Michal Koutný <mkoutny@suse.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
The test_cgcore_no_internal_process_constraint_on_threads test has two
back-to-back cg_enter_current(root) calls in its cleanup path.
A single cg_enter_current() call atomically migrates the entire thread
group to the target cgroup even for multi-threaded processes, and this
test creates no extra threads or child processes that would require a
second migration attempt. The second call is a harmless no-op once the
process is already in the root cgroup, but it is redundant and
inconsistent with the cleanup logic used in all other cgroup core
selftest cases.
Remove the duplicate call to clean up the code. No functional change is
intended.
Signed-off-by: Jian Guo <guojian@kylinos.cn>
Acked-by: Michal Koutný <mkoutny@suse.com>
Tested-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Tejun Heo <tj@kernel.org>
On some NXP chipsets, disabling Root Port MSI/MSI-X Capabilities blocks
MSIs originating from Endpoints from reaching the iMSI-RX controller.
To address this hardware bug, commit 3a4e8302e7 ("PCI: imx6: Keep Root
Port MSI capability with iMSI-RX to work around hardware bug") preserves
Root Port MSI and MSI-X Capabilities on i.MX7D, i.MX8MM, and i.MX8MQ
when iMSI-RX is in use.
The same applies to i.MX6Q, i.MX6QP, and i.MX6SX, so preserve Root Port
MSI/MSI-X Capabilities there as well.
Note that preserving these Capabilities means Root Port-originated MSIs
such as AER and PME won't be received due to separate hardware limitations.
Users may need to use workarounds such as passing the 'pcie_pme=nomsi'
command-line parameter.
Fixes: f5cd8a929c ("PCI: dwc: Remove MSI/MSIX capability for Root Port if iMSI-RX is used as MSI controller")
Signed-off-by: Soeren Moch <smoch@web.de>
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Acked-by: Richard Zhu <hongxing.zhu@nxp.com>
Cc: stable@vger.kernel.org # 7.0+
Link: https://patch.msgid.link/20260717033203.2965045-1-hongxing.zhu@oss.nxp.com
The Focaltech ft3d81 is fully compatible with the ft8112 i.e.
it uses the same I2C-HID protocol and the same power-on/reset sequencing,
DT nodes for boards carrying an ft3d81,can therefore bind to the existing
ft8112 driver without any additional changes.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Pradyot Kumar Nayak <pradyot.nayak@oss.qualcomm.com>
Link: https://patch.msgid.link/20260717-add_focaltech_ft3d81_touchscreen_support-v4-1-5dd091e25801@oss.qualcomm.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The driver implements debounce protection using a timer-based mechanism:
when a key interrupt occurs, a timer is scheduled to verify the key state
after DEBOUNCE_TIME before reporting the event. This works well during
normal operation.
However, key press events can be lost during system resume on platforms
like i.MX8MQ-EVK because:
1. During the no_irq resume phase, PCIe driver restoration can take up to
200ms with IRQs disabled.
2. The power key interrupt remains pending during the no_irq phase.
3. If the key is released before IRQs are re-enabled, the timer eventually
runs but sees the key as released and skips reporting the event.
To prevent event loss during system suspend, set a pending_press flag in
the interrupt handler and report the press event from the timer callback
when the flag is set. This avoids out-of-order event delivery and keeps
the existing timer-based debounce mechanism for normal operation.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260715-b4-pwrkey-v5-4-07e7353c319e@oss.nxp.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Add the PCI1008 device ID to the quirk_switchtec_ntb_dma_alias PCI fixup
table. Without it, DMA transactions from a PCI1008 switch's NTB function
are not given the correct requester ID alias, which can misdirect them
under an IOMMU.
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260714212010.230606-4-logang@deltatee.com
Add the Microchip PCI1008 device ID to the core switchtec management
driver's PCI ID table. Without it, the management endpoint on a PCI1008
switch is not bound by this driver, preventing userspace tools from
configuring or monitoring the switch and leaving NTB functionality
unavailable.
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260714212010.230606-3-logang@deltatee.com
- the revert of the uclinux map driver which was presumably no longer
used but in fact was
- the use of SPI match data to get chip capabilities in the mchp23k256
driver
- several fixes addressing the newly introduced virt-concat support
- a missing build dependency on ndfc
There is as well the usual load (if not actually bigger than ususal) of
uninitialized variables, leaks, double free, and AI fuzzed issues being
fixed.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmpaTeQACgkQJWrqGEe9
VoQ0/Af7BpZ9gxFZrgiXBdQ/XcVDfsrP7YP/3D3SLlB7ynwPHrq0YvMdBs8CCp+b
YbTDqBrt0+T1YeZ4igWu50bGSjAz0mLztE2r09/uwrG9YO+B0s98jXRFEqnaOMMf
2ghhrIKr2RB9OPJaigmtdzQij1UAjCIFpWxEz4XLytXQ5oxnzP2j50JyeVxifb1R
3KDw0KBibngn3I5MUQ4OHCg4+6Krf0rtjo8yZWB6LKgVlCcy3eEbYGZMn3YI3T6T
xsOa8KxkBLf2BeAFu2nDp0e/5vEfaVk9fCnRElBDz3kEdJ6LR6k45mLpqfB+U9HN
DhWZswONu0y54xHAmyauVWyYBK/DHg==
=SD+E
-----END PGP SIGNATURE-----
Merge tag 'mtd/fixes-for-7.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull mtd fixes from Miquel Raynal:
"Among the most important fixes that we have here, there are:
- the revert of the uclinux map driver which was presumed to
be no longer used but in fact was
- the use of SPI match data to get chip capabilities in the
mchp23k256 driver
- several fixes addressing the newly introduced virt-concat
support
- a missing build dependency on ndfc
as well as the usual load (if not actually bigger than usual) of
uninitialized variables, leaks, double free, and AI fuzzed issues
being fixed"
* tag 'mtd/fixes-for-7.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux:
Revert "mtd: maps: remove uclinux map driver"
mtd: onenand: samsung: report DMA completion timeouts
mtd: rawnand: fsl_ifc: return errors for failed page reads
mtd: mchp23k256: use SPI match data for chip caps
mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout
mtd: rawnand: lpc32xx_mlc: fail DMA transfers on timeout
mtd: fix double free and WARN_ON in add_mtd_device() error paths
mtd: virt-concat: free duplicate generated name
mtd: nand: mtk-ecc: stop on ECC idle timeouts
mtd: mtdswap: remove debugfs stats file on teardown
mtd: mtdpart: validate partition bounds in mtd_add_partition()
mtd: mtdpart: fix uninitialized erasesize on MTDPART_OFS_RETAIN error path
mtd: rawnand: ndfc: add CONFIG_OF dependency
mtd: spinand: initialize ret in regular page reads
mtd: virt_concat: fix use-after-free in mtd_virt_concat_destroy()
mtd: rawnand: ingenic: handle ECC clock enable failures
mtd: nand: ecc-mtk: handle ECC clock enable failures
mtd: virt_concat: fix use-after-free in mtd_virt_concat_destroy_joins()
mtd: rawnand: ndfc: fix gcc uninitialized var
- Fix RPMB device unregister ordering
- Fix __counted_by handling in mmc_test
MMC host:
- mtk-sd: Document missing clocks for MT8189
- sdhci-esdhc-imx: Fix the support for system suspend/resume for SDIO
- sdhci-of-dwcmshc: Fix error handling for clock prepare/enable
- vub300: Fix lockdep issue for the cmd_mutex
- vub300: Fix use-after-free on probe failure
MEMSTICK:
- Reject a card that reports too many blocks
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAmpaF4YQHHVsZmhAa2Vy
bmVsLm9yZwAKCRD+JoQlc1iMKQsXEAC4Y3DuRvuYUi3MVeAI8IqXZKW1qZ2Wg7pD
tvjbS0h1ZLVBPXeWIhjL2N9Y2GWIzbq5Yb0zAyqwl4d99IsNL5j0ul6rQbVWHY6Z
48IJ8idboGeUXZ9foUif8t+gZOVUd6Mecf8GxWkJcwlJ70pt36TCGWPvp3/MkQmP
w6srlDXfIZgQyauQIz+cHYcocD0L7vp6apAcT/QQRLadY4PBpzNfjjgbqr5ogejF
ovRkTUBp2D/ufTV0p8V0ykQ9onac7aV1HrX1ubSjs/2rkxNMOBGRYTeds8YYm4Of
Jljdivx0EeLA638sJ7XO6QGbxT7pwwffRzS+q6VE+NilKghwF3/GE1LPv8NSV+mA
woeSxPCgVxfqF+THGQE9J8NQXtIV6UF7gNHVSp+Vq/aKuykSwnRslUbu7mncgDZC
nv2cwcmlVU98IKDNVFNNMCkMbaEyifWzaxR6gX2Xlo+Qo6n3A/Qz6bSjw5LTkIyg
sAx0jmSKWbgpRZl4eYO16DKDwOkGW5zDEhjxQqtRBcyxv7Yndgl+lcP/fPR0oVCT
/gyZOEsFg3ItfUCW5nMnTRWZ6u8D7tSXXVXaqs8b4HB8Nj7jX2WHfkrmT0+i8oMu
eGXITNNOWp827RZHX1uxzoBMQXfHVIZq8FVECAcrCxnzQz4E5zpP3JKTzz9ydpe6
VG49Xs+JsA==
=IHdC
-----END PGP SIGNATURE-----
Merge tag 'mmc-v7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
Pull MMC fixes from Ulf Hansson:
"MMC core:
- Fix RPMB device unregister ordering
- Fix __counted_by handling in mmc_test
MMC host:
- mtk-sd: Document missing clocks for MT8189
- sdhci-esdhc-imx: Fix the support for system suspend/resume for SDIO
- sdhci-of-dwcmshc: Fix error handling for clock prepare/enable
- vub300:
- Fix lockdep issue for the cmd_mutex
- Fix use-after-free on probe failure
MEMSTICK:
- Reject a card that reports too many blocks"
* tag 'mmc-v7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
mmc: sdhci-esdhc-imx: fix resume error handling
mmc: sdhci-esdhc-imx: make non-fatal errors non-blocking in suspend
mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspend
mmc: sdhci-esdhc-imx: disable irq during suspend to fix unhandled interrupt
mmc: sdhci-esdhc-imx: restore pinctrl before restoring ios timing on resume
mmc: sdhci-esdhc-imx: fix esdhc_change_pinstate() to allow default state restore
mmc: sdhci-esdhc-imx: restore DLL override for DDR modes on resume
mmc: sdhci-esdhc-imx: remove unnecessary mmc_card_wake_sdio_irq check for tuning save/restore
mmc: block: fix RPMB device unregister ordering
memstick: ms_block: reject a card that reports too many blocks
dt-bindings: mmc: mtk-sd: Document extra clocks for MT8189
mmc: vub300: defer reset until cmd_mutex is unlocked
mmc: vub300: fix use-after-free on probe failure
mmc: mmc_test: Fix __counted_by handling after kzalloc_flex() conversion
mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe() method
This reverts commit e057b94772.
Sashiko points out that updating 'orig_x0' after secure_computing()
has returned is too late to handle the case where a seccomp filter is
re-evaluated after initially returning SECCOMP_RET_TRACE. This means
that a tracer can manipulate the first argument of the syscall behind
seccomp's back.
For now, revert the initial fix and we'll have another crack at it soon.
Since the incorrect fix was cc'd to stable, do the same here with an
appropriate fixes tag.
Cc: stable@vger.kernel.org
Fixes: e057b94772 ("arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates")
Link: https://sashiko.dev/#/patchset/20260716120640.6590-1-will@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
