mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-11-10 20:48:12 +00:00
1,485,420 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Dmitry Kandybka
|
3110d09bb9 |
tracing: Fix ignored return value of resize_buffer_duplicate_size()
When tr->allocated_snapshot is true, resize_buffer_duplicate_size() is
called to update the snapshot buffer size. However, its return value was
not checked. In case of a failed resize this could lead next snapshot
being incomplete.
Add resize_buffer_duplicate_size() result check and return error if
resize fails.
Compile tested only.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260928152634.4354-1-d.kandybka@gmail.com
Fixes:
|
||
Krystian Kaniewski
|
89bab1dba8 |
ring-buffer: Fix false warning in ring_buffer_map_get_reader()
The mmap reader can warn when it catches up with a writer that is still
committing events. rb_get_reader_page() returns NULL in this case, but
ring_buffer_map_get_reader() treats that result as an error.
The initial rb_per_cpu_empty() check filters out an empty buffer, but it
does not guarantee that the next reader page has committed data. Writers
do not take reader_lock and can advance commit_page before publishing the
committed length on the new page. rb_get_reader_page() can swap to that
page, catch up with the writer and return NULL.
Handle NULL through the existing no-data exit without warning. Remove the
caller's reader_page == commit_page check as well, since the reader-page
helper already handles that case. The existing metadata update and return
path remain in place.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260924084946.20104-1-krystianmkaniewski@gmail.com
Fixes:
|
||
Vincent Donnefort
|
0fa993581a |
tracing: Fix simple_ring_buffer undef check on sparc64
simple_ring_buffer relies on headers that end up including
<asm/thread_info.h>. On sparc64, this emits the undefined symbol
current_thread_info_reg. Allow this symbol.
Link: https://patch.msgid.link/20260923074213.3077182-4-vdonnefort@google.com
Fixes:
|
||
|
Vincent Donnefort
|
ba875c4483 |
tracing: Fix simple_ring_buffer undef check on parisc
simple_ring_buffer uses local_set() and cmpxchg() on unsigned long. Add
them to undefsyms_base.c to extend the allowlist for the parisc
architecture.
Link: https://patch.msgid.link/20260923074213.3077182-3-vdonnefort@google.com
Fixes:
|
||
|
Vincent Donnefort
|
c902b6d709 |
tracing: Fix empty symbol names in simple_ring_buffer undef check
Sparc64 emits empty symmbol names. Skips them when establishing the
allowlist and when extracing undefined symbols.
Link: https://patch.msgid.link/20260923074213.3077182-2-vdonnefort@google.com
Fixes:
|
||
Linus Torvalds
|
db7afcbf9e |
sched_ext: Fixes for v7.3-rc7
- A task that skipped the BPF scheduler on its way back to its CPU's local queue could stall there until the watchdog fired, as the CPU had already decided to go idle. - Use-after-free of a destroyed user dispatch queue by a deferred re-enqueue request. - A task could be moved off a dispatch queue while the dispatching CPU was still running ops.dequeue() on it. - Bypass mode mishandled a sub-scheduler bypass overlapping an ancestor's, as across a system suspend. Descendants could leave bypass mid-teardown and tasks could be stranded on bypass queues. - The idle CPU selection helper could return a CPU outside the allowed CPUs of a pinned or migration-disabled task. -----BEGIN PGP SIGNATURE----- iIQEABYKACwWIQTfIjM1kS57o3GsC/uxYfJx3gVYGQUCatACow4cdGpAa2VybmVs Lm9yZwAKCRCxYfJx3gVYGdEvAP4tfwuDqRpiVDU/69SdALuWdObKorErLg/6uTxE 53qODgEA4Vvao1ZtcxzF3Fd+umA13UgiJ8WBxX66XJDMaxXtiAo= =LtsB -----END PGP SIGNATURE----- Merge tag 'sched_ext-for-7.3-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext Pull sched_ext fixes from Tejun Heo: - A task that skipped the BPF scheduler on its way back to its CPU's local queue could stall there until the watchdog fired, as the CPU had already decided to go idle. - Use-after-free of a destroyed user dispatch queue by a deferred re-enqueue request. - A task could be moved off a dispatch queue while the dispatching CPU was still running ops.dequeue() on it. - Bypass mode mishandled a sub-scheduler bypass overlapping an ancestor's, as across a system suspend. Descendants could leave bypass mid-teardown and tasks could be stranded on bypass queues. - The idle CPU selection helper could return a CPU outside the allowed CPUs of a pinned or migration-disabled task. * tag 'sched_ext-for-7.3-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext: sched_ext: Wait for SCX_OPSS_DISPATCHING before moving tasks off DSQs sched_ext: Rename scx_reenq_wait_dispatching() to scx_wait_dispatching() sched_ext: idle: Respect task affinity in restricted CPU selection sched_ext: Fix the bypass dispatch claim for schedulers bypassed by an ancestor sched_ext: Propagate every bypass depth change to the descendants sched_ext: Fix use-after-free of a destroyed user DSQ by a deferred reenqueue sched_ext: Fix stall when a task enqueued with SCX_ENQ_LAST lands back on its CPU's local DSQ |
||
|
Linus Torvalds
|
e177c722b3 |
pci-v7.3-fixes-5
-----BEGIN PGP SIGNATURE----- iQJIBAABCgAyFiEEgMe7l+5h9hnxdsnuWYigwDrT+vwFAmrP3kgUHGJoZWxnYWFz QGdvb2dsZS5jb20ACgkQWYigwDrT+vzsGxAAsN2M6i1gbFHDljDAOEYJHtKevofh QFEiOUvlqhF/W5n5OFFIcvbnh4zeFYfZsnhkvEGl9/okCyRttUOVnzoddcL+Lep1 ijNA1oE/G0kyZh9uh/QMgMZc2q/+sqeK/hHT11yjIjRIgI6FZ9MiiNM+0q0Z19Yu 2E4dFS4vJxs/sIRz2xnuC3RrOgP1SpTW02GGNbPHw46rZ5XIQtUsolXSeCGF572w 7RByICd86WPtC18IygNWnDLhCgOEX2G2whx+U1XQLKabsntG64qhTOvToJh4cxQI WDYPGEM/6k9ZH9CmkUBga+AqKLIyJDTMM1e/0xDTqn4ZUN5xg1jTc6Wa3iZRK0ql GhT5rgsOg2q32OwABNlgO0DFK13nDaHCrnkwlqVMT1aGSNqVs+hJLKOaoXuttVTb FsE9vWdlFa78rf02h3mX4gQOn5sbadbCZDdg8WEnv5FDV6ihjqgG/c4ZRW+0Ld0v hevnSsZfGzNQndBeaCMj+nHF7j5EONTmMKS5M40WtF8B+//EbTcJC5II4DpugwrC oAiIBNiNC6huqsFxi9YxeRKCH2geNTVdZbRMK75mpQoHS8t4+AmYed5HxBvxG4Le AV7y+1Xsaq1P3LJEZpJkOEs5A0za2l358Ujn9qWDJmWUDxs6irqb6eKjocD8niUO 1iVQVjG/e9REYBA= =VrQ6 -----END PGP SIGNATURE----- Merge tag 'pci-v7.3-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull PCI fixes from Bjorn Helgaas: - Leave ANFE masked on Apple T2 Secure Enclave, which fixes spontaneous poweroff regressions on MacBookPro16,1 and likely other models with the T2 caused by new Advisory Non-Fatal Error support (Jason Perlow) - Move dw-rockchip INTx IRQ setup from rockchip_pcie_host_init(), where it runs after every reset, to the rockchip_pcie_probe() path to avoid installing new IRQ handler (which causes INTx IRQs to be lost) and leaking an IRQ domain on every reset; fixes a regression added this cycle (Shawn Lin) * tag 'pci-v7.3-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI: dw-rockchip: Move INTx IRQ setup to probe PCI/AER: Keep ANFE masked on Apple T2 Secure Enclave |
||
Donggeun Yoo
|
25132363c7 |
ring-buffer: Fix the sub-buffer array base in rb_meta_subbuf_idx()
On a persistent ring buffer, rb_meta_subbuf_idx() can return an index one
sub-buffer too high. rb_setup_ids_meta_page() then fills subbuf_ids[]
shifted by one and leaves subbuf_ids[0] NULL, which __rb_map_vma()
dereferences when userspace maps trace_pipe_raw. rb_update_meta_reader()
writes two such indices into meta->buffers[], which rb_cpu_meta_valid()
would reject on the next boot, discarding the previous boot's trace.
A CPU's sub-buffer array starts after its meta header and the nr_subbufs
integers that follow, aligned up to a sub-buffer. rb_meta_subbuf_idx()
inverts that calculation but skips only the integers, not the header, so
its base is one sub-buffer low whenever the omitted header size crosses
the alignment boundary.
Invert the calculation with rb_subbufs_from_meta() rather than repeating
it. rb_range_buffer() maps an index back to an address through the same
helper, so the two directions can no longer disagree.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260918071507.1019251-1-donggeunyoo.kernel@gmail.com
Fixes:
|
||
|
Donggeun Yoo
|
647c2f97fc |
tracing: Fix the shift out of bounds in the log2 histogram modifier
The .log2 key modifier files a value under its base-2 order:
# echo 'hist:keys=bytes_req.log2' > events/kmem/kmalloc/trigger
hist_field_log2() computes that as ilog2(roundup_pow_of_two(val)). The
out-of-line form of roundup_pow_of_two() is
return 1UL << fls_long(n - 1);
which shifts by 64 on a 64-bit kernel both when n is 0, where n - 1
wraps to ULONG_MAX, and when n is above 2^63. Both are ordinary keys,
because the field fetch hands every value over as a u64: a syscall
argument of 0 reaches the first, and one above 2^63 reaches the second.
Keying sys_enter_lseek on offset.log2 and passing 0, 1, 2, 3, 1000,
2^63+1 and U64_MAX gives
{ offset: ~ 2^1 } hitcount: 1
{ offset: ~ 2^10 } hitcount: 1
{ offset: ~ 2^2 } hitcount: 1
{ offset: ~ 2^0 } hitcount: 4
Keys above 2^63 land in the lowest bucket. With CONFIG_UBSAN_SHIFT=y
the shift is also reported:
UBSAN: shift-out-of-bounds in include/linux/log2.h:57:13
shift exponent 64 is too large for 64-bit type 'long unsigned int'
__ubsan_handle_shift_out_of_bounds.cold+0xdd/0x1cb
hist_fn_call.cold+0x8b/0xd9
event_hist_trigger+0x1cc/0x790
ftrace_syscall_enter+0x197/0x360
do_syscall_64+0x402/0x4b0
Use order_base_2(), which is ilog2(n - 1) + 1 for n > 1 and 0 below
that. It returns what the old expression returned on every input the
old one was defined for. Where it was not, 0 stays in bucket 0, which
is where x86_64 had been putting it, and the keys above 2^63 move into
bucket 64.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260916002735.808520-1-donggeunyoo.kernel@gmail.com
Fixes:
|
||
David Carlier
|
3f23cae09a |
ring-buffer: Do not show buffer_meta for CPUs without a buffer
The per_cpu/cpuN/buffer_meta files are created for every possible CPU,
but buffer->buffers[cpu] is only allocated once that CPU comes online.
Reading the file of a CPU that never came online dereferences a NULL
cpu_buffer in rbm_start().
Fail the open with -ENODEV when the CPU has no buffer, as the other
per CPU ring buffer interfaces do.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260914133506.4865-3-devnexen@gmail.com
Fixes:
|
||
|
David Carlier
|
2afe7575fb |
tracing: Take trace_types_lock when dropping the buffer_meta reference
tracing_buffer_meta_open() drops the trace_array reference with
__trace_array_put() when ring_buffer_meta_seq_init() fails, without
holding trace_types_lock. Use trace_array_put() like every other open
error path.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260914133506.4865-2-devnexen@gmail.com
Fixes:
|
||
|
Donggeun Yoo
|
a0777b9e53 |
tracing: Fix NULL dereference when copying keys for a field variable
In event_hist_trigger_parse() where it needs to create actions like
"onmatch", it calls:
event_hist_trigger_parse() {
create_actions() {
action_create() {
trace_action_create() {
trace_action_create_field_var() {
create_field_var_hist()
Where create_field_var_hist() does a loop on the hist_data
representing the keys. The issue is, if the keys uses one of the
pseudo field types (like common_cpu), the hist_data field element
will have NULL for its field member causing a NULL pointer
dereference when accessing the key_field->field->name.
# echo 'hist:keys=common_cpu:ts0=common_timestamp.usecs' > \
events/sched/sched_waking/trigger
# echo 'my_synth u64 lat; int prio' > synthetic_events
# echo 'hist:keys=common_cpu:wakeup_lat=common_timestamp.usecs-$ts0:\
onmatch(sched.sched_waking).my_synth($wakeup_lat,prio)' > \
events/sched/sched_switch/trigger
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
RIP: 0010:create_field_var_hist+0x771/0x1380
Call Trace:
trace_action_create_field_var+0x360/0x600
trace_action_create+0x393/0xe80
event_hist_trigger_parse+0x3e47/0x69e0
trigger_process_regex+0x1a6/0x250
event_trigger_write+0xce/0x160
Instead of accessing it directly, use the proper handler
expr_field_str() to get the name.
The three previous patches are prerequisites: without them a .buckets
key and a common_stacktrace key each render into a command that cannot
be parsed back.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260914053443.981201-5-donggeunyoo.kernel@gmail.com
Fixes:
|
||
Christian Brauner
|
906f04fb1e |
Merge patch series "namespace: a mount that copy_tree() leaves out can't take over a lock"
Christian Brauner <brauner@kernel.org> says: Since commit |
||
|
Christian Brauner
|
a7064be65f |
Merge patch series "fs: don't let idle threads pin the initramfs"
Christian Brauner <brauner@kernel.org> says:
Since v7.0 nullfs is the real rootfs and userspace can pivot_root() away
from the initramfs and unmount it. systemd does exactly that and the
initramfs is supposed to be freed afterwards. But it isn't (cf. [1]).
The unpacked initramfs stays around forever. It shows up as Unevictable
in /proc/meminfo with ramfs and as Shmem with tmpfs. In the reports
that's between 70MB and 150MB.
Two things keep it alive and neither is visible from userspace:
(1) On v7.0 to v7.2 devtmpfsd unshares a copy of the initial mount
namespace which since nullfs contains the initramfs mount. It
doesn't show up in /proc/<pid>/mountinfo because it's below the
thread's root. That's already fixed in mainline by commit
|
||
|
Christian Brauner
|
eadfe727dd |
selftests/filesystems: test that a mntns file can't take over a lock
Add a case to the locked mount test: - a bind of the mount namespace file of a grandchild moved beneath a locked cover must fail with EINVAL - a bind of an ordinary file beneath it takes the lock over, the old cover can go and the new one can't - the file is still covered after unshare(CLONE_NEWNS) Link: https://patch.msgid.link/20261014-work-namei-locked-mnt_ns_file-v1-2-24035bd5d8e9@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org> |
||
|
Christian Brauner
|
d2bdb9b61b |
fs: let idle threads share init_fs
With nullfs as the real rootfs userspace can pivot_root() away from the
initramfs and unmount it:
chdir(rootfs);
pivot_root(".", ".");
umount2(".", MNT_DETACH);
That's what systemd does and the initramfs is supposed to go away at
that point together with all the memory it uses. But on every machine
with more than one possible cpu the initramfs superblock stays around
forever (cf. [1]). With ramfs as rootfs the unpacked initramfs shows up
as Unevictable in /proc/meminfo, with tmpfs as Shmem, and it is never
freed. In the reports that's between 70MB and 150MB.
The idle threads of the secondary cpus are created by fork_idle() from
smp_init(). That runs in kernel_init(), i.e., in PID 1, after
init_userspace_fs() moved PID 1 from nullfs into the initramfs.
fork_idle() doesn't pass CLONE_FS so each idle thread gets a private
copy of PID 1's fs_struct and with it a reference to the initramfs as
root and as pwd.
pivot_root() relies on chroot_fs_refs() to move everyone whose root or
pwd is the old root over to the new root. Idle threads aren't on the
task list though so chroot_fs_refs() never finds them. They never exit
either. So they keep the initramfs mount and with it the superblock
alive for good. I overlooked this when I added nullfs. Before that the
rootfs could never be unmounted anyway so it didn't matter what pinned
it.
Idle threads are kernel threads and init_task, the idle thread of the
boot cpu, already uses init_fs. So let the idle threads of the other
cpus share init_fs as well instead of copying PID 1's filesystem state.
Note that kernels before 7.3 need a different backport. There PID 1
still shares init_fs with all kthreads so passing CLONE_FS in
fork_idle() is enough. They also have a second pin: devtmpfsd unshares
a copy of the initial mount namespace, initramfs mount included. That
was fixed in commit
|
||
|
Christian Brauner
|
69fbe94f80 |
namespace: a mount that copy_tree() leaves out can't take over a lock
Since commit |
||
|
Christian Brauner
|
98b6cf102b |
namei: test for a negative dentry the way traverse_mounts() does
lookup_fast_for_open() only hands an O_CREAT open a cached dentry if
it's positive. Otherwise the open goes on to lookup_open(), which takes
the directory lock and creates the file. It tests for that with
!dentry->d_inode, but traverse_mounts() later decides with the type in
d_flags. And when a dentry is instantiated __d_set_inode_and_type()
stores ->d_inode first and only then releases the type into ->d_flags.
So a refwalk that took its reference to a negative dentry right before
another task instantiates it can find ->d_inode already set in
lookup_fast_for_open(), go on to step_into(), and still find the
negative type in traverse_mounts(). The open then fails with -ENOENT,
which an O_CREAT open must never do. rcuwalk doesn't get that far, the
d_seq check in step_into() catches the instantiation.
Use d_is_negative() so both look at the type. While the type is still
negative the open takes lookup_open() and waits for the directory lock
like any other O_CREAT open of a negative dentry.
On its own the window is a couple of instructions in the creating task,
so it takes an interrupt or a preempted vcpu in exactly the right spot.
I haven't caught it without help in about 600 million racing O_CREAT
opens.
The debug patch below stalls the creating task between the two stores
for names starting with "ocrace", the way an interrupt landing there
would. The reproducer below opens "ocrace" with O_CREAT through
symlinks on a strictatime tmpfs: following them updates their atime,
which drops the walk out of rcuwalk, so the name is always looked up in
refwalk. With
echo 20 > /proc/sys/fs/ocrace_instantiate_us
./ocreat_enoent -t 60
on a KASAN kernel open() failed with -ENOENT 43 times in 4.9 million
calls. With this patch it never failed in 4.8 million calls. Tracing
step_into_slowpath() during such a run, each of the 98 -ENOENTs it
returned came right after the same task had entered it with a dentry
that was still typed negative.
// SPDX-License-Identifier: GPL-2.0
/*
* ocreat_enoent: open(O_CREAT) racing the creation of the same name.
*
* Writers unlink "ocrace" and create it again. Readers open it with
* O_CREAT through a symlink of their own on a strictatime tmpfs.
* Following the symlink updates its atime, which drops the walk out of
* rcu mode, so the name is always looked up in refwalk. An O_CREAT open
* must never fail with ENOENT.
*
* -p arms a cpu-clock perf timer with that period in ns on every writer,
* so that interrupts land at random points in it.
*
* usage: ocreat_enoent [-t secs] [-w writers] [-r readers] [-p ns]
*/
#define _GNU_SOURCE
#include <errno.h>
#include <fcntl.h>
#include <pthread.h>
#include <stdatomic.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mount.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <unistd.h>
#include <linux/perf_event.h>
#define DIR "/tmp/oc"
static atomic_int stop;
static atomic_long opens, creates, enoent, other;
static long period;
static void die(const char *what)
{
fprintf(stderr, "FATAL %s: %s\n", what, strerror(errno));
exit(2);
}
static void *writer(void *arg)
{
(void)arg;
if (period) {
struct perf_event_attr attr = {
.type = PERF_TYPE_SOFTWARE,
.size = sizeof(attr),
.config = PERF_COUNT_SW_CPU_CLOCK,
.sample_period = period,
};
if (syscall(SYS_perf_event_open, &attr, 0, -1, -1, 0) < 0)
die("perf_event_open");
}
while (!atomic_load(&stop)) {
int fd;
unlink(DIR "/ocrace");
fd = open(DIR "/ocrace", O_CREAT | O_RDWR | O_CLOEXEC, 0644);
if (fd >= 0)
close(fd);
atomic_fetch_add(&creates, 1);
}
return NULL;
}
static void *reader(void *arg)
{
char lnk[64];
snprintf(lnk, sizeof(lnk), DIR "/lnk.%ld", (long)arg);
while (!atomic_load(&stop)) {
int fd = open(lnk, O_CREAT | O_RDWR | O_CLOEXEC, 0644);
if (fd >= 0)
close(fd);
else if (errno == ENOENT)
atomic_fetch_add(&enoent, 1);
else
atomic_fetch_add(&other, 1);
atomic_fetch_add(&opens, 1);
}
return NULL;
}
int main(int argc, char **argv)
{
int secs = 60, nw = 4, nr = 12, c, n = 0;
pthread_t t[256];
while ((c = getopt(argc, argv, "t:w:r:p:")) != -1) {
switch (c) {
case 't': secs = atoi(optarg); break;
case 'w': nw = atoi(optarg); break;
case 'r': nr = atoi(optarg); break;
case 'p': period = atol(optarg); break;
default: return 2;
}
}
if (nw + nr > 256)
return 2;
mkdir(DIR, 0755);
if (mount("oc", DIR, "tmpfs", MS_STRICTATIME, "mode=0755"))
die("tmpfs");
for (long i = 0; i < nr; i++) {
char lnk[64];
snprintf(lnk, sizeof(lnk), DIR "/lnk.%ld", i);
if (symlink("ocrace", lnk))
die("symlink");
}
for (long i = 0; i < nw; i++)
if (pthread_create(&t[n++], NULL, writer, NULL))
die("writer");
for (long i = 0; i < nr; i++)
if (pthread_create(&t[n++], NULL, reader, (void *)i))
die("reader");
sleep(secs);
atomic_store(&stop, 1);
for (int i = 0; i < n; i++)
pthread_join(t[i], NULL);
printf("%ds: %ld opens, %ld creates, ENOENT %ld, other errors %ld\n",
secs, atomic_load(&opens), atomic_load(&creates),
atomic_load(&enoent), atomic_load(&other));
umount2(DIR, MNT_DETACH);
return atomic_load(&enoent) ? 1 : 0;
}
diff --git a/fs/dcache.c b/fs/dcache.c
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -32,9 +32,13 @@
#include <linux/bit_spinlock.h>
#include <linux/rculist_bl.h>
#include <linux/list_lru.h>
+#include <linux/delay.h>
#include "internal.h"
#include "mount.h"
+/* debug: stall "ocrace*" names between ->d_inode and the type */
+static int sysctl_ocrace_instantiate_us;
+
#include <asm/runtime-const.h>
/*
@@ -200,6 +204,13 @@
}
static const struct ctl_table fs_dcache_sysctls[] = {
+ {
+ .procname = "ocrace_instantiate_us",
+ .data = &sysctl_ocrace_instantiate_us,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
{
.procname = "dentry-state",
.data = &dentry_stat,
@@ -405,6 +416,10 @@
unsigned flags;
dentry->d_inode = inode;
+ /* debug: an interrupt landing right here */
+ if (unlikely(READ_ONCE(sysctl_ocrace_instantiate_us)) &&
+ !strncmp(dentry->d_name.name, "ocrace", 6))
+ udelay(READ_ONCE(sysctl_ocrace_instantiate_us));
flags = READ_ONCE(dentry->d_flags);
flags &= ~DCACHE_ENTRY_TYPE;
flags |= type_flags;
Fixes:
|
||
|
Christian Brauner
|
9cd0df397a |
fs: pass flags to copy_fs()
Turn the umh boolean into a flags argument. Idle threads need their own case in copy_fs() as well and that's nicer than a second boolean. No functional changes. Link: https://patch.msgid.link/20261013-work-fs-idle_fs-v1-1-2063d1bcb5aa@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org> |
||
Guanglei Zhu
|
99ae7dc439 |
ovl: reject lowerdir ending with unescaped backslash
In ovl_parse_param_split_lowerdirs() a backslash consumes the character that follows it. When the backslash is the last character of the lowerdir value, it consumes the NUL terminator: the loop exits normally and the backslash is kept in the output, so the lowerdir is passed downstream with a trailing backslash and the mount fails later with a confusing ENOENT from path lookup. A trailing unescaped backslash escapes nothing, so reject it with EINVAL. Signed-off-by: Guanglei Zhu <zhugl3@xiaopeng.com> Link: https://patch.msgid.link/20261012095538.938789-1-zhugl3@xiaopeng.com Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org> |
||
Kyle Zeng
|
36ebddca56 |
fsnotify: prevent mark additions during connector teardown
fsnotify_destroy_marks() keeps a reference to its current mark while it
drops conn->lock to destroy the mark. This stabilizes the forward-walk
cursor, but does not prevent a new mark from being inserted before it.
For example, an inotify watch re-added after IN_IGNORED sorts before the
old, detached mark for the same group. The walk can miss the replacement
and then detach the entire connector from the object.
The replacement is still on its group's marks_list and, for inotify, in
the watch IDR. The group mutex no longer protects the connector's object
from disappearing. An unprivileged fdinfo read racing the final detach
can consequently call igrab(NULL):
BUG: KASAN: null-ptr-deref in igrab+0x24/0x100
Write of size 4 at addr 0000000000000148
Call Trace:
igrab+0x24/0x100
inotify_show_fdinfo+0x1dc/0x5e0
seq_show+0x397/0x690
Set a DESTROYING flag under conn->lock before starting the walk, and
reject new marks on that connector with -ENOENT. The existing add-mark
error paths undo the temporary group-list entry and the backend's watch
allocation. Do not wait for teardown while holding the group mutex,
which the destroyer needs. Once the old connector is detached, an add
can install a fresh connector as before.
This closes the insertion race for all object types using the common
connector teardown, without changing the mark reference or SRCU lifetime
rules.
Fixes:
|
||
|
Christian Brauner
|
40d38f58fc |
Merge patch series "fs: drop the smp_mb()s that mnt_get_count() made redundant"
Christian Brauner <brauner@kernel.org> says:
mntput_no_expire_slowpath() and do_umount() both have an smp_mb()
between taking mount_lock and summing up the reference count. They pair
with the smp_mb() in __legitimize_mnt(). The walker increments the count
and then re-reads the seqcount. The unmounter writes the seqcount when
it takes mount_lock and then sums up the count. They must not both miss
each other's store. That's store buffering and it needs a full barrier
on both sides.
Since
|
||
Aviv Vaknin
|
81933038f5 |
pid_namespace: make zap_pid_ns_processes() freezable
When the init of a pid namespace exits, zap_pid_ns_processes() waits until all other pids in the namespace are freed. A tracer outside the namespace that does not reap its traced zombies keeps those pids allocated, so this wait has no upper bound, and while it lasts every suspend attempt fails: Freezing user space processes failed after 20.006 seconds (2 tasks refusing to freeze, wq_busy=0): Neither wait is freezable. The first loop sleeps in do_wait(), which returns -ERESTARTSYS on the freezer's fake signal; the loop then clears TIF_SIGPENDING and waits again without ever freezing. The final loop sleeps in TASK_INTERRUPTIBLE, and since nothing clears TIF_SIGPENDING there, schedule() returns immediately after the first freeze attempt and the task spins until the wait ends. Sleep in TASK_INTERRUPTIBLE | TASK_FREEZABLE in do_wait(), so that the freezer can freeze tasks waiting there directly, and in TASK_IDLE | TASK_FREEZABLE in the final loop, like coredump_task_exit() does. This was hit with Chromium-based browsers: crashpad ptrace-attaches the threads of a crashed renderer, which is a pid namespace init, and does not reap those killed during the dump. Fixes: |
||
|
Christian Brauner
|
a291a5cf00 |
fs: drop the smp_mb()s that mnt_get_count() made redundant
Both mntput_no_expire_slowpath() and do_umount() have an smp_mb() between taking mount_lock and summing up the reference count. They pair with the smp_mb() in __legitimize_mnt(). A walker in __legitimize_mnt() increments the count and then re-reads the seqcount of mount_lock. The unmounter writes the seqcount when it takes mount_lock and then sums up the count. They must not both miss each other's store. Otherwise the walker keeps a reference to a mount that the unmounter finishes off. That's the store buffering pattern and it needs a full barrier between the store and the load on both sides. In commit |
||
Sung Byeongchan
|
65676cd420 |
autofs: ignore notification errors from a replaced pipe
autofs_notify_daemon() takes a reference to the current notification
pipe under wq_mutex, then drops the mutex before writing the request. The
write can block while the daemon enters catatonic mode and installs a
replacement pipe.
If the old pipe's reader is then closed, the delayed write returns -EPIPE
and the generic error path enters catatonic mode again. That transition
acts on the current superblock state, closes the replacement pipe, and
releases the new daemon generation's wait queues.
Only enter catatonic mode when the pipe which failed is still the current
pipe. Factor the already-locked transition so the identity check and state
change are atomic with respect to another replacement.
This was reproduced on v7.3-rc5-337-gff47652a4b66c in a local QEMU guest.
An unprivileged UID 65534 lookup filled the old packet pipe before a
normal CATATONIC/SETPIPEFD restart. On the unmodified kernel, the new pipe
received HUP and both a pending victim lookup and a later lookup failed
with ENOENT in two out of two fresh-mount runs.
With this change, the new pipe remained active, received an intact
304-byte request, and both victim lookups completed in two out of two
runs. Normal lookup and restart-without-a-blocked-writer controls passed.
No KASAN, oops, refcount, or lock diagnostic was observed. A source
reproducer and complete local logs are available privately on request.
The demonstrated impact is limited to denial of a shared autofs service
during a legitimate daemon restart. No memory corruption, information leak,
privilege escalation, or code execution primitive was observed.
Fixes:
|
||
|
Christian Brauner
|
c68b15ae11 |
Merge patch series "fs: fix a range of UAFs during rcu pathwalk caused by non-rcu frees"
Christian Brauner <brauner@kernel.org> says: While working on eliding the grace period in namespace_unlock() I went through what filesystems free when they're shut down and what a pathwalk in rcu mode can still read at that point. Since 66a97c2ec953's rcu pathwalk fixes that's the filesystem's job. Whatever ->permission(), ->d_revalidate(), ->get_link(), ->d_hash() and ->d_compare() look at in rcu mode has to be freed after a grace period. A few filesystems don't do that. Most of it is hidden by umount(2). namespace_unlock() waits for a grace period before it drops the mounts, so a walker that was inside the filesystem is gone by the time the filesystem is shut down. But the last reference to a mount doesn't have to go away in umount(2). A chdir() out of a lazily unmounted directory or the close() of the last file on it drops it without a grace period. A walker can then still be in the filesystem while ->put_super() and ->kill_sb() free what it reads. With KASAN on vfs.fixes: - ext4_get_link() reads sb->s_fs_info and the extent status counters in rcu mode for a symlink that keeps its target in a data block. ext4_put_super() destroys the counters, clears s_fs_info and frees the sbi right away. That's a NULL dereference, a use-after-free of the sbi or a fault on a destroyed percpu counter, depending on where the walker sits. - The unicode map of casefolded ext4, f2fs and tmpfs is freed from ->put_super() while generic_ci_d_hash() and generic_ci_d_compare() use it. - ntfs3 with nocase frees its sbi and mount options under ntfs_d_hash() and ntfs_d_compare(). A remount frees the old mount options right away too, that one needs no unmount at all. - eventfs frees an eventfs_inode after an SRCU grace period only, but tracefs_d_revalidate() reads it under rcu_read_lock(). No unmount needed either. The ipc patch is a different kind of bug. create_ipc_ns() leaks the mqueue mount and its superblock when it fails after mq_init_ns(). I ran into it while looking at the kern_unmount() users. afs and 9p look just as broken but nothing can reach it today. Both have a private bdi, and generic_shutdown_super() calls bdi_unregister(), which waits for a grace period before ->kill_sb() frees their private data. That grace period is there for the rcu readers of bdi_list and covers afs and 9p by accident. I don't want them to depend on that, so they free their private data after a grace period of their own as well. I appended the reproducers. The race reproducers hold a pathwalk inside the filesystem's callback for two seconds with a kprobe while the other side frees what it reads. For the ntfs3 remount the window is a single load and its dereference, so that one needs an mdelay() in the kernel. ext4 with a journal needs a kernel without lockdep since jbd2_journal_destroy() calls lockdep_unregister_key(), which waits for a grace period too. Clean this all up. * patches from https://patch.msgid.link/20261009-work-fixes-rcu-v1-0-7446d2d335e6@kernel.org: ntfs3: free replaced mount options after a grace period ntfs3: free the sbi after a grace period unicode: free the map after a grace period ipc: drop the mqueue mount with kern_unmount() on setup failure eventfs: free the eventfs_inode after an rcu grace period too 9p: free the session after a grace period afs: free the super info after a grace period ext4: free the sbi after a grace period Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-0-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org> |
||
|
Christian Brauner
|
56c3824de5 |
ntfs3: free replaced mount options after a grace period
ntfs_fs_reconfigure() replaces the old mount options with new mount
options in sbi->options. The old mount options land in fs_context and
are freed as soon as remount returns. With a pathwalk held up in
ntfs_nls_to_utf16() between loading sbi->options and dereferencing it
while a remount replaces them:
BUG: KASAN: slab-use-after-free in ntfs_nls_to_utf16+0x7ae/0x7c0
Read of size 8 at addr ff110001044fd448 by task walker/98
Call Trace:
<TASK>
ntfs_nls_to_utf16+0x7ae/0x7c0
ntfs_d_hash+0x22b/0x500
link_path_walk+0x11ad/0x1d30
path_lookupat+0x63/0xb00
filename_lookup+0x1f1/0x5b0
vfs_statx+0xd7/0x3b0
[...]
Allocated by task 95:
__kmalloc_node_track_caller_noprof+0x2a2/0x730
kmemdup_noprof+0x25/0x50
ntfs_fill_super+0x1e5/0x4550
[...]
Freed by task 97:
kfree+0x1db/0x5b0
put_fs_context+0x13c/0x7d0
path_mount+0x54a/0x2130
__x64_sys_mount+0x20c/0x270
That info is needed in rcu lookup in the dentry hash and dentry compary
methods for ntfs3 and causes a UAF today. Delay freeing with an rcu
grace period.
ntfs_nls_to_utf16() reads ->nls and ->ads once under rcu_read_lock() so
the hooks pair with the release in ntfs_fs_reconfigure(). That also
covers callers outside of rcu pathwalk such as ntfs_lookup(). They don't
hold rcu_read_lock() themselves and wouldn't be protected by the grace
period otherwise. Remount refuses to change the iocharset so ->nls stays
valid after rcu_read_unlock().
Fixes:
|
||
|
Christian Brauner
|
c01b091b06 |
ntfs3: free the sbi after a grace period
If the "nocase" mount option ntfs3 uses custom hash and dentry compare
functions. Both access ntfs3 superblock private information in rcu
pathwalk. ntfs_put_super() and ntfs3_kill_sb() drop the info without any
rcu delay. A lookup that's still inside the filesystem when the last
reference to the mount is dropped causes a UAF. With a pathwalk held up
in ntfs_d_hash() while the last reference to the mount goes away:
BUG: KASAN: slab-use-after-free in ntfs_nls_to_utf16+0x752/0x940
Read of size 8 at addr ff1100010453c850 by task walker/99
Call Trace:
<TASK>
ntfs_nls_to_utf16+0x752/0x940
ntfs_d_hash+0x22b/0x500
link_path_walk+0x11ad/0x1d30
path_lookupat+0x63/0xb00
filename_lookup+0x1f1/0x5b0
vfs_statx+0xd7/0x3b0
[...]
Allocated by task 95:
__kmalloc_cache_noprof+0x249/0x560
ntfs_init_fs_context+0x2db/0x5a0
alloc_fs_context+0x52e/0xc70
[...]
Freed by task 98:
kfree+0x1db/0x5b0
deactivate_locked_super+0x9c/0xf0
cleanup_mnt+0x9f/0x130
task_work_run+0x131/0x250
The bug is currently masked by the grace period in namespace_unlock()
for umount(2). Keep the necessary information until the filesystem
private info is freed and free it with an rcu delay.
ntfs3_free_sbi() now runs from an rcu callback and drops the upcase
table via ntfs_put_shared(). So switch s_shared_lock over to
spin_lock_bh(). Otherwise the callback can deadlock against a task
holding the lock on the same cpu.
Fixes:
|
||
|
Christian Brauner
|
a96c5299bd |
unicode: free the map after a grace period
generic_ci_d_hash() and generic_ci_d_compare() read sb->s_encoding and
dereference the unicode map while a pathwalk in rcu mode holds nothing
but rcu_read_lock(). The filesystems that use them, ext4, f2fs and
tmpfs, drop the map with utf8_unload() from ->put_super(), which runs
when the last reference to the mount goes away. A lookup that is still
inside such a filesystem at that point reads a freed map.
With a pathwalk held up in utf8_casefold_hash() while the last reference
to a casefolded tmpfs goes away:
BUG: KASAN: slab-use-after-free in utf8nlookup+0x74c/0x950
Read of size 8 at addr ff110001030fe658 by task walker/98
Call Trace:
<TASK>
utf8nlookup+0x74c/0x950
utf8byte+0x160/0x1560
utf8_casefold_hash+0x167/0x230
generic_ci_d_hash+0xdd/0x1c0
link_path_walk+0x11ad/0x1d30
path_lookupat+0x63/0xb00
filename_lookup+0x1f1/0x5b0
vfs_statx+0xd7/0x3b0
[...]
Allocated by task 94:
__kmalloc_cache_noprof+0x249/0x560
utf8_load+0x4e/0x570
shmem_parse_opt_casefold.isra.0+0x92/0x270
[...]
Freed by task 97:
kfree+0x1db/0x5b0
shmem_put_super+0x72/0x170
generic_shutdown_super+0x14c/0x530
kill_anon_super+0x3a/0x60
deactivate_locked_super+0x9c/0xf0
cleanup_mnt+0x9f/0x130
So far that has been hard to hit. umount(2) waits for a grace period
in namespace_unlock() before it drops the mount, so only a mount whose
last reference goes away elsewhere, like the close of a file or a chdir
out of a lazily unmounted directory, can race a walker. So it is
reachable.
Delay the free until a grace period has passed. The map and the data
table it holds a reference to then outlive any pathwalk that found the
superblock before the mount went away. The reference on the data table
module is dropped from the rcu callback as well. utf8-core is built in
whenever CONFIG_UNICODE is set, so there is no module exit that would
have to wait for the callbacks.
Overlayfs points the s_encoding of an overlay at the map of its first
layer without taking a reference of its own. That stays correct. The
layer is held by the overlay, so its map is dropped only after the
overlay is gone.
Fixes:
|
||
|
Christian Brauner
|
f0e48172a5 |
ipc: drop the mqueue mount with kern_unmount() on setup failure
mq_init_ns() creates the mqueue mount with fc_mount_longterm(), so its ->mnt_ns is MNT_NS_INTERNAL. When setting up the mqueue or ipc sysctls or msg_init_ns() fails afterwards, create_ipc_ns() drops it with a plain mntput(). With ->mnt_ns set that takes the fast path of mntput_no_expire(). The count drops to zero and nothing ever kills the mount, so the mount and the mqueue superblock are leaked. Commit |
||
|
Christian Brauner
|
6e6928b396 |
eventfs: free the eventfs_inode after an rcu grace period too
tracefs_d_revalidate() reads ->is_freed of the eventfs_inode that dentry->d_fsdata points to, and ->d_revalidate() is called in rcu pathwalk mode with nothing but rcu_read_lock() held. The dentry itself stays around for such a walker, but tracefs_d_release() drops its reference to the eventfs_inode when the dentry is killed, and release_ei() then frees it after a grace period of eventfs_srcu. An SRCU grace period doesn't wait for rcu_read_lock() sections, so the walker can read an eventfs_inode that is already gone. With a pathwalk held up in tracefs_d_revalidate() while the dentry goes away: BUG: KASAN: slab-use-after-free in tracefs_d_revalidate+0x76/0x90 Read of size 1 at addr ff1100010152d8d0 by task walker/97 Call Trace: <TASK> tracefs_d_revalidate+0x76/0x90 lookup_fast+0x320/0x640 path_lookupat+0x160/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 vfs_fstatat+0x4d/0x90 __do_sys_newfstatat+0xa0/0x100 do_syscall_64+0x10e/0x5e0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [...] Allocated by task 1: __kmalloc_cache_noprof+0x249/0x560 eventfs_create_dir+0x7a/0x590 event_create_dir+0x2fb/0xcf0 trace_add_event_call+0xbf/0x150 [...] Freed by task 11: kfree+0x1db/0x5b0 srcu_invoke_callbacks+0x3a3/0x620 process_one_work+0x937/0x1810 worker_thread+0x4f1/0xd60 Before commit |
||
|
Christian Brauner
|
bcec7fc2e2 |
9p: free the session after a grace period
v9fs_vfs_get_link_dotl() reads ->cache from the v9fs_session_info in
sb->s_fs_info to decide whether the symlink target sits in the page
cache. It does that before it looks at the dentry, so it also does it in
rcu pathwalk mode. Without loose or metadata caching the dentries have
no ->d_revalidate() that would make the walk leave rcu mode before it
gets there.
v9fs_kill_super() frees the session and clears sb->s_fs_info without
waiting for a grace period. Right now a pathwalk can't still be in
v9fs_vfs_get_link_dotl() at that point, but only by accident. umount(2)
waits for a grace period in namespace_unlock() before it drops the
mount. And a mount whose last reference goes away elsewhere, like the
chdir out of a lazily unmounted directory, still gets a grace period
from bdi_unregister(). v9fs_fill_super() sets up a private bdi, so
generic_shutdown_super() unregisters it from kill_anon_super() and
bdi_remove_from_list() waits in synchronize_rcu_expedited() before
v9fs_kill_super() frees the session. That grace period protects the rcu
readers of bdi_list in the writeback code. It has nothing to do with
pathwalk.
Don't rely on it. Keep sb->s_fs_info and free the session after a grace
period.
Fixes:
|
||
Cen Zhang (Microsoft)
|
5e531d62f1 |
watch_queue: Fix note pool publication race in watch_queue_set_size()
There is a race between watch_queue_set_size() and post_one_notification().
watch_queue_set_size() publishes wqueue->notes, notes_bitmap, nr_pages and
nr_notes with plain stores, and post_one_notification() reads them with
plain loads under a different lock, so nothing orders the four stores
against the poster's loads: depending on the build, notes can be stored
last (gcc 14 on x86-64 does this). Since keyctl_watch_key() lets a watch
attach to a queue before it is sized, post_one_notification() can already
be running on another CPU at that moment: it reads nr_notes > 0, passes
its bounds check, and then reads notes while it is still NULL,
dereferencing notes[0].
An unprivileged user triggers this reliably by watching one of its own
keys through a notification pipe and racing ioctl(IOC_WATCH_QUEUE_SET_SIZE)
on that pipe against keyctl(KEYCTL_SETPERM) on the key from another CPU,
triggering:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:post_one_notification.isra.0+0xa2/0x1e0
Call Trace:
__post_watch_notification+0x148/0x180
keyctl_setperm_key+0x119/0x130
do_syscall_64+0x108/0x4c0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Kernel panic - not syncing: Fatal exception in interrupt
Fix this by publishing nr_notes last with smp_store_release(), and by
reading it once with smp_load_acquire() in post_one_notification() before
the bitmap and the page array are touched. A poster that observes a
non-zero nr_notes then also observes the pool behind it; one that observes
zero drops the notification as before.
Fixes:
|
||
|
Christian Brauner
|
59e483739f |
afs: free the super info after a grace period
afs_atcell_get_link() resolves the @cell and .@cell symlinks of a
dynamic root in rcu pathwalk mode. Before it looks at the dentry it gets
the afs_net through afs_i2net(), which reads ->net_ns from the
afs_super_info in sb->s_fs_info. The @cell dentries are kept around when
unused and the dynamic root has no ->d_revalidate(), so a lookup that
finds @cell in the dcache gets to ->get_link() in rcu mode.
afs_kill_super() frees the afs_super_info with a plain kfree() in
afs_destroy_sbi(). Right now a pathwalk can't still be in
afs_atcell_get_link() at that point, but only by accident. umount(2)
waits for a grace period in namespace_unlock() before it drops the
mount. And a mount whose last reference goes away elsewhere, like the
chdir out of a lazily unmounted directory, still gets a grace period
from bdi_unregister(). afs_fill_super() sets up a private bdi, so
generic_shutdown_super() unregisters it from kill_anon_super() and
bdi_remove_from_list() waits in synchronize_rcu_expedited() before
afs_destroy_sbi() runs. That grace period protects the rcu readers of
bdi_list in the writeback code. It has nothing to do with pathwalk.
Don't rely on it and free the afs_super_info after a grace period.
Fixes:
|
||
|
Kyle Zeng
|
40bb03d3ea |
pipe: preserve existing fasync readers on writer setup failure
F_SETFL and FIOASYNC decide whether to invoke ->fasync() before
pipe_fasync() takes pipe->mutex. Two enables of one O_RDWR FIFO can
therefore both enter the callback.
fasync_helper() allocates before checking for an existing entry. If the
first enable installs both entries, a second enable can update the
reader entry and then fail the allocation for the writer entry. The
error path removes the pre-existing reader entry, clearing FASYNC while
the writer entry remains registered. __fput() then skips ->fasync(), so a
later pipe notification can dereference the freed file or its f_owner.
An unprivileged memory-pressure reproducer triggers a KASAN
slab-use-after-free in send_sigio() through this path.
Keep the reader helper's result and undo the registration only if this
call added it. The pipe mutex serializes changes to both lists, so a
failed new registration still removes its reader, while a failed
duplicate preserves the existing registrations and FASYNC. Successful
duplicate enables continue to update fa_fd as before.
Fixes:
|
||
|
Christian Brauner
|
c17b44266a |
ext4: free the sbi after a grace period
ext4_get_link() follows a symlink that keeps its target in a data block
in rcu pathwalk mode with ext4_getblk(EXT4_GET_BLOCKS_CACHED_NOWAIT).
That reads s_mount_state in the ASSERT() of ext4_getblk() and again in
ext4_es_lookup_extent(), and the lookup bumps the extent status hit or
miss counter, all through sb->s_fs_info.
ext4_put_super() destroys those counters, clears sb->s_fs_info and frees
the sbi without waiting for a grace period. A pathwalk that is still in
ext4_get_link() when the last reference to the mount goes away then
dereferences a NULL s_fs_info, the freed sbi or the destroyed percpu
counters.
With a pathwalk held up in ext4_get_link() while the last reference
goes away:
KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af]
RIP: 0010:ext4_getblk+0xf0/0x640
Call Trace:
<TASK>
ext4_get_link+0x26c/0x410
pick_link+0xf96/0x1780
step_into_slowpath+0x9b8/0x1250
path_lookupat+0x484/0xb00
filename_lookup+0x1f1/0x5b0
vfs_statx+0xd7/0x3b0
vfs_fstatat+0x4d/0x90
__do_sys_newfstatat+0xa0/0x100
do_syscall_64+0x10e/0x5e0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
So far that has been hard to hit. umount(2) waits for a grace period in
namespace_unlock() before it drops the mount, so only a mount whose last
reference goes away elsewhere, like the close of a file or a chdir out of
a lazily unmounted directory, can race a walker.
Keep sb->s_fs_info and free the sbi together with the extent status
counters after a grace period. Split the counters out of
ext4_es_unregister_shrinker() for that. The shrinker still gets wasted
in ext4_put_super(), the counters go with the sbi.
Fixes:
|
||
Nickolai Zeldovich
|
28d2905d77 |
exit: fix lost-update race on the child_subreaper bitfields
is_child_subreaper, has_child_subreaper, autoreap and, with
CONFIG_POSIX_TIMERS=y, timer_create_restore_ids are 1-bit fields that
share one memory location in struct signal_struct. A store to any of
them is a read-modify-write of the whole word, and three of the stores
run without a common lock:
- PR_SET_CHILD_SUBREAPER writes me->signal->is_child_subreaper with
no lock held.
- propagate_has_child_subreaper(), run by walk_process_tree() from
the same prctl in an ancestor, writes p->signal->has_child_subreaper
of every descendant p under read_lock(&tasklist_lock), which does
not exclude the other writers.
- PR_TIMER_CREATE_RESTORE_IDS writes
current->signal->timer_create_restore_ids with no lock held.
When a process calls prctl(PR_SET_CHILD_SUBREAPER, 1) while an
ancestor's PR_SET_CHILD_SUBREAPER walk visits it, or while another
thread of the same process calls prctl(PR_TIMER_CREATE_RESTORE_IDS),
the read-modify-write sequences interleave and one of the bits is
silently lost:
- If has_child_subreaper is lost, the process's orphaned descendants
are reparented straight to init when it exits: find_new_reaper()
tests father->signal->has_child_subreaper first and never looks for
the ancestor subreaper. The service manager that registered as the
subreaper never gets SIGCHLD for them and cannot wait() on them.
- If is_child_subreaper is lost, the prctl returned 0 but the process
is not a subreaper: orphans of its descendants skip it and are
reparented to the next subreaper up or to init.
PR_GET_CHILD_SUBREAPER reads back 0.
- If timer_create_restore_ids is lost, the prctl returned 0 but
timer_create() does not restore the requested timer ids (or keeps
restoring them after _OFF), and _GET reads back the old value.
Documentation/memory-barriers.txt requires all fields of one bitfield
to be protected by one lock for exactly this reason. No lock is taken
or documented for these flags, and the prctls need no privilege, so any
process can hit the race against its own ancestors or descendants, or
between two of its own threads.
Make is_child_subreaper and has_child_subreaper separate bool members.
Each store then has its own memory location and no read-modify-write
of a neighbour. The readers and their locking are unchanged.
autoreap stays a bit-field and so shares a memory location only with
timer_create_restore_ids. That pair is race-free: autoreap is stored
exactly once, in copy_process() before the new signal_struct is
reachable by any other task, and timer_create_restore_ids is only
stored to the signal_struct of an already running process.
Fixes:
|
||
Sasha Levin
|
f1365f97fb |
samples: pidfd: fix userprogs typo
The Makefile adds pidfd-metadata to "usertprogs-always-y", which kbuild
does not know, so the sample has not been built since the conversion to
userprogs, even with CONFIG_SAMPLE_PIDFD=y.
Fix the variable name. pidfd-metadata.c builds without warnings with
gcc and clang for x86_64 and arm64.
Fixes:
|
||
Cen Zhang
|
4c43582893 |
ocfs2/dlm: Protect the recovery list during debugfs reads
Recovery participant records must remain alive while debug_state_print()
walks reco.node_data and formats their fields. The formatter holds
dlm->spinlock, but the recovery participant list is protected by
dlm_reco_state_lock. In particular, dlm_destroy_recovery_area() detaches
the list under dlm_reco_state_lock and frees the detached records after
releasing it. A concurrent debugfs open can therefore read freed memory.
Protect the participant traversal and field reads in debug_state_print()
with dlm_reco_state_lock, matching the existing list writers. This also
serializes the traversal against list_add_tail() during recovery-area
initialization. Make the existing lock available to the debug code
through dlmcommon.h; the lock remains internal to the OCFS2 DLM module.
Release dlm->spinlock after formatting the other domain state and before
acquiring dlm_reco_state_lock, so the debug reader does not nest the two
locks. Leave recovery list insertion, detachment and freeing unchanged.
KASAN report as below:
BUG: KASAN: slab-use-after-free in debug_state_open+0x1169/0x12d0
Read of size 4 at addr ffff88810662ef80 by task dlm-state-stres/896
CPU: 1 UID: 0 PID: 896 Comm: dlm-state-stres Not tainted 7.3.0-rc4-next-20260921-pmb-ocfs2-functional-v1+ #1 PREEMPT(lazy)
Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x93/0xd0
print_report+0xce/0x630
? debug_state_open+0x1169/0x12d0
? srso_alias_return_thunk+0x5/0xfbef5
? __virt_addr_valid+0x20e/0x420
? debug_state_open+0x1169/0x12d0
kasan_report+0xe0/0x110
? debug_state_open+0x1169/0x12d0
debug_state_open+0x1169/0x12d0
? __pfx_debug_state_open+0x10/0x10
full_proxy_open_regular+0x193/0x310
do_dentry_open+0x595/0x12d0
? __pfx_full_proxy_open_regular+0x10/0x10
vfs_open_consume+0xd1/0x400
? srso_alias_return_thunk+0x5/0xfbef5
path_openat+0x18d0/0x2020
? __pfx_path_openat+0x10/0x10
do_file_open+0x21e/0x470
? __pfx_do_file_open+0x10/0x10
? _raw_spin_unlock+0x23/0x40
? srso_alias_return_thunk+0x5/0xfbef5
? alloc_fd+0x3a6/0x6b0
do_sys_openat2+0xf4/0x1b0
? __pfx_do_sys_openat2+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
? __fput+0x5b5/0xa60
__x64_sys_openat+0x136/0x1e0
? __pfx___x64_sys_openat+0x10/0x10
do_syscall_64+0x114/0x620
entry_SYSCALL_64_after_hwframe+0x77/0x7f
[Register dump omitted.]
</TASK>
Allocated by task 880:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
__kasan_kmalloc+0xaa/0xb0
__kmalloc_cache_noprof+0x28d/0x610
dlm_remaster_locks+0x147/0x1d90
dlm_do_recovery+0xde1/0x1580
dlm_recovery_thread+0x109/0x300
kthread+0x351/0x460
ret_from_fork+0x659/0x940
ret_from_fork_asm+0x1a/0x30
Freed by task 880:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x5f/0x80
kfree+0x308/0x580
dlm_destroy_recovery_area+0x285/0x460
dlm_remaster_locks+0x17c4/0x1d90
dlm_do_recovery+0xde1/0x1580
dlm_recovery_thread+0x109/0x300
kthread+0x351/0x460
ret_from_fork+0x659/0x940
ret_from_fork_asm+0x1a/0x30
The buggy address belongs to the object at ffff88810662ef80
which belongs to the cache kmalloc-32 of size 32
The buggy address is located 0 bytes inside of
freed 32-byte region [ffff88810662ef80, ffff88810662efa0)
[Page and memory-state dumps omitted.]
Fixes:
|
||
Erik Faye-Lund
|
c347fef5f8 |
drm/panthor: fix immortalis condition
Exactly 10 cores is also valid for an Immortalis configuration,
according to the public documentation:
https://support.arm.com/compute-ip/immortalis-g715
So let's report this G715 with 10 cores as Immortalis as well, as long
as it supports the ray-intersection feature. This matches what we do for
more recent GPUs as well.
Fixes:
|
||
|
Linus Torvalds
|
0fcb05b723 |
Crypto library fixes for 7.3-final
Fix two Poly1305 bugs including a lost carry bit, and add a regression test. -----BEGIN PGP SIGNATURE----- iIoEABYIADIWIQSacvsUNc7UX4ntmEPzXCl4vpKOKwUCas92XxQcZWJpZ2dlcnNA a2VybmVsLm9yZwAKCRDzXCl4vpKOKzlqAP9wGX5K4F95NgzPhJ/AG0Ze5aEiRzbR Bay8csFZoftMoQEA2LipJ8lmHFrvOHwIiiUP/d3LWWXiEYaq4+y0R7CYXwo= =CmWW -----END PGP SIGNATURE----- Merge tag 'libcrypto-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux Pull crypto library fixes from Eric Biggers: "Fix two Poly1305 bugs including a lost carry bit, and add a regression test" * tag 'libcrypto-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: lib/crypto: tests: Add Poly1305 split-update carry regression test lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON state lib/crypto: poly1305: Use memzero_explicit() in poly1305_final() |
||
Dnyaneshwar Bhadane
|
6a8bf59de3 |
drm/i915/cx0_phy: Fix ARL-S host bridge detection
Fix is_arrowlake_s_by_host_bridge() which always returned false.
The while loop always exits with pdev as NULL, so the return
condition was always false, causing the wrong tx_misc value to be used.
Check the host bridge ID inside the loop body. Once found early exit
from the loop release the pci reference "pdev" and return true.
v2:
- Update commit message (Chaitanya)
Bspec:74165,74491
Suggested-by: Jani Nikula <jani.nikula@intel.com>
Cc: <stable@vger.kernel.org>
Fixes:
|
||
Dibin Moolakadan Subrahmanian
|
7dedc5bb11 |
drm/i915/dmc: Add sanity check for DMC load address
For DMC firmware header version 3, the firmware load address is stored
in dmc_info->start_mmioaddr and later used by dmc_load_program().
Unlike the MMIO address table, the firmware load address is not
validated. Add a sanity check to ensure it is within the valid range.
BSpec: 69671, 68378
Fixes:
|
||
|
Dibin Moolakadan Subrahmanian
|
8bb1858db4 |
drm/i915/dmc: Harden DMC firmware payload parsing
Validate the conversion of the DMC firmware size from dwords to bytes
using check_mul_overflow() before calculating the firmware payload size.
Reject zero-length payloads and zero MMIO counts in the DMC firmware
header so malformed firmware is caught early. Also set dmc_fw_size only
after the payload allocation succeeds.
Fixes:
|
||
Amirmohammad Eftekhar
|
c8f4cfe1cf |
KVM: nVMX: Reset MMU back to the root MMU if loading L2 state fails for !VM-Entry
Reset the vCPU's MMU pointer back to the root MMU if loading L2 state fails in the "not from VM-Entry" case, i.e. when emulating RSM or handling KVM_SET_NESTED_STATE. Failure to unwind the MMU pointer results in KVM trying to run L1 with a nested MMU, and is especially problematic if the vCPU manages to free its nested state before the VM crashes. Constructing the root for a nested EPT MMU goes through vmcs12, which is dynamically allocated/freed when nVMX is enabled/disabled. And so if the nested state is freed with the MMU still pointing at the nested MMU, KVM will hit a NULL pointer deref when attempting to get L1=>L2 EPTP. BUG: kernel NULL pointer dereference, address: 0000000000000078 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 114a2d067 P4D 111743067 PUD 11141f067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 20 UID: 1000 PID: 1272 Comm: nested_tdp_faul Not tainted 7.3.0-rc4-8c89f11d1a99b-sink-vm #1914 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:nested_ept_get_eptp+0xb/0x10 [kvm_intel] Call Trace: <TASK> kvm_mmu_load+0xcd/0x870 [kvm] kvm_arch_vcpu_ioctl_run+0x18f5/0x1f80 [kvm] kvm_vcpu_ioctl+0x2c7/0x970 [kvm] __x64_sys_ioctl+0x90/0xd0 do_syscall_64+0x9c/0x4d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x47491b </TASK> Modules linked in: kvm_intel kvm irqbypass CR2: 0000000000000078 ---[ end trace 0000000000000000 ]--- RIP: 0010:nested_ept_get_eptp+0xb/0x10 [kvm_intel] Cc: David Woodhouse <dwmw2@infradead.org> Fixes: |
||
EJ Campbell
|
81d99abe2b |
x86/kvm: Don't consume async #PF flags on a kernel #PF in NMI context
An async #PF "page not present" event arrives through the #PF vector, and its reason sits in the per-CPU apf_reason.flags until __kvm_handle_async_pf() reads and clears it. If an NMI arrives after the event is injected and before the #PF handler reads the flags, and the NMI handler itself takes a #PF, that fault reads and clears the flags belonging to the #PF it interrupted. It then finds interrupts disabled in the NMI context it interrupted, and panics: Kernel panic - not syncing: Host injected async #PF in interrupt disabled region Call Trace: <NMI> panic+0x52/0x60 __kvm_handle_async_pf+0xb0/0xb0 exc_page_fault+0x71/0xb0 asm_exc_page_fault+0x27/0x30 RIP: 0010:__get_user_nocheck_8+0x6/0x20 perf_callchain_user+0x147/0x1a0 get_perf_callchain+0x12d/0x1c0 ... perf_event_nmi_handler+0x26/0x50 exc_nmi+0xe8/0x110 RIP: 0010:asm_exc_page_fault+0x0/0x30 </NMI> The last RIP line shows the NMI landing on the first instruction of the #PF entry. perf with user call chains takes such a fault: the sampling NMI walks the user stack with __get_user(), which faults when a saved frame pointer is not a valid user address or the walk runs off the top of the stack. The same window exists when KVM, running as an L1 hypervisor with DELIVERY_AS_PF_VMEXIT, reads the flags itself after a #PF VM-exit. The NMI entry code saves and restores CR2 for this nesting, but not the async #PF reason. Andy Lutomirski described the race, with perf as the example, when async #PF delivery was reworked in 2020 [1]. Saving and clearing the flags across the NMI, next to CR2, was discussed there but not merged. Since that rework, Linux has stopped setting KVM_ASYNC_PF_SEND_ALWAYS, so the host delivers "page not present" only for user mode faults and a kernel-mode fault in NMI context (including kernel-mode #MC and #DB) cannot be an async page fault. In that case, return without touching the flags so that the interrupted handler finds them intact. Tested on v7.3-rc5 in a 4-vCPU, 2 GiB guest restored from a snapshot whose memory is served on demand through userfaultfd, so that reading it back takes async #PFs, while every thread samples hardware cycles with user call chains and points its frame pointer at an unmapped page. Without this patch the guest panicked as above in 3 of 3 runs. With it, the guest survived 3 of 3 runs of 60 seconds, and the host counted 148,441 to 153,334 kvm_async_pf_not_present events in the first 20 seconds of each. On 6.18.50 the results were the same: the guest panicked without the patch and survived with it. Link: https://lore.kernel.org/all/ed71d0967113a35f670a9625a058b8e6e0b2f104.1583547991.git.luto@kernel.org/ [1] Link: https://lore.kernel.org/all/20211126123145.2772-1-jiangshanlai@gmail.com/ [2] Cc: stable@vger.kernel.org # v5.9+ Signed-off-by: EJ Campbell <ejc3@meta.com> Link: https://patch.msgid.link/CADkxfh-uQTca_6jB1JPDq1MsKffF_UKGQR339oQSJNcoV75GNQ@mail.gmail.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> |
||
Jason Gunthorpe
|
4bcfe29021 |
iommupt/kunit: Use if_changed_rule for the kunit
Use if_changed_rule so rule_cc_o_c runs cmd_save_c_flags for the kunit
objects. Without the saved flags CONFIG_LTO_CLANG_THIN_DIST runs the
ThinLTO backend with no --target and generates x86_64 code from arm64
bitcode.
Fixes:
|
||
Joerg Roedel
|
3ba149029a |
Revert "iommu/amd: Remove redundant check in irq_remapping_select()"
This reverts commit
|
||
Mikhail Gavrilov
|
7cbaa0f457 |
entry: Account the deferred hrtimer rearm as hardirq context for lockdep
On a desktop debug kernel (PROVE_LOCKING, KASAN, LOCKDEP_CHAINS_BITS=19) lockdep switches itself off after about two days of uptime with "BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!", and locking is not validated until the next reboot. In the last such boot the pool ran out after 46.6 hours, and a fifth of it, 533509 of 2621431 chain hlocks in 63838 of 344717 chains, had been created by the deferred hrtimer rearm on return from interrupt. Make lockdep account that rearm as part of the timer interrupt it belongs to. Commit |
||
Jann Horn
|
3267512ad1 |
futex: Fix mm reuse handling for FUT_OFF_MMSHARED
A FUT_OFF_MMSHARED futex is a shared futex that refers to an MM.
It is possible for a process to wait on a shared futex with a different MM
because a FUT_OFF_INODE waiter can be requeued onto a FUT_OFF_MMSHARED
futex by another process.
This can cause FUT_OFF_MMSHARED waiters on a freed MM to consume
wakeups intended for a newly allocated MM at the same address.
Fix it by keying FUT_OFF_MMSHARED using a unique 64-bit per-MM ID.
Leave private futexes as before to avoid influencing the performance of the
hotpath.
(Multi-threaded processes typically implicitly use FUT_OFF_MMSHARED by
setting clear_child_tid such that it points into anonymous memory, which
causes mm_release() in a multi-threaded mm to perform FUTEX_WAKE.)
Fixes:
|