| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull more vfs fixes from Christian Brauner:
- inode: Let the shrinker reclaim inodes with I_METADATA_WRITEBACK like
any other clean inode and have evict() write out what the bit tracks
unless the inode is being deleted.
Since v7.3 ext2, ext4 without a journal, fat, udf and minix set
I_METADATA_WRITEBACK when they copy an inode into its buffer and only
fsync() and friends clear it again. inode_lru_isolate() took such
inodes off the LRU expecting something to put them back once the bit
was gone but nothing ever did. So they couldn't be reclaimed until
something fsynced them or the filesystem was unmounted.
On ext4 without a journal an atime update was enough to pin an inode,
and creating 60000 small files in a memory cgroup limited to 96M got
the task OOM killed after about 43000 of them. Now all 60000 get
created.
- dcache:
- Give d_set_mounted() a seqlock of its own that d_invalidate()
waits on after unhashing the dentry.
Since v6.17 d_set_mounted() doesn't bump the seqcount of
rename_lock anymore, so a mount racing d_invalidate() could end
up below the unhashed directory. Nobody can reach it there and it
pins the subtree until the mount namespace goes away. With a FUSE
directory 3000 levels deep 151 of 200 bind mounts racing
FUSE_NOTIFY_INVAL_ENTRY ended up there.
- Only take busy secondary roots off ->s_roots in do_one_tree() so
that umount waits for a racing eviction of an idle one. Since
v7.3 it didn't, which ended in busy inodes after unmount and an
iput() on a dead superblock.
- Make a disconnected dentry a secondary root when the mount on it
goes away so that umount finds it and waits for its eviction.
With CAP_DAC_READ_SEARCH such a dentry can be mounted on via
open_by_handle_at() and move_mount() and umount racing its
eviction ended the same way.
- splice:
- Remove pipe buffer stealing as you and David suggested.
fuse and virtio_console were the only users of ->try_steal() and
now always copy, as they already did when a steal failed.
Stealing took page cache folios out of their files and turned
pages into page cache folios and back. SPLICE_F_GIFT and
SPLICE_F_MOVE are still accepted and fuse still advertises
FUSE_SPLICE_MOVE so servers that ask for it mount as before.
- Clamp a ->write_iter() result that is larger than the iterator in
iter_file_splice_write() instead of only warning about it.
Otherwise the pipe releases buffers past its head.
- ns:
-Allocate the namespace id before calling the namespace_init LSM
hook that was added this merge window. Landlock now logs the
allocated id instead of zero when it denies the creation of a
namespace.
-Don't mark the arguments of the namespace_init and namespace_free
hooks as trusted for bpf LSM programs. Both see namespaces that
are only partially set up or on their way out.
- proc: Don't let proc_sys_call_handler() report more bytes written
than it was passed when a cgroup/sysctl bpf program replaced the
value with a longer one. A splice() into the sysctl file then walked
past the pipe head.
- coda: Pass the append state of each write on to the container file
with RWF_APPEND or RWF_NOAPPEND. coda_open() sets O_APPEND on the
container file after its iocb flags were cached, so an O_APPEND write
overwrote existing data instead of appending.
- adfs: Reject big directory entries in adfs_fplus_getnext() whose name
doesn't fit into the name buffer. A crafted image overflowed it on
the stack.
* tag 'vfs-7.4-rc3.fixes.2' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: (28 commits)
nstree: drop ns_tree_add_raw()
ns: allocate the namespace id before the namespace_init hook
bpf: don't mark namespace_init and namespace_free arguments as trusted
splice: replace nosteal_pipe_buf_ops with default_pipe_buf_ops
splice: remove pipe buffer stealing
fuse: don't move pipe buffers into the page cache
virtio_console: copy pipe buffers in splice_write()
fs/adfs: bound directory entry name length in adfs_fplus_getnext()
dcache: let umount find a disconnected ex-mountpoint
dcache: wait for a racing eviction of a secondary root
dcache: let d_invalidate() wait for a d_set_mounted() in flight
fat: drop mmb_sync() from fat_evict_inode()
udf: drop mmb_sync() from udf_evict_inode()
minix: drop mmb_sync() from minix_evict_inode()
ext4: drop mmb_sync() from ext4_evict_inode()
ext2: drop mmb_sync() from ext2_evict_inode()
fs: don't strand I_METADATA_WRITEBACK inodes outside the LRU
fs: set I_METADATA_WRITEBACK in mmb_mark_buffer_dirty()
udf: don't allocate the inode block in udf_sync_inode_metadata()
minix: don't read the inode block in minix_sync_inode_metadata()
...
|
|
Now that ns_tree_add() doesn't allocate an id anymore it does the same
thing as ns_tree_add_raw(). Switch the remaining ns_tree_add_raw() users
over to ns_tree_add() and drop it. Rename __ns_tree_add_raw() to
__ns_tree_add() while at it.
No functional changes.
Fixes: f675d2e95569 ("lsm: add LSM blob and hooks for namespaces")
Cc: stable@kernel.org # mainline only
Link: https://patch.msgid.link/20261029-work-security-namespace_free-v2-5-65591dbba7b3@kernel.org
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Currently the namespace id is allocated only after __ns_common_init()
has called the namespace_init LSM hook. Most namespace types allocate it
in ns_tree_add() right before the namespace is added to the namespace
trees. So the namespace_init hook always sees an id of zero.
The namespace id is the only identifier of a namespace that is never
recycled. A bpf LSM wants to use it to track a namespace from
namespace_init until namespace_free, e.g., by using it as the key into a
map that associates data with the namespace. The inode number doesn't
work for that as it is quickly recycled.
So allocate the id in __ns_common_init() before calling the
namespace_init hook. Every namespace then has its id by the time it is
added to the namespace trees. The initial namespaces still get their
fixed ids, either statically from NS_COMMON_INIT() or for init_net from
ns_common_init(). So ns_tree_add() doesn't need to allocate an id
anymore. Ids are still handed out in creation order so mnt_ns_loop()
keeps working. Mount and ipc namespaces already allocated their id right
after ns_common_init() anyway.
If creating the namespace fails after the id has been allocated the id
is simply never used.
Landlock logs the namespace id when it denies the use of a namespace.
For a denied namespace creation that used to be zero. Now it's the id
that was allocated for the new namespace. That namespace never becomes
visible to userspace but it's the same id that other LSMs see in
namespace_init. Update the Landlock documentation and selftests
accordingly. The selftests can't know the id of a namespace whose
creation was denied so they only check that it isn't zero.
While at it, drop ns_tree_gen_id() as it has no users left.
Reproducer, 100 user and uts namespaces:
bpftrace -e 'fentry:bpf_lsm_namespace_init {
@[args.ns->ns_id ? "set" : "zero"] = count(); }' &
for i in $(seq 100); do unshare -Uu true; done
before: @[zero]: 200
after: @[set]: 200
Fixes: f675d2e95569 ("lsm: add LSM blob and hooks for namespaces")
Cc: stable@kernel.org # mainline only
Link: https://patch.msgid.link/20261029-work-security-namespace_free-v2-4-65591dbba7b3@kernel.org
Reviewed-by: Mickaël Salaün <mic@digikod.net> # Landlock changes
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
The bpf LSM marks the arguments of all hooks as trusted unless the hook
is listed in untrusted_lsm_hooks. That list was added in commit
c0c852dd1876 ("bpf: Do not mark certain LSM hook arguments as trusted")
for hooks that are called on objects that are only partially set up or
that are already on their way out. The namespace_init and namespace_free
hooks are exactly that but they aren't listed.
namespace_init is called from __ns_common_init() before the namespace
has been set up. It isn't in the namespace trees yet and for all types
but network namespaces even the owning user namespace isn't set yet. If
any LSM rejects the namespace or if anything after ns_common_init()
fails the namespace is freed right away without looking at its reference
count.
namespace_free is called from __ns_common_free() when the namespace is
torn down or when its initialization failed.
Currently there's no kfunc that takes a namespace. But once there is
one, e.g., for namespace local storage, a program could take a reference
to or create storage on a namespace that is about to be freed. So don't
mark the arguments of these hooks as trusted. namespace_install is
called with a reference to a fully set up namespace and stays trusted.
Fixes: f675d2e95569 ("lsm: add LSM blob and hooks for namespaces")
Cc: stable@kernel.org # mainline only
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://patch.msgid.link/20261029-work-security-namespace_free-v2-2-65591dbba7b3@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Nothing calls pipe_buf_try_steal() any more. Remove ->try_steal() from
struct pipe_buf_operations, its implementations and the exported
generic_pipe_buf_try_steal().
PIPE_BUF_FLAG_LRU and PIPE_BUF_FLAG_GIFT were set only for stealing, and
go too. page_cache_pipe_buf_release() did nothing but drop the page and
the LRU flag, so page cache and user page buffers use
generic_pipe_buf_release().
vmsplice() still accepts SPLICE_F_GIFT, and splice() SPLICE_F_MOVE.
Both were hints, and nothing acts on them now.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
Link: https://patch.msgid.link/20261110145241.536019-4-kas@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull probe fixes from Masami Hiramatsu:
"Fix registration and unregistration error handling:
- Release the instruction slot via arch_remove_kprobe() and propagate
the error code when arm_kprobe() fails in
__register_kprobe() instead of leaking the slot and returning 0.
- Skip rethook_free() and kretprobe holder cleanup in
unregister_kretprobes() when __unregister_kprobe_top() fails, and
clear rp->rh after synchronize_rcu() to avoid double free and NULL
pointer dereferences.
- Resolve the target address up-front in register_kretprobe() and
check for re-registration before allocating resources so
symbol_name-based re-registration does not corrupt the active
kretprobe on error.
Fix optprobe state transitions during forced unoptimization:
- Disarm a disabled optprobe in unoptimize_kprobe() when forced
unoptimization moves it directly to a cooling or freeing list, for
preventing breakpoint callback of freed probes.
- Skip disarming unhashed optprobes in the optimizer dispatch path so
a newly registered probe at the same address does not get disarmed
(or have freed module text written to).
- Keep a reused cooling optprobe marked disabled in
reuse_unused_kprobe() so register_aggr_kprobe() or enable_kprobe()
properly arms it, and skip redundant force-unoptimization cleanup
for already-unoptimized cooling probes.
Fix symstr buffer overflow and eprobe triggers:
- Format symstr symbols into a temporary buffer and copy only up to
the reserved field length (updating __data_loc accordingly) to
prevent overwriting the trace record if a probed pointer changes
between sizing and storing passes.
- Install and remove the eprobe event trigger for each trace instance
file that enables the eprobe rather than only on first enable and
last disable, so secondary instances record events and disabled
triggers do not reference freed eprobes.
Replace printk() with trace_printk() in probe handlers:
- Replace printk() and stack_trace_print() with trace_printk() and
trace_dump_stack() in kprobe and fprobe sample modules, and depend
on CONFIG_EVENT_TRACING.
- Document in kprobes.rst and fprobe.rst that calling printk()
directly from probe handlers can deadlock on console or scheduler
locks and recommend trace_printk() instead"
* tag 'probes-fixes-v7.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
kprobes: Arm reused optprobe on cooling list
kprobes: Do not disarm unhashed optprobe on dispatch
kprobes: Disarm disabled optprobe on forced unoptimization
tracing/eprobe: Install the trigger for every instance that enables the eprobe
tracing/probes: bound symstr stores to reserved length
docs: trace: Warn against using printk() in probe handlers
samples/fprobe: Use trace_printk() and trace_dump_stack()
samples/kprobes: Use trace_printk() in probe handlers
kprobes: Validate re-registration earlier in register_kretprobe()
kprobes: Fix double free and NULL deref in unregister_kretprobes()
kprobes: Fix error return and slot leak in __register_kprobe()
|
|
A new probe that reuses an unused probe still on a cooling list doesn't
fire. reuse_unused_kprobe() clears DISABLED, so register_aggr_kprobe()
doesn't arm it and the probe has no int3 until it's optimized again, or
ever if it can't be (e.g., it has a post_handler).
Keep a reused cooling probe disabled instead, so register_aggr_kprobe()
arms it if the new probe is enabled, or enable_kprobe() does it later.
The probe is then still unused when add_new_kprobe() force-unoptimizes
it for a new probe with a post_handler, which would unhash it and queue
it for freeing. Skip that since a cooling probe is already unoptimized.
With the fix, the new probe fires.
Link: https://lore.kernel.org/all/20261105-kprobes-optprobe-state-v2-3-7a2f5290baa0@columbia.edu/
Fixes: 06e0d3b89da1 ("kprobes: Make optprobe optimizer multi-generational and asynchronous")
Suggested-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Mani Tofigh <mt4022@columbia.edu>
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
|
|
A new probe at the address of a force-unoptimized probe can stop
firing. When unoptimize_kprobe() force-unoptimizes an unused probe it
disarms and unhashes it, but the next dispatch disarms it again. If a
new probe was registered at the same address in the meantime, the
second disarm clears the new probe's int3. For a module address the
same disarm would write to freed module text after rmmod.
Skip the disarm for unhashed probes since they're always disarmed before
they're unhashed. With the fix, the new probe fires.
Link: https://lore.kernel.org/all/20261105-kprobes-optprobe-state-v2-2-7a2f5290baa0@columbia.edu/
Fixes: 06e0d3b89da1 ("kprobes: Make optprobe optimizer multi-generational and asynchronous")
Signed-off-by: Mani Tofigh <mt4022@columbia.edu>
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
|
|
A disabled optimized probe can be freed with its int3 still in the
text. It waits on the unoptimizing list for the optimizer to remove its
jump. If another probe is armed on one of the bytes that jump replaced,
unoptimize_kprobe() forces the unoptimization and moves the disabled
probe straight to a cooling list without removing its int3:
Task A (tracefs) Task B (optimizer)
disable k1
/* k1 queued to unoptimize */
/* still on an earlier batch */
enable k2 on a byte k1's jump replaced
unoptimize_kprobe(k1, true)
/* int3 back, k1 on a cooling list */
remove k1
/* k1 freed, int3 left in the text */
The next call into the function then oopses:
[ 9.924313] Oops: int3: 0000 [#1] SMP KASAN NOPTI
[ 9.925627] CPU: 0 UID: 0 PID: 68 Comm: kprobeopt Tainted: G W 7.3.0-17087-gd865f2677c44 #1 PREEMPT
[ 9.930933] RIP: 0010:__do_sys_sysinfo+0x8/0xe0
...
[ 9.949348] Call Trace:
[ 9.949890] <TASK>
[ 9.950404] do_syscall_64+0xfb/0x590
[ 9.952027] entry_SYSCALL_64_after_hwframe+0x77/0x7f
...
[ 9.966436] </TASK>
...
[ 9.968009] Kernel panic - not syncing: Fatal exception in interrupt
Disarm a disabled probe on that path before it goes to the freeing or
cooling list, like do_unoptimize_kprobes() does. With the fix, the int3
is gone by the time the probe is freed.
This bug was identified and confirmed with the help of a deterministic
hypervisor currently under development. The C reproducer below however
hits it within about 10s.
Link: https://lore.kernel.org/all/20261105-kprobes-optprobe-state-v2-1-7a2f5290baa0@columbia.edu/
Fixes: 06e0d3b89da1 ("kprobes: Make optprobe optimizer multi-generational and asynchronous")
Signed-off-by: Mani Tofigh <mt4022@columbia.edu>
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
Pull devm_kmalloc_obj conversion from Kees Cook:
- treewide refresh of kmalloc_obj() conversions
- devm_kmalloc_obj conversion rules added to Coccinelle scripting
- treewide conversion of devm_kmalloc() family to devm_kmalloc_obj()
* tag 'devm_kmalloc_obj-v7.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
treewide: Convert devm_kmalloc() family to the devm_kmalloc_obj() family
coccinelle: kmalloc_obj: Include devm_kmalloc_obj conversion rules
treewide: refresh kmalloc_obj() conversions
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull scheduler fixes from Ingo Molnar:
- Fix this_bw on class change of a dying SCHED_DEADLINE task
(Nickolai Zeldovich)
- Account I/O waits independently of delayed dequeue
(Christian Loehle)
- Clear throttle state when leaving the fair class (Daehyeon Ko)
- Fix u32 truncation of the PELT period count (Hui Su)
- Fix imbalanced cluster static-key updates that can mistakenly
disable cluster-aware scheduling (Hui Su)
- Fix active load balancing logic to ignore non-fair current
in alb_break_llc() (Kayra Cizmeci)
* tag 'sched-urgent-2026-11-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/cache: Ignore non-fair current in alb_break_llc()
sched/topology: Balance cluster static-key updates
sched/pelt: Fix u32 truncation of the PELT period count
sched/fair: Clear throttle state when leaving the fair class
sched/core: Account I/O waits independently of delayed dequeue
sched/deadline: Fix this_bw on class change of a dying task
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf events fixes from Ingo Molnar:
- Fix sideband event output when only requesting attr.defer_output
(Ian Rogers)
- Clamp deferred callchain entry count to fit u16 header.size
(Ian Rogers)
- Various AMD IBS fixes (Ravi Bangoria):
- Reset CPU0 IBS state on syscore resume
- Fix kernel address leak via REGS_USER and REGS_INTR
- Simplify/fix event state handling with IBS_CAPS_DIS
- Revert AUX page allocation order default to be continuous (Leo Yan)
- Don't send SIGTRAP after exec removed the event (Danish Khateeb)
* tag 'perf-urgent-2026-11-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/core: Don't send SIGTRAP after exec removed the event
Revert "perf/aux: Allocate non-contiguous AUX pages by default"
perf/amd/ibs: Simplify event state handling with IBS_CAPS_DIS
perf/amd/ibs: Fix kernel address leak via REGS_USER and REGS_INTR
perf/amd/ibs: Reset CPU0 IBS state on syscore resume
perf/core: Clamp deferred callchain entry count to fit u16 header.size
perf/core: Include perf_event_attr::defer_output in is_sb_event() check
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull locking fixes from Ingo Molnar:
- Fix lockdep message output (Zhuangzhuang Wang)
- Fix OSQ memory ordering bugs, one of which can cause
unlink queue corruption (Peter Zijlstra)
* tag 'locking-urgent-2026-11-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
locking/osq: Fix unlink queue corruption
locking/osq: Switch osq_wait_next()/atomic_cmpxchg() ordering
locking/lockdep: Fix inverted "on"/"last" CPU label in lockdep_print_held_locks()
|
|
The eprobe trigger lives in the instance of the enabling file, but it is
only added when the eprobe is first enabled and only removed when the
last file goes away. A second instance then records nothing, and the
first instance's trigger is left behind once the eprobe is disabled
there, so the eprobe can be deleted while that trigger still uses it.
Add and remove the trigger for each file. The file is never NULL here,
so warn if it is and drop the dead perf paths.
Link: https://lore.kernel.org/all/20261107101233.151434-1-devnexen@gmail.com/
Fixes: 7491e2c44278 ("tracing: Add a probe that attaches to trace events")
Cc: stable@vger.kernel.org
Signed-off-by: David Carlier <devnexen@gmail.com>
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
|
|
Traceprobe calculates dynamic string sizes before storing the values. A
probed pointer can change between those passes, so
fetch_store_symstrlen() can reserve space for a short symbol while
fetch_store_symstring() observes a longer one. The store path then
overwrites the trace record.
Format the symbol into a temporary KSYM_SYMBOL_LEN buffer and copy only
the bytes that fit in the reserved field, including a trailing NUL.
Update __data_loc with the length actually stored so consumers do not
read beyond the truncated value.
Link: https://lore.kernel.org/all/179378621331.55520.2052332247156241151@stu.pku.edu.cn/
Fixes: b26a124cbfa8 ("tracing/probes: Add symstr type for dynamic events")
Signed-off-by: Yifan Zhang <yfzhang23@stu.pku.edu.cn>
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux
Pull printk fixes from Petr Mladek:
- Prevent possible use-after-free when printk kthreads
could not be created
- Fix computation of the free space when allocating a
bigger ring buffer
- Add info about the new printk mailing list for
printk-related subsystems
* tag 'printk-for-7.4-fixups' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux:
printk: Avoid multiple unregistration in unregister_console_locked()
MAINTAINERS: Add new "printk" mailing list for PRINTK, PRINTK INDEXING, and VSPRINTF
printk_ringbuffer: Fix space_used() when blk_lpos->next overflows
|
|
Very similar to commit 50972fe78f24 ("locking/osq_lock: Fix osq_lock
queue corruption"), make sure to order the prev->next store against
the next->prev store.
Fixes: 50972fe78f24 ("locking/osq_lock: Fix osq_lock queue corruption")
Suggested-by: David Laight <david.laight.linux@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Waiman Long <longman@redhat.com>
Cc: linux-kernel@vger.kernel.org
|
|
The atomic_cmpxchg() in osq_wait_next() removes the current CPU's node
from the tail of the queue and puts @old_cpu back.
This is very much like an 'unlock', which is RELEASE, rather than
ACQUIRE.
Additionally, on success (the only case where the ordering is
effective), this returns NULL which means both callsites will do nothing
more, there are no subsequent operations to order against.
Furthermore, the osq_lock() caller will then return false, indicating
failure to acquire -- the mutex must go block. Again, not making a case
for ACQUIRE. Neither atomics nor locks provide ordering on failure.
Since ACQUIRE makes no sense, while RELEASE makes it more symmetric with
osq_unlock(), switch the ordering. This then makes osq_unlock()
consistently RELEASE.
Fixes: c55a6ffa6285 ("locking/osq: Relax atomic semantics")
Suggested-by: David Laight <david.laight.linux@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Waiman Long <longman@redhat.com>
Cc: linux-kernel@vger.kernel.org
|
|
lockdep_print_held_locks()
Commit 051f5d223dfc ("lockdep: Enable the printing of held locks of
remote running tasks and print task CPU") added the task's CPU to the
"locks held by" line. As the comment above the printk() describes, a
running task should be reported as "on CPU#N" and a task that is not
running as "last CPU#N". The ternary has the two strings swapped, so
the labels are inverted.
Swap the strings so the output matches the comment.
Fixes: 051f5d223dfc ("lockdep: Enable the printing of held locks of remote running tasks and print task CPU")
Signed-off-by: Zhuangzhuang Wang <3050681779@qq.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://patch.msgid.link/20261030-lockdep-fix-cpu-label-v1-1-96875c74b15b@qq.com
|
|
Commit d6b9afab44e23 ("sched/cache: Fix
checking active load balance by only considering the CFS task")
stopped using task_util() for non-fair cur.
__active_load_balance_cpu_stop() calls detach_one_task(), that only looks
to cfs_tasks list. So if the rq->curr is not fair, doing a decision
according to it is wrong, since we only migrate tasks that is fair.
Commit f0d243a96f26 ("sched/fair: Avoid creating misfits during
cache-aware balancing") passes cur to task_misfits_asym_cpu()
without checking if the cur is in fair class or not. Fix this.
Fixes: f0d243a96f26 ("sched/fair: Avoid creating misfits during cache-aware balancing")
Signed-off-by: Kayra Cizmeci <kayracizmeci@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Tim Chen <tim.c.chen@linux.intel.com>
Link: https://patch.msgid.link/20261020185402.57017-1-kayracizmeci@gmail.com
|
|
build_sched_domains() increments sched_cluster_active once per newly
built partition that contains an SD_CLUSTER domain.
detach_destroy_domains() instead tested the global static key before
decrementing it, so destroying a cluster-less partition could drop a
reference owned by another partition and disable cluster-aware
scheduling while SD_CLUSTER domains remained installed.
Check the installed domains before detaching them, only while the key is
enabled, and decrement only when the removed partition contains an
SD_CLUSTER domain.
With two cluster-bearing partitions installed, removing a singleton
partition left the baseline count at 1 where 2 partitions still
carried SD_CLUSTER; the fixed kernel correctly reports 2. On an
asymmetric cluster topology where the parent partition gains no
cluster domain, the baseline count drops to 0 while a cluster
partition remains installed; the fixed kernel keeps it at 1.
Fixes: 8881e1639f1f ("sched/fair: Scan cluster before scanning LLC in wake-up path")
Signed-off-by: Hui Su <sh_def@163.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Reviewed-by: Kayra Cizmeci <kayracizmeci@gmail.com>
Link: https://patch.msgid.link/20261021043834.1140951-1-sh_def@163.com
|
|
accumulate_sum() computes the number of elapsed PELT periods in a
u64 but returns u32. When the count is a multiple of 2^32, it is
truncated to zero even though the PELT sums have been updated.
The caller interprets zero as no period boundary crossed and skips
recomputing the averages, leaving *_avg stale relative to *_sum.
Return the period count as u64 so the caller can test it without
truncation.
Fixes: a481db34b9be ("sched/fair: Optimize ___update_sched_avg()")
Signed-off-by: Hui Su <sh_def@163.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
Reviewed-by: Kayra Cizmeci <kayracizmeci@gmail.com>
Link: https://patch.msgid.link/20261023025207.2967903-1-sh_def@163.com
|
|
Task-based CFS bandwidth throttling removes a task's fair sched_entity
while the scheduler core still considers the task queued. p->throttled
carries the fair-specific state across dequeue/enqueue operations.
DEQUEUE_CLASS removes the task from cfs_rq->throttled_limbo_list
but retains the bit. If the last finite CFS quota is disabled while
the task runs in another class, it is absent from the unthrottle walk and
the bit survives.
Returning to fair while cfs_bandwidth_used() is false then performs a real
fair enqueue with p->throttled still set.
After bandwidth is re-enabled, a class-change dequeue treats the
stale bit as limbo state and skips __dequeue_task(). p->se.on_rq therefore
remains set, and put_prev_task_fair() places the entity in the EEVDF tree
while the task moves to RT. On exit, the fair picker can select the
TASK_DEAD task. __schedule() then returns to do_task_dead(),
which hits BUG().
Keep p->throttled across migrations and group moves, but clear it on
DEQUEUE_CLASS because fair-specific state must not outlive fair-class
membership. A later return to fair uses the normal enqueue path. That path
still respects a throttled cfs_rq.
A KASAN, LOCKDEP and DEBUG_LIST v7.3 kernel reproduced the do_task_dead()
BUG in 3/3 root and 3/3 delegated uid-1000 runs with CapPrm=CapEff=0 and
RLIMIT_RTPRIO=1. The fix passed both matrices plus a 3/3 class-switch
control with bandwidth continuously enabled, without a scheduler warning,
KASAN report, lockdep splat or crash.
An AI coding assistant analyzed the state mismatch and drafted the initial
reproducer, fix candidate and this changelog. The source paths, trigger,
controls and results were rechecked against the cited revisions.
Fixes: e1fad12dcb66 ("sched/fair: Switch to task based throttle model")
Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Aaron Lu <ziqianlu@bytedance.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20261022235234.150957-1-4ncienth@gmail.com
|
|
Starting blkio delay accounting and incrementing rq->nr_iowait in
__block_task() ties both to removal from the runqueue. With EEVDF delayed
dequeue, this misses the initial part of an I/O sleep, or the entire
sleep if the task wakes before it is dequeued. Such tasks are also
missing from procs_blocked while their dequeue is delayed. Final dequeue
can run in another task's context, causing delayacct_blkio_start() to
timestamp the wrong task.
Start both forms of accounting in try_to_block_task(), when the current
task commits to blocking, before delayed dequeue or proxy execution can
retain it on the runqueue. End both when clearing is_blocked, including
queued wakeups and the proxy execution paths that let the current task
continue. Checking is_blocked excludes wakeups that precede blocking.
Save the CPU charged at the start of the wait. Delayed tasks can migrate
while still queued, and proxy execution can also move blocked tasks.
Decrement the saved CPU's counter on unblock, regardless of the task's
current placement, and remove the old dequeue-based accounting.
CPU iowait continues to classify idle time using the counter on the
charged CPU; it does not accumulate the full per-task blocked duration.
Closes: https://lore.kernel.org/r/20261014081731.1068794-1-zhanxusheng@xiaomi.com
Fixes: 152e11f6df29 ("sched/fair: Implement delayed dequeue")
Reported-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
Signed-off-by: Christian Loehle <christian.loehle@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
Reviewed-by: Kayra Cizmeci <kayracizmeci@gmail.com>
Link: https://patch.msgid.link/fd8578a1-e60b-4993-ab51-2b5d63abcf77@arm.com
|
|
Moving a SCHED_DEADLINE task out of the class with sched_setscheduler(2)
after it stored TASK_DEAD in do_task_dead(), but before __schedule()
dequeued it, subtracts its bandwidth from the runqueue's this_bw twice.
this_bw then stays short until reboot: __sub_rq_bw() warns about the
underflow or about running_bw > this_bw, and GRUB reclaim for
SCHED_FLAG_RECLAIM tasks on that CPU is miscomputed.
The class change dequeues the still queued task with DEQUEUE_SAVE, which
removes its bandwidth from running_bw and this_bw. switched_from_dl()
then calls task_non_contending(), which, if the 0-lag time has passed,
removes it from this_bw again because the task is TASK_DEAD. That
removal is meant for the dying task's own DEQUEUE_SLEEP dequeue, which
has removed nothing before it.
Do the TASK_DEAD removal only on that dequeue path.
Reproduced under QEMU on x86_64 and riscv64 by moving exiting deadline
tasks to SCHED_OTHER in a loop; with this patch there is no warning.
Fixes: 8fd27231c330 ("sched/deadline: Track the "total rq utilization" too")
Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Juri Lelli <juri.lelli@redhat.com>
Tested-by: Juri Lelli <juri.lelli@redhat.com>
Link: https://patch.msgid.link/20261025124657.836229-1-nickolai@csail.mit.edu
|
|
A sigtrap event must also set remove_on_exec, so that its SIGTRAP never
reaches a program after exec. But the signal is sent from task work,
which only runs on the way back to user space. If the event overflows
shortly before execve(), the task work can still be pending when the
task enters execve(), and then runs when execve() returns. By then
perf_event_exec() has removed the event and the new program has default
signal handlers, so the SIGTRAP kills it.
The exec_stress test in the remove_on_exec selftest catches this and
fails about half the time in a VM. A process that opens a sigtrap event
on itself and then calls execve() is killed by SIGTRAP in 15% to 50% of
runs, both on an AMD machine running v7.2 and in a VM, with or without
close-on-exec on the event fd.
Commit ffb684f2aa14 ("perf: Fix race between perf_event_exit_task() and
perf_pending_task()") made perf_sigtrap() return once
perf_event_exit_task() has set ctx->task to TASK_TOMBSTONE. Exec only
calls perf_event_exit_task() when the new program is not dumpable, such
as a setuid one. An ordinary exec keeps the context and only removes the
remove_on_exec events, so the SIGTRAP is still sent.
perf_event_exit_event() sets PERF_EVENT_STATE_EXIT when exec removes the
event. If the event fd is close-on-exec and was the last reference to
the file, exec also queues the file release as task work. Task work runs
newest first, so perf_release() runs before the SIGTRAP work and moves
the event on to PERF_EVENT_STATE_DEAD. So don't send the signal when the
event state is PERF_EVENT_STATE_EXIT or lower, which means the event has
been removed. That also covers PERF_EVENT_STATE_REVOKED, where the PMU
is gone.
Fixes: 97ba62b27867 ("perf: Add support for SIGTRAP on perf events")
Assisted-by: LLM
Signed-off-by: Danish Khateeb <danishkhateeb03@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20261015152013.106040-1-danishkhateeb03@gmail.com
|
|
This reverts commit 18049c8cff9cc89daadc4df6975f7d9069638926.
The original commit claimed that contiguous AUX pages unnecessarily
exacerbate fragmentation for SPE, TRBE and ETR. This is not generally
valid: larger allocations can keep pages with the same lifetime
together, while order-0 allocations can scatter them across large
blocks and prevent free pages from coalescing [1]. The follow-up
discussion [2] has not established how forcing order-0 allocations
addresses the reported problem.
TRBE and SPE write to virtually addressed buffers. The TRBE L1 TLB
has one entry on Neoverse V2 [3] and two on Neoverse V3 [4]. Small
mappings increase translation pressure, and TTW stalls can contribute
to FIFO overflow and trace loss on TRBE.
Larger allocations provide contiguous, aligned chunks for PMD or
contiguous-PTE mappings with the proposed vmap() support [5].
With the proposed vmap() support already applied, the tests in [2]
showed that preferring larger AUX allocations reduced L2 data TLB
refills by 99.68% in the TRBE test and 34.74% in the SPE test.
Restore the previous policy of trying higher-order allocations first.
The allocator already uses __GFP_NORETRY and falls back to smaller
orders, including order 0, when larger allocations fail.
Remove PERF_PMU_CAP_AUX_PREFER_LARGE, since the restored default
provides that preference. Intel PT retains its existing allocation
behaviour, with no functional change.
[1] https://lore.kernel.org/all/aPjrRkjiIt6HmXmT@casper.infradead.org/
[2] https://lore.kernel.org/linux-arm-kernel/20260810-perf_aux_trace_large_granule-v1-0-03306c9339e3@arm.com/
[3] https://documentation-service.arm.com/static/633fe1ec4c59b30b517730b8#page=52
[4] https://documentation-service.arm.com/static/67361bd2c7fc0d1f211da382#page=54
[5] https://lore.kernel.org/linux-mm/20260715120813.3609949-1-jiangwen6@xiaomi.com/
Signed-off-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: James Clark <james.clark@linaro.org>
Reviewed-by: Dev Jain <dev.jain@arm.com>
Link: https://patch.msgid.link/20261025-perf_revert_prefer_large_alloc-v1-1-5fb431bbd624@arm.com
|
|
IBS hardware captures a sample and raises an NMI. Since the NMI can be
delivered with a delay, a privilege change may occur between sample
capture and NMI delivery. Because IBS only provides the sample RIP, the
kernel records GPRs from the NMI pt_regs, which may reflect kernel mode
if a privilege switch occurred in the interim. This can leak kernel
addresses to unprivileged users through PERF_SAMPLE_REGS_USER and/or
PERF_SAMPLE_REGS_INTR.
Fix this by using interrupt regs while preparing PERF_SAMPLE_REGS_USER
and PERF_SAMPLE_REGS_INTR. With the change, when IBS samples a user mode
instruction but the NMI is delivered in kernel mode, PERF_SAMPLE_REGS_USER
will source its register state from task_pt_regs(current) and
PERF_SAMPLE_REGS_INTR will be omitted from the data sent to userspace.
In addition to fixing the kernel address leak, this change also ensures
GPR snapshot consistency, which resolves the DWARF unwinding issue with
IBS.
Closes: https://lore.kernel.org/r/CAPu-DQqF0aF6=GS8Z6KKWeeX_V5LiXeKU_rJQZC+uGg8zuTPNw@mail.gmail.com
Fixes: d29e744c7167 ("perf/x86: Relax privilege filter restriction on AMD IBS")
Reported-by: Gennady Kupava <gennady.kupava@gmail.com>
Reported-by: Jayapal Ashwin Nair <janair@amd.com>
Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://patch.msgid.link/20261026041838.941-3-ravi.bangoria@amd.com
|
|
In perf_callchain_deferred_output(), if trace->nr is large enough that
sizeof(deferred_event->event) + trace->nr * sizeof(u64) + id_header_size
exceeds U16_MAX, header.size wraps while the output loop still writes
all trace->nr entries into the ring buffer.
Clamp nr per event (accounting for event->id_header_size when
sample_id_all is enabled) so the record never overflows u16 header.size.
Fixes: c69993ecdd4d ("perf: Support deferred user unwind")
Signed-off-by: Ian Rogers <irogers@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://patch.msgid.link/20261025215508.1237480-2-irogers@google.com
|
|
Events configured with attr.defer_output = 1 receive deferred callchain
sideband records (PERF_RECORD_CALLCHAIN_DEFERRED) via perf_iterate_sb().
Include attr->defer_output in is_sb_event() so that such events are
attached to the sideband event list even when no other sideband flags
(such as mmap or comm) are enabled on the event.
Fixes: c69993ecdd4d ("perf: Support deferred user unwind")
Signed-off-by: Ian Rogers <irogers@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://patch.msgid.link/20261025215508.1237480-1-irogers@google.com
|
|
Mirroring the earlier kmalloc_obj() conversion, convert the
device-managed allocators over to the type-based API using the now
updated scripts/coccinelle/api/kmalloc_objs.cocci. The size is derived
from the type rather than written out as a sizeof(), and the result is
a pointer to that type rather than void *, so a mismatch between the
size requested and the variable assigned becomes a build error instead
of being silently accepted.
The conversions break down as:
6713 devm_kzalloc_obj()
1749 devm_kzalloc_objs()
307 devm_kzalloc_flex()
91 devm_kmalloc_objs()
82 devm_kmalloc_obj()
2 devm_kmalloc_flex()
The rules deliberately leave alone allocations sized by a string or a
byte-sized type, or assigned to a pointer to a byte-sized type, since
those are byte buffers rather than objects. Allocations sized by a
multi-byte integer type are only converted when they are assigned to a
pointer to that same type, and allocations of pointers to integers or of
void pointers are left alone too. After this change, 528 files still
call devm_kmalloc(), devm_kzalloc(), devm_kcalloc(), or
devm_kmalloc_array().
Build tested with allmodconfig on x86_64, arm64, i386, arm, riscv, s390,
m68k, mips, parisc, sparc, loongarch, arc, xtensa, and openrisc with GCC
16.2.0 with no new warnings.
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
|
|
Refresh the tree with run of the existing Coccinelle rules in
scripts/coccinelle/api/kmalloc_objs.cocci, now that they also convert
arrays of multi-byte integers.
The conversions break down as:
435 kzalloc_objs()
169 kmalloc_objs()
52 kvzalloc_objs()
47 kzalloc_obj()
42 kvmalloc_objs()
8 kmalloc_obj()
2 kzalloc_flex()
2 kvmalloc_flex()
and 37 existing kmalloc_obj() family calls drop a redundant GFP_KERNEL.
Build tested with allmodconfig on x86_64 with GCC 16.2.0, and, together
with the devm_kmalloc_obj() conversion that follows, on x86_64, arm64,
i386, arm, riscv, s390, m68k, mips, parisc, sparc, loongarch, arc,
xtensa, and openrisc with GCC 16.2.0 with no new warnings.
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mm/core
Pull core memory management fixes from David Hildenbrand:
"Here's a bigger set of MM fixes that we didn't manage to have ready
for -rc1. All fixes are stable-worthy; the majority fixes nasty
long-standing bugs instead of being purely hotfixes.
We have some more of these kinds of stable-worthy fixes in the
pipeline, but we'll focus on the really urgent fixes as we get closer
to the release.
(Leaving urgent MM fixes lurking for various weeks is not good, but
having too many changes close to the release is also not good, it's
tricky ...)
Most issues were reported by Anthropic. Others were found while
reworking proposed fixes, and of course some of the fixes were just
reported and fixed on the mailing list.
All fixes were in linux-next for several days without changes. Some
commit IDs changed recently when I had to drop some non-stable fixes,
rebased to -rc1 and picked up more trailers.
This includes fixes to:
- THP (Transparent Huge Pages)
- GUP (Get User Pages)
- KSM (Kernel Samepage Merging)
- USERFAULTFD
- SHARED MEMORY (shmem/tmpfs/memfd)
- HUGETLB
- Core MM, PAGE CACHE and MEMORY RECLAIM
The main changes are:
- Prevent information leaks through memfd pinning, and out-of bounds
writes in GUP.
- Fix data loss in shmem, THP collapse, KSM and memfd pinning.
- Fix corruption and reference-counting errors with huge PMD/PUD
mappings, and incorrect TLB flushing and unmapping.
- Fix various use-after-free bugs, deadlocks and unkillable loops,
witha a focus on shmem swap handling.
- Fix execution-seal enforcement for memfd (incl. hugetlb).
Other changes fix accounting, quota and userfaultfd (un)registration
handling"
* tag 'mm-core-7.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/core: (61 commits)
mm/gup: check folio->mapping under folio lock in memfd_pin_folios()
khugepaged: fix readahead lock inversion in collapse_file()
mm/huge_memory: set the mmu_gather page size in zap_huge_pud()
mm/memory-tiers: unregister empty tiers outside memory_tier_lock
mm/cma: don't release CMA pages still in use
mm/vma: don't leak the charge for stack growth
mm/huge_memory: split huge PUDs when adjusting VMA boundaries
mm/vma: call ->may_split() before a partial merge
mm/ksm: check large swap-cache folios before mapping them
mm/ksm: fix use of a freed anon_vma at swap-in
mm/ksm: reset the unstable trees of all nodes
mm: fix deadlock of mremap() against UFFDIO_MOVE
mm: fix unkillable fault loop on MAP_DROPPABLE memory
mm: fix unmap_mapping_range() beyond 4 GiB on 32-bit
mm/memory: reject remote COW faults on PFN mappings
mm/madvise: fix data loss from MADV_FREE on a KSM page
mm/mremap: fix moving PUD leaves
mm/mremap: recheck PUDs under the page table lock
mm/mremap: use pudp_huge_get_and_clear() when moving huge PUDs
mm/mmu_notifier: set ->mm only after mmgrab()
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Pull non-MM fixes from Andrew Morton:
"22 patches. 17 are cc:stable.
Most are OCFS2 fixes. These address extended-attribute corruption,
missing attributes and kernel BUGs, along with crashes during cluster
configuration, lock migration, recovery and unmount. Extent movement
is also fixed to validate its range against a stable file size.
Three FAT changes prevent a failed-write/FIBMAP race from spuriously
making the filesystem read-only, correct directory link counts after
rename, and speed up file expansion. The reported QEMU benchmarks show
particularly large improvements on synchronous mounts.
A taint-string fix prevents an out-of-bounds read which can expose
slab contents in the kernel log. There are also build fixes for
OpenRISC modules on CPUs without hardware multiply and for Clang 24"
* tag 'mm-nonmm-hotfixes-stable-2026-11-04-20-26' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (22 commits)
ocfs2: cache the mount context for dentry lock callbacks
ocfs2: wait for filecheck kobject release after a failed add
fat: fix parent link count when replacing a sibling directory
ocfs2/cluster: unlink socket containers before releasing resources
ocfs2: stop recovery before shutting down local allocators
ocfs2/dlm: serialize migration MLE cleanup on failure
panic: zero the dynamically allocated taint buffer
ocfs2: keep locking_state within the cluster connection lifetime
MAINTAINERS: mailmap: use Clément Léger's linux.dev mail address
MAINTAINERS: add an IPC entry
ocfs2: validate move extents against a stable EOF
fat: hold truncate_lock in fat_write_failed()
fat: preallocate space before expanding in fat_cont_expand()
ocfs2: do not read the entry array of an empty xattr block
ocfs2: do not index before the entry array when dividing an empty bucket
ocfs2: do not read the entry array of an empty xattr bucket
ocfs2: find the xattr entry again after converting a block to a bucket
ocfs2: find the xattr entry again after defragmenting a bucket
ocfs2: read the xattr entry hash before defragmenting the bucket
ocfs2/heartbeat: serialize concurrent writes to a region's dev attribute
...
|
|
register_kretprobe() only checked for re-registration if rp->kp.addr was
specified, skipping the check when rp was registered with symbol_name
and rp->kp.addr was NULL. In that scenario, register_kretprobe()
proceeded to allocate a new rethook (or kretprobe holder), and when
register_kprobe(&rp->kp) subsequently failed due to re-registration, the
error path freed and NULL-ed rp->rh (or rp->rph) on the still-active
kretprobe, leading to NULL pointer dereferences when the active probe
was hit.
Resolve the target address via _kprobe_addr() up-front and check whether
the probe is already registered at that address via
check_kprobe_rereg_at() before allocating any resources, and drop the
WARN_ON_ONCE() in the re-registration check now that re-registration is
gracefully detected and rejected.
Link: https://lore.kernel.org/all/179375032568.247640.17429793187163536192.stgit@devnote2/
Fixes: 0188b87899ff ("kretprobe: Avoid re-registration of the same kretprobe earlier")
Cc: stable@vger.kernel.org
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
|
|
In unregister_kretprobes(), if __unregister_kprobe_top() returns an error
(e.g., if the kretprobe was not registered or was already unregistered),
rethook_free(rps[i]->rh) or rcu_assign_pointer(rps[i]->rph->rp, NULL) is
still executed. For rethook-based kretprobes, calling rethook_free() on an
already-freed rethook causes a double-free / list corruption in RCU. For
legacy kretprobes, rps[i]->rph is NULL after previous cleanup, resulting
in a NULL pointer dereference.
Skip rethook_free() and rph cleanup if __unregister_kprobe_top() fails,
and clear rps[i]->rh after synchronize_rcu() has waited for in-flight
pre_handler_kretprobe() invocations to complete.
Link: https://lore.kernel.org/all/179375031660.247640.6349602689169856649.stgit@devnote2/
Fixes: 73f9b911faa7 ("kprobes: Use rethook for kretprobe if possible")
Cc: stable@vger.kernel.org
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
|
|
When arm_kprobe() fails in __register_kprobe(), the probe is removed
from kprobe_table and synchronize_rcu() is executed, but the error code
ret was ignored and try_to_optimize_kprobe(p) was executed, returning 0.
Additionally, the instruction slot allocated by prepare_kprobe() was
leaked.
Fix this by releasing the instruction slot via arch_remove_kprobe(p)
and returning ret when arm_kprobe() fails.
Link: https://lore.kernel.org/all/179375030756.247640.10859474201266455798.stgit@devnote2/
Fixes: 587e8e6d640b ("kprobes: Adopt guard() and scoped_guard()")
Cc: stable@vger.kernel.org
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
|
|
unregister_console_locked() is called from within
hlist_for_each_entry_safe(console_list) loops. This would be safe if
unregister_console_locked() only unregistered the specified console. After
all, that is what the _safe variant is for.
However, unregister_console_locked() calls printk_kthreads_check_locked(),
which can unregister _multiple_ consoles if kthreads fail to start. This
could lead to hlist_for_each_entry_safe() use-after-free scenarios because
not only was the list entry removed, but possibly the following entry as
well (the @n temporary storage of the next entry).
Move the call to printk_kthreads_check_locked() outside of
unregister_console_locked(). Add comments to both functions to clarify
if they are safe to be used in hlist_for_each_entry_safe(console_list)
loops.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/lkml/87ik31iz4x.fsf@jogness.linutronix.de
Fixes: 76f258bf3f2a ("printk: nbcon: Introduce printer kthreads")
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Tested-by: Derek Barbosa <debarbos@redhat.com>
Link: https://patch.msgid.link/20261030135802.663893-1-john.ogness@linutronix.de
Signed-off-by: Petr Mladek <pmladek@suse.com>
|
|
A %s read of print_tainted()'s string can run past the end of the taint
buffer while another CPU rebuilds a longer string in it, reading slab
memory out of bounds into the kernel log (a KASAN slab-out-of-bounds
report at taint_buf + size). A warning or an unhandled-signal dump on
another CPU reaches print_tainted() through dump_stack_print_info().
alloc_taint_buf() sizes the buffer for the longest taint string and
allocates it with kmalloc(), so the bytes past that string are never
written and the object holds no permanent NUL terminator.
_print_tainted() rebuilds the string in place without locking and writes
the terminator last, so a reader that overtakes a writer extending the
string past the previous high-water mark finds no terminator inside the
object and walks off its end. print_tainted()'s kernel-doc promises the
string is "always NULL terminated", a guarantee the previous zero-filled
static buffer kept.
Allocate the buffer with kzalloc() so its trailing bytes stay NUL and
every reader stops inside the object.
Reproduced on QEMU riscv64 under KASAN by growing the taint set while
processes took unhandled-signal dumps on several CPUs: the unpatched
kernel reports a slab-out-of-bounds read at taint_buf + size, the patched
one is clean.
Link: https://lore.kernel.org/20261024020153.830459-1-nickolai@csail.mit.edu
Fixes: a9dff0d0d11c ("kernel/panic: allocate taint string buffer dynamically")
Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Bradley Morgan <brads@mainlining.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Rio <rioo.tsukatsukii@gmail.com>
Cc: <stable@vger.kernel.org>
|
|
Pull bpf fixes from Alexei Starovoitov:
"Fix various bugs in bpf core and bpf-lwt. Looks like the speed of us
fixing bugs is higher than the number of new bugs found. Not out of
the woods yet. sockmap fixes will come later.
- Various fixes (Alexei Starovoitov):
- Use one may_goto time slice per prog invocation instead of one
per stack frame to fix a soft lockup in loops that nest across
calls
- Fix use-after-free in btf__add_type() in libbpf
- Invalidate a dynptr slice when its stack buffer is written or
when the frame of the buffer returns
- Fix the tracking of pointers to the stack in SCEV
- Keep the valid bytes of a packet pointer in SCEV
- Fix bpf_throw() in a prog with a private stack in x86 JIT
- Compare the arguments of an extension prog with those of its
target
- Don't accept memory of the prog for struct arguments of
KF_ACQUIRE kfuncs and for arguments of an empty struct type
- Fix mmap() of an arena: refuse address 0 and a length above
max_entries pages, etc.
- Don't let bpf_skb_adjust_room() raise gso_size to GSO_BY_FRAGS
- Fix lwt progs: reset skb->cb and don't leave a stale MAC header
after a prog pushes an IP header, require BPF_LWT_REROUTE when
an lwt_in prog changes the protocol, don't call into IPv6 when
it is disabled, don't look for the SRH again in the End.BPF
helpers, and set a dst for test runs of lwt_in progs
- Fix bpf_dynptr_copy() for overlapping ranges in one packet
(Ayushman Rout)
- Various fixes (Chris Mason):
- Reject memory of the prog for kfunc projection type arguments
- Require prog fd or capability for cgroup prog detach
- Keep the skb network offset signed in cgroup skb progs
- Reject non-IPv6 packets in BPF_LWT_ENCAP_SEG6
- Limit the SRH length and move the MAC header in
bpf_lwt_seg6_adjust_srh()
- Move the transport header together with the headers that
bpf_skb_adjust_room() and bpf_lwt_seg6_adjust_srh() move, and
use the inner transport header after a decap
- Check the offset in bpf_skb_generic_{push,pop}()
- Mark jmp mode of ftrace direct trampolines on x86 by clearing bit
63 of the address instead of setting bit 0, since an ftrace
callback can start at an odd address (Daniel Borkmann)
- Fix psock update-side data races on sk->sk_prot and progs in
sockmap (Jakub Sitnicki)
- Fix skb_pull() BUG in __bpf_redirect_neigh(): make sure that the
MAC and IP headers are there and are linear (Jamal Hadi Salim)
- Fix jited line info that is off by the CFI preamble on x86-64,
arm64 and riscv64 (Jose Fernandez)
- Clamp the trace length in __bpf_get_stack() to fix a write after
the end of the buffer (Josef Bacik)
- Drop percpu_counter from the htab element count, since its lock can
deadlock with NMI and tracing progs that update the same map
(Puranjay Mohan)
- Propagate scalar precision through stack arguments (Xu Yunxiang)
- Fix callback recursion selftest with llvm24 (Yonghong Song)
- Free the skb when bpf_xmit() fails to expand the headroom (Yuqiang
Sun)"
* tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: (61 commits)
libbpf: Fix use-after-free in btf__add_type
selftests/bpf: Exercise stack argument precision on state reuse
bpf: Propagate scalar precision through stack arguments
selftests/bpf: Fix callback recursion test with noipa global func
selftests/bpf: Test one may_goto time slice per prog invocation
bpf: End bpf_loop() when the time of may_goto is up
bpf: One may_goto time slice per prog invocation
bpf: Pass a pointer to arch_bpf_timed_may_goto()
s390/bpf: Support internal-only MOV instruction to resolve per-CPU addrs
selftests/bpf: End the loop of parallel_test_bitmap after 50 ms
selftests/bpf: Give the first loop of cond_break5 an end
selftests/bpf: Don't cast a pointer to .bss in arena_htab_asm
bpf: Emit timed may_goto for JITed progs only
selftests/bpf: Test writes to the buffer of bpf_dynptr_slice_rdwr()
bpf: Invalidate a dynptr slice when its stack buffer is written
selftests/bpf: Test a callee that overwrites a spilled pointer of its caller
bpf: Don't trust pointers spilled in slots that a callee can write
selftests/bpf: Test the join of fp+0 with a value that is not a pointer to stack
bpf: Fix the join of fp+0 with a value that is not a pointer to stack
selftests/bpf: Run arena_mmap serially and test MAP_FIXED addresses
...
|
|
Outgoing stack arguments retain scalar verifier state separately from
registers and ordinary spills. State comparison uses their precision
marks, but propagate_precision() does not carry those dependencies from
a reused state to the current path's ancestors. A path can consequently
reuse a state without making earlier checkpoints distinguish scalar
values that will later be used as memory offsets.
Seed the existing backtracking batch with precise scalar argument slots
from every frame. Incoming arguments live in the caller's outgoing
slots, so include caller frames as well as the current frame.
Also cover scalar argument slots in bpf_mark_all_scalars_precise(), so
conservative fallback preserves the same invariant. Keep its existing
ancestor-only traversal and leave pointer and uninitialized slots alone.
AI assistance was used in preparing this patch.
Fixes: 0f6bd5e7a804 ("bpf: Support stack arguments for bpf functions")
Signed-off-by: Xu Yunxiang <xyx2021@mail.ustc.edu.cn>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261102190350.788433-2-xyx2021@mail.ustc.edu.cn
|
|
When the time of a prog is up all loops with may_goto end, but bpf_loop()
goes on. It calls its callback up to 1 << 23 times. The loops in the
callback make no iteration, but the rest of the callback runs, and that can
be another bpf_loop(). Two test progs with bpf_loop(1 << 23, cb) and some
work in cb return after 4 sec and 10 sec. With this patch they return after
250 ms.
bpf_loop() and bpf_for_each_map_elem() end their loop when the callback
returns 1. So return 1 in the first insns of the callback when the time is
up:
r0 = address of the count
r0 = &(void __percpu *)(r0)
r0 = *(u64 *)(r0 +0)
if r0 != 0x0 goto pc+2
r0 = 1
exit
The verifier has seen what follows: the loop of the helper can end after
each call of the callback.
A function that BPF code calls too, or that is the callback of another
helper or kfunc, stays as it is: there the return value has another
meaning. The callback of bpf_user_ringbuf_drain() stays as it is too. The
helper takes a sample out of the buffer for each call, so a call that
does nothing loses the sample. Its loop ends after 128K samples.
This patch does not limit bpf_loop() itself. Only may_goto counts and reads
the clock. So nested bpf_loop() are not stopped when the prog has no
may_goto, or has none in the callbacks: bpf_loop(1 << 20, cb) with
bpf_loop(4096, cb2) in cb takes 5 sec. Nested open coded iterators have the
same problem. A follow up will fix these holes.
A call of such a callback executes 4 more insns. The cost on x86-64 (Zen 5)
in nsec:
before after
callback makes 1 iteration, inlined bpf_loop() 1.16 1.54
callback makes 1 iteration, bpf_loop() 6.52 6.74
callback without may_goto, inlined bpf_loop() 1.16 1.16
callback without may_goto, bpf_loop() 4.95 4.95
callback without may_goto, nested bpf_loop() 1.13 1.38
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261031215543.682284-9-alexei.starovoitov@gmail.com
|
|
The count and the timestamp of may_goto are in the stack frame. So the
limit of 250 ms is for one call of a subprog, not for one invocation of the
prog, and loops that nest across calls multiply it. These 9 insns cause a
soft lockup:
main: sub:
1: call sub 1: may_goto 2f
may_goto 2f goto 1b
goto 1b 2: r0 = 0
2: r0 = 1 exit
exit
Use one count and one timestamp for all may_goto of a prog, in per-cpu
memory of the prog. The main prog sets them in its first insns. When the
time is up each loop ends at its next may_goto, in any function.
rX = address of the count
rX = &(void __percpu *)(rX)
r12 = *(u64 *)(rX +0)
if r12 == 0x0 goto target
r12 -= 1
if r12 != 0x0 goto pc+2
r12 = rX
call arch_bpf_timed_may_goto
*(u64 *)(rX +0) = r12
rX is a register that is dead at the may_goto. When all ten are live R0 is
saved in the stack.
An async callback can interrupt the prog on the same cpu. So its caller
sets count and timestamp, and puts the old values back at the end. A second
invocation of the prog on the same cpu gives more time to the first one.
x86-64 (Zen 5), nsec before after
iteration, empty loop 0.36 0.44
iteration, the body takes 4 cycles 0.89 0.89
call of a subprog and 1 iteration 1.21 1.16
The 56 progs of scx with may_goto get 1.7% more JITed code and use 25% less
stack.
Fixes: e723608bf428 ("bpf: Add verifier support for timed may_goto")
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261031215543.682284-8-alexei.starovoitov@gmail.com
|
|
arch_bpf_timed_may_goto() gets the offset of count and timestamp in the
stack frame in BPF_REG_AX. Arch code adds the frame pointer to it, and
calls bpf_check_timed_may_goto() with the result. On arm64, riscv,
loongarch, powerpc and s390 the asm function does it. On x86-64 the JIT
does it, because the frame pointer is in another register when the prog has
a private stack.
The next patch moves count and timestamp out of the stack frame. So pass
the pointer in BPF_REG_AX, and let the verifier emit the addition:
before after
r12 = -16 r12 = r10
call arch_bpf_timed_may_goto r12 += -16
call arch_bpf_timed_may_goto
The JITs know which register r10 is. The asm functions have a move in place
of the addition, and the special case in the x86-64 JIT goes away.
These insns run when the count is used up: in each 65535th iteration. The
cost of an iteration does not change.
Three tests have the insns of may_goto in them. Update them.
Tested on x86-64, and on arm64 and s390 in QEMU. riscv, loongarch and
powerpc are compile tested only.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261031215543.682284-7-alexei.starovoitov@gmail.com
|
|
The timed form of may_goto calls arch_bpf_timed_may_goto(). This function
takes its argument and returns its result in BPF_REG_AX, in a register of
the cpu. Only JITed code can call it.
The verifier emits the timed form when the arch has a JIT that supports it.
It does not look at the prog. With CONFIG_BPF_JIT_ALWAYS_ON=n the
interpreter can run such a prog: the JIT is off, or it fails. The
interpreter calls the function like a helper. The function takes what the C
code left in that register for a pointer, and bpf_check_timed_may_goto()
reads and writes through it.
Emit the timed form only when the prog asks for a JIT, and make the JIT
mandatory for such a prog. All other progs get the form that counts down
from BPF_MAX_LOOPS.
One test of verifier_may_goto_1 shows the insns of the timed form. Load it
only when progs are JITed.
Fixes: e723608bf428 ("bpf: Add verifier support for timed may_goto")
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261031215543.682284-2-alexei.starovoitov@gmail.com
|
|
bpf_dynptr_slice(&ptr, off, buffer, size) and bpf_dynptr_slice_rdwr()
return a pointer to the data of a dynptr. When the data is not contiguous,
for example in a non-linear skb, they copy it to 'buffer' and return
'buffer'. Usually the buffer is on the stack. For the verifier the result
is plain memory (PTR_TO_MEM), and an access through it is not an access to
the stack:
- A store makes wrong what the verifier tracks in the buffer: a known
scalar, a spilled pointer, a dynptr, an iterator, irq flags.
- A load gives the bytes of a spilled pointer or of a dynptr as a scalar.
- Both are possible after the frame of the buffer returned.
The accesses are safe while the buffer contains only unknown bytes, as it
does after the call. Thus keep this rule: the buffer contains no tracked
data while a slice that can be the buffer exists. The slice remembers the
frame, the offset and the size of its buffer. The verifier invalidates the
slice, read-only or not, at each event that breaks the rule:
event slices of the buffer
------------------------------------------------- --------------------
the prog stores to bytes of the buffer invalid
a dynptr, an iterator or irq flags are made there invalid
the frame of the buffer returns invalid
a helper or a kfunc fills the buffer no change
a store next to the buffer, a read of the buffer no change
Tracked data gets into a stack slot in check_stack_write(), also the bytes
of a new dynptr, iterator or irq flags. Thus one call there, and one call
in prepare_func_exit(), are sufficient. Each is one walk over the
registers, only in progs that have such a slice. Helpers and kfuncs leave
only unknown bytes: mark_raw_stack() goes around check_stack_write().
The range of the buffer is in the part of bpf_reg_state that the verifier
copies with the register and compares for pruning. A slice that is the
buffer of a second call passes its range on. Local, ringbuf and skb
metadata dynptrs never return the buffer: no range. A dynptr argument of a
global function counts as an skb dynptr.
The usual pattern only reads the buffer, and it continues to load:
if (p == buffer)
bpf_dynptr_write(&ptr, 0, buffer, sizeof(buffer), 0);
A prog that stores to the buffer and then uses the old slice is rejected:
"R7 invalid mem access 'scalar'". The diagnostics name the reason, and the
log shows the buffer of a slice: R7=mem(sz=8,buf=fp[0]-8+8).
Fixes: 66e3a13e7c2c ("bpf: Add bpf_dynptr_slice and bpf_dynptr_slice_rdwr")
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261102170958.3586893-2-alexei.starovoitov@gmail.com
|
|
arg_track follows pointers to the stack through registers and spills.
Scalar evolution and the removal of dead slots rely on it to know which
slots an insn reads and writes.
arg_track assumes that a call does not change the pointers that are spilled
in the frame of the caller. But a static subprog or a callback can store
a pointer to other memory there, and the caller can use it:
*(u64 *)(r10 - 16) = fp-8
r1 = fp-16, r2 = map_value
call sub ; *(u64 *)(r1 + 0) = r2
r7 = *(u64 *)(r10 - 16) ; verifier: map_value. arg_track: fp-8
*(u64 *)(r10 - 8) = fp-24
*(u64 *)(r7 + 0) = 0 ; arg_track: fp-8 is overwritten
r8 = *(u64 *)(r10 - 8) ; verifier: fp-24. arg_track: none
loop:
r1 = *(u64 *)(r10 - 24) ; the counter of the loop
...
*(u64 *)(r8 + 0) = 4096 ; arg_track: not a write to fp-24
Scalar evolution does not see the last store. It gives the counter the
range of a loop that only increments it. The prog loads, and it accesses
a map value out of bounds.
Valid progs are rejected as well. The store through r7 makes fp-8 dead, and
a later read of fp-8 fails with "slot poisoned by dead code elimination".
When a static subprog or a callback can get a pointer to the frame of its
caller, join every slot of that frame with "not a pointer to the stack".
Reads and possible writes through a filled pointer are still seen, but no
store through it is a certain write. It has to be every slot: the callee
reaches the whole frame from one pointer, and callees are analyzed after
the caller. The price is precision: an 8-byte load through a filled
pointer gives a value that can point to any frame.
For a spilled copy of r10 this needs "bpf: Fix the join of fp+0 with
a value that is not a pointer to stack".
In selftests, Cilium and sched_ext the stack marks change in 4 of 12522
progs. Verdicts, insns and states do not change in any prog.
one_fp_clear_stack_threshold and two_fp_clear_stack_threshold expect the
fake offset fp+0 in the log now.
Fixes: bf0c571f7feb ("bpf: introduce forward arg-tracking dataflow analysis")
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261102055913.3598414-4-alexei.starovoitov@gmail.com
|
|
arg_track follows pointers to the stack through registers and spills.
Scalar evolution and the removal of dead slots rely on it to know which
slots an insn reads and writes.
Where two paths meet, a register can be fp-N on one path and not a pointer
to the stack on the other path. There is no value for that. The join adds
a fake second offset, fp+0: with two offsets no store through the register
is a certain write. But for fp+0 the fake offset is the offset itself:
join(fp-8, none) = {fp-8, fp+0} two offsets
join(fp+0, none) = {fp+0} one offset: "exactly fp+0"
Then a store counts as a certain write to the stack, but at run time it can
go to other memory:
r7 = r10, or r7 = map_value + 8 ; arg_track: exactly fp+0
*(u64 *)(r10 - 8) = fp-24
*(u64 *)(r7 - 8) = map_value ; arg_track: fp-8 is overwritten
r8 = *(u64 *)(r10 - 8) ; fp-24 or map_value. arg_track: none
loop:
r1 = *(u64 *)(r10 - 24) ; the counter of the loop
...
*(u64 *)(r8 + 0) = 4096 ; arg_track: not a write to fp-24
Scalar evolution does not see the last store. It gives the counter the
range of a loop that only increments it. The prog loads, and it accesses
a map value out of bounds.
Valid progs are rejected as well. The store through r7 makes fp-8 dead, and
a later read of fp-8 fails with "slot poisoned by dead code elimination".
When the single offset is 0, drop the offsets. The result is a pointer to
an unknown slot of the frame, and all updates through it are weak.
Veristat sees no difference in selftests, Cilium and sched_ext.
Fixes: bf0c571f7feb ("bpf: introduce forward arg-tracking dataflow analysis")
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261102055913.3598414-2-alexei.starovoitov@gmail.com
|
|
The user range of an arena must not cross a 4 GiB boundary. Thus
arena_get_unmapped_area() asks the mm for 2 * len bytes and rounds the
result up if necessary. This is correct only if the mm finds a free range.
With MAP_FIXED the mm does no search and returns addr. For
MAP_FIXED_NOREPLACE, do_mmap() also sets MAP_FIXED.
With MAP_FIXED the arena is not at addr after round_up(). Thus mmap()
removes mappings outside the range from addr to addr + len. It keeps a part
of those in this range. Also, round_up() can wrap to address 0, and the
test for address 0 is before it.
The arch code gets twice the length of the mapping. Thus it can refuse a
valid MAP_FIXED range. On s390 the arch code also grows the page table for
the range. With the double length it can omit this step for a valid range.
The test for a crossing is not exact. Because ret is a long, ret >> 32
extends the sign, but the other side is unsigned. The sides are never equal
for an address with bit 63 set, and round_up() always runs. Such user
addresses exist on s390. arena_map_alloc() does the same test with a u64.
With MAP_FIXED, pass len to the mm. Return -EINVAL if the range crosses a
boundary, as for address 0. Make ret unsigned, so that only these ranges
get the error. On x86-64, if round_up() gives address 0 today, mmap() now
fails with -EINVAL or with -ENOMEM from the mm. Today mmap() can also fail
for the address after round_up(), for example with -ENOMEM, -EEXIST, -EPERM
or -EBUSY.
Without MAP_FIXED the mm must still find a free range of 2 * len bytes
inside the address space of the task. The range after round_up() is inside
it, and round_up() cannot wrap. An address with bit 63 set now moves only
if its range crosses a boundary.
For an arena, libbpf uses MAP_FIXED only with map_extra, and
arena_map_alloc() refuses a map_extra range that crosses a boundary. A
subsequent mmap() must use the range of the first mmap(). For mmap() of the
map fd, this range comes from arena_get_unmapped_area(), thus it crosses no
boundary. arena_map_alloc() still accepts a map_extra above TASK_SIZE, and
mmap() of such an arena fails.
Fixes: 317460317a02 ("bpf: Introduce bpf_arena.")
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261102064231.2153879-2-alexei.starovoitov@gmail.com
|
|
dup_mm() copies the parent's mm_struct before dup_mmap() takes the
mmap_lock. A concurrent brk() can leave the child with a stale mm->brk
and newer heap mappings, causing later brk() requests to fail.
Other operations (e.g., PR_SET_MM) on the parent's mm_struct can similarly
cause inconsistencies.
As a simple and robust fix, grab the parent's mmap_lock earlier. This
way we don't need to update individual mm fields in dup_mmap() and
keep missing ones. Stop updating the 4 existing members (total_vm, data_vm,
exec_vm, stack_vm), as that is now no longer required.
Keep releasing the parent's mmap_lock in dup_mmap(), before
userfaultfd completion, to avoid moving the userfaultfd handling into the
caller. This should get cleaned up later.
Move uprobe_start_dup_mmap() to preserve the lock ordering.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Reported-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Reviewed-by: Rik van Riel <riel@surriel.com>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Reviewed-by: Barry Song <baohua@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
Reviewed-by: Harry Yoo (Meta) <harry@kernel.org>
Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
Reviewed-by: SJ Park <sj@kernel.org>
Tested-by: Muhammad Usama Anjum <usama.anjum@arm.com>
Link: https://patch.msgid.link/20261031-fixes_core-v3-2-d6437171ecc3@kernel.org
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
|
