Commit Graph

1482218 Commits

Author SHA1 Message Date
Jérémy Jean
72ce4b2467 LoongArch: Avoid preempt count underflow without probe
LoongArch uses break 11 for the breakpoint placed after an instruction
that Kprobes executes out of line. Since userspace can issue the same
break instruction, do_bp() can reach kprobe_singlestep_handler() when
there is no current probe.

The handler actually returns false in this case, but it first calls
preempt_enable_no_resched(). The corresponding preempt_disable() is done
by kprobe_breakpoint_handler() on a real Kprobe hit, so it has not run
here. As a result, an ordinary userspace breakpoint (code 11) underflows
the current task's preempt count.

This also makes in_interrupt() return true until the task schedules. One
visible consequence is the socket cgroup attribution: cgroup_sk_alloc()
treats the allocation as interrupt context and assigns the socket to the
root cgroup. A socket opened from the SIGTRAP handler can then avoid a
BPF_CGROUP_INET_SOCK_CREATE policy attached to the task's own cgroup.

Return as soon as kprobe_running() reports no active probe.

The same check has appeared in [PATCH v10 2/4] of the original LoongArch
Kprobes series, but was dropped before the feature reached mainline.

Cc: stable@vger.kernel.org
Fixes: 6d4cc40fb5 ("LoongArch: Add kprobes support")
Link: https://lore.kernel.org/loongarch/1670575981-14389-3-git-send-email-yangtiezhu@loongson.cn/
Assisted-by: Codex:gpt-5
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:44:43 +08:00
Wentao Guan
c3f2feace5 LoongArch: Do not save/restore percpu base register in rethook trampoline
The rethook trampoline saves $r21 ($u0), the percpu base, into its frame
at entry and restores it at exit. Inbetween rethook_trampoline_handler()
may schedule via preempt_enable_notrace().

If the task migrates to another CPU, the frame's $r21 holds the old
CPU's percpu base, and restoring it poisons $r21 on the new CPU. Until
the next user->kernel transition heals $r21, all this_cpu_*() accesses
(runqueues, RCU per-CPU data, timer tick programming, FPU ownership)
hit the wrong CPU's percpu area.

Under kretprobe-heavy preemptible load this can corrupt scheduler and
timer state: scheduling-while-atomic splats, wrong-CPU RCU warnings,
WARN_ON_ONCE(rq != this_rq()) in nohz_balance_exit_idle(), and CPUs
parking in the idle loop with the constant timer never re-armed (hard
lockup). Reproduces on a Loongson-3A6000 with kretprobes on VFS paths
plus heavy file churn (OS install / unsquashfs).

By convention $r21 always holds the current CPU's percpu base in kernel
mode: SAVE_SOME() at exception entry reloads it only when coming from
user mode, and RESTORE_SOME() restores it only when returning to user
mode; the context-switch path never writes it. Therefore the live $r21
at trampoline exit is already correct, and nothing inbetween can change
it legitimately (kernel C code cannot write a global register variable).
The same flaw existed even in the pre-rethook kretprobe trampoline since
v6.3; it was carried over when rethook replaced it. Drop both the save
and the restore here. Drop the restore is enough to solve the issue, and
drop the save is to keep the code tidy and no need to clear it.

Cc: stable@vger.kernel.org # v6.3+
Fixes: 3f55368600 ("LoongArch: Add kretprobes support")
Assisted-by: Kimi:Kimi-K3 # debug and root-cause analysis
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:44:43 +08:00
Anthony Iliopoulos
3e1b64bd8c LoongArch: Remove unused setup_profiling_timer() function
setup_profiling_timer() is not used by any code at this point. Since a
default weak implementation exists, there is no need to still keep this
arch-specific definition around. Remove it along with the now-redundant
profile header includes.

Signed-off-by: Anthony Iliopoulos <ailiop@suse.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:44:43 +08:00
Hemanth Selam
20a9e97137 LoongArch: Fix typo "avaliable" in comment of vmlinux.lds.S
Correct "avaliable" to "available", reported by scripts/checkpatch.pl
using the misspelling list in scripts/spelling.txt. It only touches the
comments, no code changes.

Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:44:24 +08:00
Nathan Chancellor
63b6a48c95 LoongArch: Do not select HAVE_RUST when KASAN is enabled
After commit 2625480a1b ("hardening: Default randstruct off with rust
for better allmodconfig support"), which allows Rust to be enabled for
allmodconfig, ARCH=loongarch allmodconfig starts failing with:

  error: kernel-address sanitizer is not supported for this target

  error: aborting due to 1 previous error

  make[4]: *** [rust/Makefile:741: rust/core.o] Error 1

For the same reason as the commit 84a0f7caaf ("ARM: Do not select
HAVE_RUST when KASAN is enabled"), do not select HAVE_RUST when KASAN
is enabled until the loongarch64-unknown-none-softfloat target in rustc
supports KASAN.

Cc: stable@vger.kernel.org
Fixes: 90868ff9ca ("LoongArch: Enable initial Rust support")
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:44:23 +08:00
Eduard Zingerman
6b31560c6b
selftests/bpf: No non-NULL inference from an imprecise zero register
Check that a register-form NULL check does not lift PTR_MAYBE_NULL on
a path where the compared register is non-zero. W/o the previous patch
the program is accepted.

Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20260904083325.2083493-8-eddyz87@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-09-04 12:58:05 +02:00
Eduard Zingerman
6aed0134d3
bpf: Mark the zero register precise for a register-form NULL check
check_cond_jmp_op() accepts "if rA <op> rB" as a NULL check for a
nullable pointer rA when rB is a scalar known to be zero,
lifts PTR_MAYBE_NULL from rA in the corresponding branch and does not
mark rB precise. Consider the following program:

  r0 = bpf_get_prandom_u32();
  r6 = 1;                  /* the r6 == 0 path is explored first */
  if (r0 == 0) goto 1f;
  r6 = 0;
1:
  r0 = bpf_map_lookup_elem(map, &0);  /* absent, NULL at runtime */
  if (r0 == r6) goto 2f;   /* taken as a NULL check for r0       */
  *(u8 *)(r0 + 0);         /* verifier: map value; runtime: zero */
2:
  return 0;

The r6 == 0 path is explored first and the dereference is accepted.
The r6 == 1 path is pruned at the checkpoint recorded for (1),
so the comparison is never verified with a non-zero r6. At runtime a
failed lookup returns NULL, NULL != 1 takes the non-NULL edge and the
program dereferences a pointer that is zero.

Fixes: 2f4cb53eed ("bpf: detect non null pointer with register operand in JEQ/JNE.")
Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20260904083325.2083493-7-eddyz87@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-09-04 12:58:04 +02:00
Eduard Zingerman
836b2fe544
selftests/bpf: Check that JMP32 pointer vs zero jumps are not predicted
Add jmp32_ptr_vs_zero_jne: the fall-through of the 32-bit compare, which
the verifier used to skip, contains an out of bounds map value access,
hence w/o the previous patch the program is accepted. See previous patch
for detailed description.

Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20260904083325.2083493-6-eddyz87@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-09-04 12:58:04 +02:00
Eduard Zingerman
e51179a4e0
bpf: Don't predict JMP32 pointer vs zero comparisons
Consider the following program:

        r1 = map_value;      /* low 32 bits are zero at runtime */
        r6 = 0xdead000000000000;
        if w1 != 0 goto l1;
    l0: r1 += r6;
        r2 = *(u64 *)(r1 + 0);
        exit;
    l1: r6 = 0;
        goto l0;

At the moment is_branch_taken() reports the jump as always taken,
because it does not distinguish between BPF_JMP and BPF_JMP32
comparisons when processing 'if w1 != 0 ...'.

Fixes: cac616db39 ("bpf: Verifier track null pointer branch_taken with JNE and JEQ")
Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20260904083325.2083493-5-eddyz87@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-09-04 12:58:04 +02:00
Eduard Zingerman
bc412b3fb1
selftests/bpf: Check the linked regs cap for the compared register
linked_regs_too_many_regs checks that collect_linked_regs() ties at most
LINKED_REGS_MAX registers for a single jump. Compare r5 instead of r0,
so that the register the jump compares is itself the member that does
not fit, and check that it comes out of the jump unlinked.

W/o the previous patch env->{false,true}_reg{1,2} bring r5's id back and
insn 7 is logged as "R5=scalar(id=1,...)".

Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20260904083325.2083493-4-eddyz87@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-09-04 12:58:03 +02:00
Eduard Zingerman
73a98f9681
bpf: Don't resurrect a scalar id dropped by collect_linked_regs()
check_cond_jmp_op() copies the compared registers into
env->{false,true}_reg{1,2} before collect_linked_regs() runs and copies
those snapshots back into both branch states afterwards.

collect_linked_regs() records at most LINKED_REGS_MAX members of a
linked registers group in the jump history and calls clear_scalar_id()
for every member that does not fit. The compared register is not exempt
from that.

As a consequence, sync_linked_regs() might adjust ranges for more
registers than bpf_bt_sync_linked_regs() can propagate precision to.

Collect the linked registers before the snapshots are taken instead.
This might lead to some unnecessary clear_scalar_id's, but from
previous testing situations with many linked registers are
extremely rare.

Fixes: ec1d77cb0e ("bpf: Use bpf_verifier_env buffers for reg_set_min_max")
Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20260904083325.2083493-3-eddyz87@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-09-04 12:58:03 +02:00
Eduard Zingerman
6752b90ccf
selftests/bpf: No non-NULL inference from unbounded offset pointers
Check that a comparison against a pointer whose offset is not bounded
from above does not make the verifier infer that a nullable pointer is
not NULL, and that a bounded offset still does. W/o the previous patch
the first test is accepted.

Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20260904083325.2083493-2-eddyz87@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-09-04 12:58:02 +02:00
Eduard Zingerman
67b529f521
bpf: Don't infer non-NULL from a pointer with an unbounded offset
reg_not_null() decides that a register holds a non-NULL value by
looking at its type alone. For pointer types that allow arithmetic the
type only guarantees a non-NULL base, in case of an unbound offset
the runtime offset value might still add up to NULL.
Consider the followng program:

  r6 = bpf_map_lookup_elem(map, &0);  /* present */
  if (r6 == 0) return 0;
  r7 = bpf_map_lookup_elem(map, &1);  /* absent, NULL at runtime */
  r8 = r7;
  r8 -= r6;     /* pointer - pointer: unknown scalar, -r6 */
  r8 <<= 1;
  r8 >>= 1;     /* any non-negative offset is accepted by */
                /* check_reg_sane_offset_ptr() */
  r6 += r8;     /* verifier: map value;    runtime: zero  */
  if (r7 != r6) return 0;
  *(u8 *)(r7 + 0);  /* r7 is inferred non-NULL, both are zero */

At runtime both registers are zero, the comparison is true and the
load faults with NULL pointer dereference.

Require the offset to be within +-BPF_MAX_VAR_OFF in reg_not_null().

Fixes: cac616db39 ("bpf: Verifier track null pointer branch_taken with JNE and JEQ")
Reported-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20260904083325.2083493-1-eddyz87@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-09-04 12:58:02 +02:00
Dave Airlie
c96294afbc A small fix on the error handling of an OA uapi and the
addition of a drm_info message to report FLAT_CSS base misalignment.
 -----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCgAdFiEEbSBwaO7dZQkcLOKj+mJfZA7rE8oFAmqZ1RgACgkQ+mJfZA7r
 E8qyAwf9FrxuliHzaaSz0vxrIlL4LzCYarKbLc9quiSAXEu0TM5QhIYlJJu8PSrp
 ChZGAutqwG+0x8o/+ztbt+5ij21+FVWOK/PnGEmctBevd+bPPRKAWYghVgSOkFww
 OuUwUotEDicqIM+Ml8qjDUXgWNRgkeoLknKZH2XTWpRZxPAxZYcC5P6k+DVAN4pC
 zcurjW9gbcTci2OP9No8EtxuY8+3YCz/Jtwd/Sx1nw0gqoD5l2yPziwdKMOjd3XU
 imml0dnBEWQYPUliVojj2onZKM9ujR4JHSpFCKAHs5c8UN5srlIEFzh14QgR+9Ux
 4ZDXzmbzc3Y3z4oM+dsJOiY3LDUJTA==
 =XZIm
 -----END PGP SIGNATURE-----

Merge tag 'drm-xe-fixes-2026-09-03' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes

A small fix on the error handling of an OA uapi and the
addition of a drm_info message to report FLAT_CSS base misalignment.

Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/apnVOtDv4WAIoj_X@intel.com
2026-09-04 20:36:14 +10:00
Dave Airlie
7f78fe856e amd-drm-fixes-7.3-2026-09-03:
amdgpu:
 - SR-IOV fix
 - GFX8 fix
 - MES queue reset fix
 - GPUVM fixes
 - DCN 6 warning fix
 - DCN 3.5/3.6 fix
 - DML fix
 - Backlight fix
 - Colorop fix
 - DC get_estimated_bw() fix
 - devcoredump fix
 - Userq fixes
 - APU PSP fix
 - Cursor fix
 
 amdkfd:
 - MES queue eviction fix
 - MQD debugfs fix
 
 UAPI:
 - Fix for drm_amdgpu_info_device with mixed 64 bit kernel and 32 bit userspace
 -----BEGIN PGP SIGNATURE-----
 
 iHUEABYKAB0WIQQgO5Idg2tXNTSZAr293/aFa7yZ2AUCapmnvwAKCRC93/aFa7yZ
 2DbfAQCapkI0p5iRMd/2fk2JcdhhaHfTtwdNEKyiHx7Z8Fyo7wD/egYUpCbhpy4W
 6bavqT8G5Gkn4+myqJmD9bIVoWmdlAA=
 =tJ2Q
 -----END PGP SIGNATURE-----

Merge tag 'amd-drm-fixes-7.3-2026-09-03' of https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes

amd-drm-fixes-7.3-2026-09-03:

amdgpu:
- SR-IOV fix
- GFX8 fix
- MES queue reset fix
- GPUVM fixes
- DCN 6 warning fix
- DCN 3.5/3.6 fix
- DML fix
- Backlight fix
- Colorop fix
- DC get_estimated_bw() fix
- devcoredump fix
- Userq fixes
- APU PSP fix
- Cursor fix

amdkfd:
- MES queue eviction fix
- MQD debugfs fix

UAPI:
- Fix for drm_amdgpu_info_device with mixed 64 bit kernel and 32 bit userspace

Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260903174712.584320-1-alexander.deucher@amd.com
2026-09-04 20:34:31 +10:00
Daehyeon Ko
cdd812d068
exit: hold a reference to thread_pid across proc_flush_pid
Commit 0a36bad017 ("release_task: kill the no longer needed
get/put_pid(thread_pid)") removed the reference around proc_flush_pid().
It assumed that free_pids(post.pids) at the end of release_task() would
keep thread_pid alive until then.

That assumption is wrong.  __change_pid() only records a detached PID in
post.pids when pid_has_task() is false for every PIDTYPE.  If another task
still uses the exiting task's PID as its process group or session ID,
__unhash_process() removes the exiting task's PIDTYPE_PID link but leaves
the PID out of post.pids.  release_task() therefore holds no reference to
it after dropping tasklist_lock.

The other task can then remove the remaining PIDTYPE links.  Its
free_pids() call schedules delayed_put_pid(), and the RCU callback can free
the PID before the first release_task() reaches proc_flush_pid().

An unprivileged reproducer races wait4(-1) against setsid() to trigger this
ordering.  Three of three fresh v7.2 KASAN boots reported:

    BUG: KASAN: slab-use-after-free in
    proc_invalidate_siblings_dcache+0x3e2/0x3f0
    Read of size 8 by task h7_pid_reaper/1921

    Call Trace:
     proc_invalidate_siblings_dcache
     release_task
     wait_consider_task
     __do_wait
     do_wait
     kernel_wait4

    Freed by task 0:
     kmem_cache_free
     put_pid
     delayed_put_pid
     rcu_core

    Last potentially related work creation:
     __call_rcu_common
     free_pids
     ksys_setsid

KASAN identified a 144-byte object from the pid cache and located the bad
read 80 bytes into the freed object, matching pid->inodes.  With an
explicit reference, three of three fresh boots completed without a KASAN
report.  The concurrent RCU callback dropped its reference while
proc_flush_pid() was protected, and the balancing put_pid() performed the
final free afterward.

Take a reference before __unhash_process() clears p->thread_pid and release
it after proc_flush_pid() completes.

A tested source reproducer is available privately on request.  No
controlled read or write, information leak, or privilege escalation is
claimed.  The mainline patch applies directly to v6.19.y and newer;
v6.16.y through v6.18.y need a context-adjusted backport.

Fixes: 0a36bad017 ("release_task: kill the no longer needed get/put_pid(thread_pid)")
Reported-by: syzbot+0aee5e8066eddbbe7397@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=0aee5e8066eddbbe7397
Reported-by: syzbot+e8b3520b53e78e90034e@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=e8b3520b53e78e90034e
Cc: stable@vger.kernel.org # see patch description, needs adjustments for 6.16.y-6.18.y
Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>
Link: https://patch.msgid.link/20260831001221.3755948-1-4ncienth@gmail.com
Acked-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Bradley Morgan <brads@mainlining.org>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-09-04 11:40:27 +02:00
Eric Biggers
60892a384a crypto: x86/aria - add missing vzeroupper in AVX-512 code
Since the AVX-512 optimized ARIA code uses ZMM registers, execute
vzeroupper before returning from it.  This is needed to avoid degrading
the performance of any later SSE code that may happen to be executed.

Fixes: c970d42001 ("crypto: x86/aria - implement aria-avx512")
Cc: stable@vger.kernel.org
Cc: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-09-04 18:45:51 +10:00
Eric Biggers
ac53977611 crypto: x86/aria - add missing vzeroupper in AVX2 code
Since the AVX2 optimized ARIA code uses YMM registers, execute
vzeroupper before returning from it.  This is needed to avoid degrading
the performance of any later SSE code that may happen to be executed.

Fixes: 37d8d3ae7a ("crypto: x86/aria - implement aria-avx2")
Cc: stable@vger.kernel.org
Cc: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-09-04 18:45:50 +10:00
Jeffin Philip
5ab54837fc
fs: autofs: fix memory leak in autofs_fill_super()
In autofs_fill_super(), we create a new inode using
autofs_new_ino(), however, if we fail to create root_inode,
(that is, root_inode failure path), we return -ENOMEM without
freeing the new inode(ino) that we created causing a memory leak.
Fix this by adding autofs_free_ino() to free the inode we created
in root_inode failure path before returning ENOMEM.

Reported-by: syzbot+df1db6e034b3953e19f5@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=df1db6e034b3953e19f5
Fixes: 66917f85db ("autofs: add: new_inode check in autofs_fill_super()")
Cc: stable@vger.kernel.org
Signed-off-by: Jeffin Philip <jeffinphilip14@gmail.com>
Link: https://patch.msgid.link/20260903081048.132524-1-jeffinphilip14@gmail.com
Signed-off-by: Ian Kent <raven@themaw.net>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-09-04 09:48:00 +02:00
Jiri Slaby (SUSE)
797b13a7de irqdomain: Delete irq_domain_add_linear()
7.3-rc1 is free of calls to irq_domain_add_linear(), so it can be finally
deleted.

According to Dongliang Mu, the related paragraph in the Chinese docs is now
obsolete. So drop it completely.

Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
Reviewed-by: Yanteng Si <si.yanteng@linux.dev>
Link: https://patch.msgid.link/20260901070450.255507-1-jirislaby@kernel.org
2026-09-04 08:40:07 +02:00
Yao Kai
a3b8d46fe4 futex: Prevent rcuwait use-after-free during requeue PI
On PREEMPT_RT, FUTEX_CMP_REQUEUE_PI can trigger a KASAN report
(slab-out-of-bounds) in futex_requeue_pi_complete() invocation of
rcuwait_wake_up().

The futex_q used by futex_wait_requeue_pi() is allocated on the waiter's
stack. An early wakeup can race with a PI requeue as follows:

        waiter                          requeue task
        ------                          ------------
futex_wait_requeue_pi()
  futex_do_wait()
    schedule()
                                       futex_requeue
                                         futex_proxy_trylock_atomic()
                                           futex_requeue_pi_prepare()
                                            Q_REQUEUE_PI_NONE -> Q_REQUEUE_PI_IN_PROGRESS
* timeout/ signal wakes waiter *
  futex_requeue_pi_wakeup_sync()
   Q_REQUEUE_PI_IN_PROGRESS -> Q_REQUEUE_PI_WAIT
                                           requeue_pi_wake_futex
                                             futex_requeue_pi_complete()
                                               cmpxchg Q_REQUEUE_PI_WAIT -> Q_REQUEUE_PI_LOCKED
    rcuwait_wait_event()
      if (atomic_read(&q->requeue_state) != Q_REQUEUE_PI_WAIT)
       break /* no schedule() */

 /* q.pi_state->owner == current */
 futex_private_hash_put()
 /* return from syscall */
                                              rcuwait_wake_up(&q->requeue_wait)
                                                /* q is gone */

futex_requeue_pi_complete() publishes Q_REQUEUE_PI_LOCKED before
calling rcuwait_wake_up(). The waiter observes this state in
rcuwait_wait_event() before invoking schedule() in rcuwait_wait_event().
Here, the waiter is free leave the syscall before requeue task can
complete the wake.

To address this race skip rcuwait_wake_up() in the Q_REQUEUE_PI_LOCKED
case.
This state is only published by requeue_pi_wake_futex(), which saves
q->task before futex_requeue_pi_complete() and wakes the waiter via
wake_up_state().

This wake is intended to wake the waiter from its futex_do_wait() sleep.
If the waiter is still sleeping there, it can not get into the
Q_REQUEUE_PI_WAIT state (and require this removed wake).
Should the waiter be woken up from futex_do_wait() by other means (as in
this example) and sleep in futex_requeue_pi_wakeup_sync() then the
wake_up_state() from requeue_pi_wake_futex() will wake it, too.
Should the waiter task terminate before wake_up_state() had a chance to
wake the task then the task pointer does not become invalid because the
futex_hash_bucket::lock is held and the task pointer is RCU protected.

[bigeasy: Updated comment and commit message]

Fixes: 07d91ef510 ("futex: Prevent requeue_pi() lock nesting issue on RT")
Signed-off-by: Yao Kai <yaokai34@huawei.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260901135453.3121948-3-bigeasy@linutronix.de
2026-09-04 08:14:15 +02:00
Sebastian Andrzej Siewior
912edebe85 futex: Provide rt_mutex_.*_schedule() equivalents for futex scheduling
There is rt_mutex_{pre|post}_schedule() around
rt_mutex_wait_proxy_lock() to ensure that sched_submit_work()/
sched_update_worker() is invoked before we schedule out and block on
rt_mutex while waiting for it become available.

The reason is that blocking on rt_mutex assigns a pi_waiter for the PI
chain and sched_submit_work() will also assign a pi_waiter if it blocks
on lock but a this point we already have a waiter assigned.
We can't skip sched_submit_work() entirely because I/O relies on the
fact that I/O queue is flushed while it blocks on a sleeping lock.
Therefore sched_submit_work() is moved before we block on the lock.

Sleeping lock in this context means mutex or rw_semaphore not spinlock_t
on PREEMPT_RT. Because the mutex abstraction on PREEMPT_RT uses the same
abstraction as the futex proxy lock, the futex code ended up using
rt_mutex_{pre|post}_schedule(), too.
Using it is/ was just to keep the task_struct::sched_rt_mutex assertion
happy. Futex proxy lock is used only in the syscall context of a task.
At this point it never got any I/O that needs to be flushed and it can't
be a workqueue that needs to notify that it will be scheduled out.
Therefore sched_submit_work() does nothing here.

By mistake futex_wait_requeue_pi() -> rt_mutex_wait_proxy_lock() did not
get the rt_mutex_{pre|post}_schedule() annotation. This was not noticed
because in this callchain the lock is (usually) not contended and so
rt_mutex_slowlock_block() does not schedule, triggering the assert.

Adding rt_mutex_pre_schedule() here looks wrong (as noted by PeterZ)
because at this point there is a pi_waiter recorded and invoking
sched_submit_work() with a possible lock contention would be wrong.

Add rt_mutex_futex_{pre|post}_schedule() which toggles the
sched_rt_mutex assert and does not involve sched_submit_work(). Add
asserts here to ensure that sched_submit_work() would do nothing. Use it
only in futex proxy lock case which is rt_mutex_wait_proxy_lock().
Remove it from futex_lock_pi().

Fixes: d14f9e930b ("locking/rtmutex: Use rt_mutex specific scheduler helpers")
Reported-by: Yao Kai <yaokai34@huawei.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260901135453.3121948-2-bigeasy@linutronix.de
Closes: https://lore.kernel.org/all/20260717084922.4153317-2-yaokai34@huawei.com
2026-09-04 08:14:15 +02:00
Dave Airlie
5ff6e2f8a7 Merge tag 'drm-intel-fixes-2026-09-03' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes
drm/i915 fixes for v7.3-rc2:
- Drop an accidentally duplicated panel fitter call in DP MST
- Fix DDI clock programming for Cx0 and LT PHY
- Fix PTL CDCLK handling at probe, causing a glitch
- Fix dg2_power_well_count() return type
- Fix a NULL pointer deref at forced probe
- Fix selective fetch disable

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/affe11af9d5eb9dc6f906441495cb843f9d4817c@intel.com
2026-09-04 15:58:07 +10:00
Florian Westphal
254c881fe0 selftests/bpf: Add tests to assert that netfilter progs cannot write to skb
The netfilter framework is allergic to ip header changing after
validation done by ip/ipv6 stack.

Assert that bpf netfilter programs do not allow skb write access.

Following additional tests are expected to be rejected by verifier:

1. alter skb->len.
2. alter skb->data.
3. prog calls bpf_dynptr_slice_rdwr.
4. alter location returned by dynptr API.

Add following test case for bpf runtime:
- alter skb data via bpf_dynptr_write()

Test checks via __retval() that bpf_dynptr_write() returned nonzero value.

Signed-off-by: Florian Westphal <fw@strlen.de>
Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Link: https://lore.kernel.org/r/20260903065845.22762-1-fw@strlen.de
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-03 21:41:58 -07:00
Dave Airlie
42bc1b92c9 A whole bunch of fixes for various drivers
- Fix drm_crtc_commit leak when PAGE_FLIP_EVENT is used,
 - amd: plane blend mode fixes
 - amdxdna: out-of-bounds access fix, reject commands chains with no
   commands, handle chained mapping BO failures, refuse to flush an
   imported BO
 - atomic-state-helpers: set pixel_blend_mode to prop default on reset
 - dma-buf: Publish the dma-buf only after copy_to_user succeeds, fix
   some kernel-doc warnings
 - ethosu: handle mmio mapping failures, handle storage modes only on
   hardware that supports it, fix job completion fence cleanup
 - fastrpc: Publish the dma-buf only after copy_to_user succeeds
 - gud: Improve TV modes and rotation handling
 - nouveau: use-after-free fixes, add scanline position support, HDMI
   and DP fixes, null pointer dereference fix, dmem accounting fixes for
   large folios, use write-combined maps for coherent
 - pagemap: Prevent double migration of device pages, Reset migration
   page count on eviction retry, dma-unmap pages before handling
   migration errors, use after free fixes
 - prime: fix prime exports tracing
 - qaic: out-of-bounds access fix
 - sysfb: Fix integer overflow, fix constant comparison bug
 - tegra: Add blend mode properties
 - virtio: exit path and error handling fixes
 -----BEGIN PGP SIGNATURE-----
 
 iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCapk9RQAKCRAnX84Zoj2+
 du3SAX9yHaEcnGDqW4cDdwSG04Q/8om+V24gOepm5HEC1Tfwwn/SthpMUArHyT4e
 PyIlngsBf0PbIyv63k4tURGMDck7RDUDZCf5YtiUR1HdhXUffTCYBClz+TdZCLpq
 qLyXJFtOqg==
 =jD2Q
 -----END PGP SIGNATURE-----

Merge tag 'drm-misc-fixes-2026-09-03' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes

A whole bunch of fixes for various drivers

- Fix drm_crtc_commit leak when PAGE_FLIP_EVENT is used,
- amd: plane blend mode fixes
- amdxdna: out-of-bounds access fix, reject commands chains with no
  commands, handle chained mapping BO failures, refuse to flush an
  imported BO
- atomic-state-helpers: set pixel_blend_mode to prop default on reset
- dma-buf: Publish the dma-buf only after copy_to_user succeeds, fix
  some kernel-doc warnings
- ethosu: handle mmio mapping failures, handle storage modes only on
  hardware that supports it, fix job completion fence cleanup
- fastrpc: Publish the dma-buf only after copy_to_user succeeds
- gud: Improve TV modes and rotation handling
- nouveau: use-after-free fixes, add scanline position support, HDMI
  and DP fixes, null pointer dereference fix, dmem accounting fixes for
  large folios, use write-combined maps for coherent
- pagemap: Prevent double migration of device pages, Reset migration
  page count on eviction retry, dma-unmap pages before handling
  migration errors, use after free fixes
- prime: fix prime exports tracing
- qaic: out-of-bounds access fix
- sysfb: Fix integer overflow, fix constant comparison bug
- tegra: Add blend mode properties
- virtio: exit path and error handling fixes

Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Maxime Ripard <mripard@redhat.com>
Link: https://patch.msgid.link/apk9X5SkRLS9g4RF@houat
2026-09-04 13:32:49 +10:00
Alexei Starovoitov
0237317ffc Merge branch 'misc-bug-fixes-part-2'
Kumar Kartikeya Dwivedi says:

====================
Misc bug fixes - part 2

A set of miscellaneous fixes for bugs reported by Nicholas, plus some
new findings by GPT-5.6-Sol and Sashiko. See commit logs for details.
====================

Link: https://patch.msgid.link/20260903214758.2727663-1-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-03 19:22:53 -07:00
Kumar Kartikeya Dwivedi
23724e009f selftests/bpf: Reject legacy packet loads from callbacks
Add verifier coverage for the callback restriction on legacy packet
loads. Exercise BPF_LD_ABS directly in a bpf_loop callback and
BPF_LD_IND from a static subprogram called by the callback, ensuring that
callback context follows nested static calls.

Also exercise a callback which reaches BPF_LD_IND through a global
function and its static descendant. A sibling success case calls the same
global chain outside a callback, preserving support for ordinary global
packet loads. Existing success cases continue to cover loads from ordinary
static subprograms.

The failure cases expect the policy-specific rejection instead of reaching
the implicit-return path, triggering a verifier warning, or being accepted
through a function boundary.

Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260903214758.2727663-9-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-03 19:22:52 -07:00
Kumar Kartikeya Dwivedi
e7d28823c6 bpf: Reject legacy packet loads from callbacks
check_ld_abs() models a failed BPF_LD_ABS or BPF_LD_IND in a
subprogram as an implicit return with R0 set to zero. It calls
prepare_func_exit() to explore this synthesized path.

When the load is reached directly from a synchronous callback,
prepare_func_exit() enforces the callback return contract and marks R0
precise. R0 is not derived from a real instruction on this path, so
precision backtracking reaches the callback call with R0 still requested
and triggers the "callback unexpected regs" verifier bug. A privileged
program loader can therefore cause a verifier warning and an -EFAULT
BPF_PROG_LOAD.

These legacy packet-load instructions are deprecated. Reject them from
callbacks rather than complicating their implicit-return model. Check all
active frames before constructing the implicit return so nested static
subprograms cannot hide the callback context.

Global functions are verified independently with a fresh frame zero, so
an active-frame check cannot identify a global function called from a
callback. Also check the complete subprogram call graph during stack-depth
validation and reject a function containing a legacy load when any caller
is a callback. This covers global and static descendants without making
has_ld_abs transitive, preserving its per-function BTF return-type check.
Ordinary uses outside callbacks remain supported.

Fixes: ee861486e3 ("bpf: Fix ld_{abs,ind} failure path analysis in subprogs")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://lore.kernel.org/bpf/20260903152147.C0E241F00A3A@smtp.kernel.org
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260903214758.2727663-8-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-03 19:22:52 -07:00
Kumar Kartikeya Dwivedi
1ba0d0d8b6 selftests/bpf: Check faultable stack helper contexts
Add verifier coverage for the sleepable bpf_get_stack() and
bpf_get_task_stack() implementations. Call each helper while preemption is
disabled and require the verifier to reject it as sleepable.

Both programs load when the prototypes lack might_sleep, so the
expected-failure tests fail. Keep success controls outside the
non-preemptible region to ensure ordinary calls from sleepable uprobes
remain valid.

Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260903214758.2727663-7-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-03 19:22:52 -07:00
Kumar Kartikeya Dwivedi
9d02927fdf bpf: Mark faultable stack helpers as sleepable
The faultable variants of bpf_get_stack() and bpf_get_task_stack() pass
may_fault=true into the common stack collection code. Resolving user-space
build IDs may then call build_id_parse_file() and block on filesystem
reads.

Neither helper prototype sets might_sleep. Since prototype selection uses
the sleepability of the whole program, the verifier can still allow these
helpers from a non-sleepable region within that program, such as an
explicit RCU or preemption-disabled region. The task-stack helper can also
be called from a non-sleepable timer callback of a sleepable program.

Mark both faultable prototypes as sleepable. The existing helper context
check then rejects these calls while continuing to allow them in genuinely
sleepable contexts.

Fixes: d4dd9775ec ("bpf: wire up sleepable bpf_get_stack() and bpf_get_task_stack() helpers")
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260903214758.2727663-6-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-03 19:22:52 -07:00
Kumar Kartikeya Dwivedi
687b2729ce selftests/bpf: Test btf lookup helper sleepability
Add an expected failure case which calls
bpf_btf_find_by_name_kind() from a BPF timer callback. Without the
helper prototype being marked sleepable, the verifier accepts the
program and the load unexpectedly succeeds.

Also add a positive control which calls the helper directly from a
syscall program. This verifies that marking the helper sleepable only
rejects it in non-sleepable regions.

Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260903214758.2727663-5-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-03 19:22:52 -07:00
Kumar Kartikeya Dwivedi
620614bf76 bpf: Mark bpf_btf_find_by_name_kind() as sleepable
When bpf_btf_find_by_name_kind() finds a type in module BTF, it
returns a new BTF object fd through __btf_new_fd(). This reaches
anon_inode_getfd(), which can sleep while allocating or expanding the
current task fd table.

The helper prototype does not set might_sleep, so the verifier allows
the helper in non-sleepable contexts such as BPF timer callbacks. The
fd allocation can then sleep in softirq context and install the fd into
the interrupted task.

Mark the helper as sleepable. This preserves calls from the main body
of a sleepable syscall program while rejecting calls from its
non-sleepable regions.

Fixes: 3d78417b60 ("bpf: Add bpf_btf_find_by_name_kind() helper.")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://lore.kernel.org/bpf/20260903155150.D57251F000E9@smtp.kernel.org
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260903214758.2727663-4-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-03 19:22:52 -07:00
Kumar Kartikeya Dwivedi
22ab49afe1 selftests/bpf: Check rbtree callback restrictions in subprogs
Add a verifier failure case where an rbtree comparator enters two nested
static subprograms and the innermost subprogram unlocks and relocks the
tree. Restoring the lock keeps the surrounding callback state balanced,
so the test specifically exercises whether the callback restriction follows
the nested calls.

Also add a load-only positive control whose comparator calls a harmless
static subprogram. This preserves the intended support for verified static
subprogram calls while holding the tree lock.

Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260903214758.2727663-3-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-03 19:22:52 -07:00
Kumar Kartikeya Dwivedi
369f4ce734 bpf: Check ancestor frames for rbtree callbacks
bpf_rbtree_add() invokes its comparator while the caller holds the root
lock. The native insertion code retains raw parent and link pointers across
the callback, so the verifier prohibits unlocking, consuming tree nodes,
or changing RCU state from that callback.

in_rbtree_lock_required_cb() only checks the innermost verifier frame.
Static subprogram calls are permitted while holding a spin lock, and such a
call pushes a frame without in_callback_fn set. Consequently, all callback
restrictions disappear in the nested frame. The subprogram can unlock the
tree, remove and drop the node being compared, then relock. Native insertion
resumes with the stale parent pointer and links freed memory into the tree.

Walk all active frames for the rbtree callback instead. Benign static
subprograms remain permitted, while callback restrictions follow execution
into nested frames.

Fixes: a44b1334aa ("bpf: Allow calling static subprogs while holding a bpf_spin_lock")
Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260903214758.2727663-2-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-03 19:22:52 -07:00
Eduard Zingerman
65b1518c99 selftests/bpf: bpf_fastcall patterns entered by a jump
Check bpf_fastcall pattern detection when the pattern is entered at an
instruction other than the first spill:
- a jump to the first spill allows the rewrite;
- conditional/unconditional a jump to the call or to the fill does not
  allow the rewrite.

Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260903205820.1743087-2-eddyz87@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-03 18:55:40 -07:00
Eduard Zingerman
0b1c83dc3c bpf: don't rewrite bpf_fastcall patterns entered by a jump
mark_fastcall_pattern_for_call() must ensure that matched
"spill; call; fill" instruction series is not interrupted by a jump.
Otherwise the rewrite applied by bpf_remove_fastcall_spills_fills()
is not sound.

Record the instructions targeted by jumps in
insn_aux_data[*].jump_target when the CFG is built and use this flag
to stop growing a pattern at such an instruction. Jumps to the first
spill are fine.

Note that existing insn_aux_data[*].jmp_point field can't be reused,
as it marks subprogram return instructions.

Fixes: 5b5f51bff1 ("bpf: no_caller_saved_registers attribute for helper calls")
Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260903205820.1743087-1-eddyz87@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-03 18:55:40 -07:00
Eduard Zingerman
54ed919503 selftests/bpf: check zero extension of an arena 32-bit cmpxchg
Add a test to verify that destination register of a 32-bit cmpxchg
operating on an arena pointer is explicitly zero extended.
W/o patch #1 this did not happen.

Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260903171542.1438050-3-eddyz87@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-03 18:54:45 -07:00
Eduard Zingerman
1f3cd9719c bpf: update disasm.c to print BPF_PROBE_ATOMIC as atomics
bpf_convert_ctx_accesses() rewrites an atomic on an arena pointer from
BPF_STX | BPF_ATOMIC to BPF_STX | BPF_PROBE_ATOMIC, this patch adjusts
print_bpf_insn() to print such instructions as regular atomics with a
'probe_' prefix (instead of printing them as BUG_XX).

Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260903171542.1438050-2-eddyz87@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-03 18:54:45 -07:00
Eduard Zingerman
4814ed6406 bpf: zero extend the result of an arena 32-bit cmpxchg
bpf_convert_ctx_accesses() rewrites an atomic on an arena pointer from
BPF_STX | BPF_ATOMIC to BPF_STX | BPF_PROBE_ATOMIC, and it runs before
bpf_opt_subreg_zext_lo32_rnd_hi32().

That pass emits an explicit zero extension for a 32-bit cmpxchg even
when bpf_jit_needs_zext() is false. This is done because on some
architectures 32-bit cmpxchg requires explicit zero extension for the
dst register. E.g. on x86-64 'lock cmpxchg' does not change the %eax
if comparison is successful, while BPF semantics declare that each
operation on a 32-bit register zero extends it's upper half.

is_cmpxchg_insn() matches BPF_MODE == BPF_ATOMIC only, so an arena
cmpxchg misses said zero extension adjustment. This patch adjusts
is_cmpxchg_insn() to match BPF_PROBE_ATOMIC alongside BPF_ATOMIC.

Fixes: d503a04f8b ("bpf: Add support for certain atomics in bpf_arena to x86 JIT")
Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260903171542.1438050-1-eddyz87@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-03 18:54:45 -07:00
Jens Axboe
00ef2248c5 nvme fixes for Linux 7.3
- Harden the tcp host and target against malformed PDUs: reject C2HData
    for a non-read command, bound an over-long PDU before copying it, and
    reject unsolicited H2CData (Yehyeong, Shivam)
  - Fix circular locking on TLS queues (Xixin)
  - Fix a soft lockup when scanning sparse namespace ID space (Mohamed)
  - Fix racy access to the FDP placement id array (Kanchan)
  - RDMA host and target fixes for a double cleanup on the queue_rq
    error path and a queue leak when the connect backlog is exceeded
    (Xixin)
  - Authentication fixes: drain the target's expiry work before the SQ
    is freed, and release the DH-CHAP secret when parsing fails (Kazuki,
    Xu Rao)
  - Fix nvme-fc options double free when nvme_add_ctrl() fails (Niklas)
  - Add missing SRCU grace period to nvme_alloc_ns() error path (Tristan)
  - Skip zoned limits update when the zone info query failed (Chao)
  - Reject enabling a target namespace with no device path (Seokgyu)
  - Add opcode filtering for fault injection (Mohamed)
  - Drop the kernel-doc comments from nvme-tcp.h (Randy)
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEE3Fbyvv+648XNRdHTPe3zGtjzRgkFAmqZ46MACgkQPe3zGtjz
 RglHuRAAhB+37HZ4wsYuwIud6IwF4rrXMv/EU1C87Nt6ORXiTG892ECT+4G4ruZo
 GTxFl6UB+i8GRw+RivMpZAWoLtEclU1GZ/ijPpgQ4+QKva60q29/2oQQiqT+x5us
 Nhez9uuC1hywxY+HfVDfvx44ISXwPG/8ZTrGMfuEO8kbmiczY8X5LxnSicgWLTc8
 PTdXvSDw5mtinzCPozRDVuFRTcDwUhM3NzVIv7MVXgEyY1sCwcPbmj8GdCkFco1G
 WnIpWP3WplnO7yNcwMN+sSFvq8PjBFfW+LJ/25WRLQFvTpF5zwejPXNWPt90USU4
 hA9kXua1CRHuApKUeNSLMQ3PG2pbB+NjIN31ZpBnveXplmIudoQuT+wLwltBg3te
 9doRCqCGLMCNu+qPFquUOOr9+6+36pBlFTynNy5WGqen0YwY4/UEG4PEU649J3Ve
 N10KY+ttHgi3bY6JdcCVlDhdzGW/rSobNz1GL4IpqPcYdZsvMqSyLrQpZfdKfp5m
 4KWYyiVmydq6ixHpZF1yEM9y2+RZGi9AtOi6CCY5pNDt7lS257htsNSTX9T3pWcH
 IeknLIuseNEW1IgUa7RPUrEkQJsiQx7eb6wI13otJULA60T40rISshuC8yGZblni
 4zu5PQiaecjqXSWQfenEi6tvPuu9jV7YsuvK5x5qs21DnFy7pUo=
 =YJ4v
 -----END PGP SIGNATURE-----

Merge tag 'nvme-7.3-2026-09-03' of git://git.infradead.org/nvme into block-7.3

Pull NVMe fixes from Keith:

"- Harden the tcp host and target against malformed PDUs: reject C2HData
   for a non-read command, bound an over-long PDU before copying it, and
   reject unsolicited H2CData (Yehyeong, Shivam)
 - Fix circular locking on TLS queues (Xixin)
 - Fix a soft lockup when scanning sparse namespace ID space (Mohamed)
 - Fix racy access to the FDP placement id array (Kanchan)
 - RDMA host and target fixes for a double cleanup on the queue_rq
   error path and a queue leak when the connect backlog is exceeded
   (Xixin)
 - Authentication fixes: drain the target's expiry work before the SQ
   is freed, and release the DH-CHAP secret when parsing fails (Kazuki,
   Xu Rao)
 - Fix nvme-fc options double free when nvme_add_ctrl() fails (Niklas)
 - Add missing SRCU grace period to nvme_alloc_ns() error path (Tristan)
 - Skip zoned limits update when the zone info query failed (Chao)
 - Reject enabling a target namespace with no device path (Seokgyu)
 - Add opcode filtering for fault injection (Mohamed)
 - Drop the kernel-doc comments from nvme-tcp.h (Randy)"

* tag 'nvme-7.3-2026-09-03' of git://git.infradead.org/nvme: (21 commits)
  nvme-tcp.h: drop kernel-doc comments, fix a few descriptions
  nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails
  nvmet: reject namespace enable without device path
  nvmet-auth: Synchronize timeout work during SQ teardown
  MAINTAINERS: update nvme entry
  nvmet-tcp: reject unsolicited H2CData PDUs
  nvme-tcp: defer TLS inline send to io_work
  nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU
  nvme-tcp: return -EPROTO for a C2HData on a write
  nvmet: print namespace IDs as unsigned 32bit value
  nvme: print namespace IDs as unsigned 32bit value
  nvme: remove stale namespaces by NSID range during scan
  nvme: add missing SRCU grace period in error path
  nvme-fabrics: fix DHCHAP secret leak on parse failure
  nvmet-rdma: fix queue leak when connect backlog is exceeded
  nvme: add opcode filtering for fault injection
  nvme: fix racy access to FDP placement id array
  nvme: set ns->head in nvme_alloc_ns_head
  nvme-rdma: fix -EIO cleanup order in queue_rq
  nvme: skip the zoned limits update if the zone info query failed
  ...
2026-09-03 19:48:07 -06:00
Linus Torvalds
bc35965f69 18 hotfixes. 13 are cc:stable. 15 are for MM.
All are singletons - please see the changelogs for details.
 -----BEGIN PGP SIGNATURE-----
 
 iHUEABYKAB0WIQTTMBEPP41GrTpTJgfdBJ7gKXxAjgUCapoUuQAKCRDdBJ7gKXxA
 jgscAP9iRyonROgpsNKC9H8EsAL7QhZNxjwc5PWs0bN6J50LOwD/Um6G7b1P8cxs
 j7kGpxbQYI0RWxxLUBLTQiPbDrvn6wY=
 =TJzY
 -----END PGP SIGNATURE-----

Merge tag 'mm-hotfixes-stable-2026-09-03-17-45' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

Pull misc fixes from Andrew Morton:
 "18 hotfixes.  13 are cc:stable.  15 are for MM.

  All are singletons - please see the changelogs for details.

  There are no fixes (yet) for all the stuff we added in the most recent
  merge window. Hopefully a good sign"

* tag 'mm-hotfixes-stable-2026-09-03-17-45' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
  mm/secretmem: properly account locked pages
  mm/mremap: reset unfaulted VMA page offset for MREMAP_DONTUNMAP
  MAINTAINERS: add Kiryl as a THP reviewer
  MAINTAINERS: cover all of RAID
  MAINTAINERS: mailmap: update entries for Thorsten Blum
  MAINTAINERS: remove Lorenzo as THP co-maintainer
  Revert "once: don't use a work queue to reset sleepable static key"
  mm/hugetlb: fix missing migratable flag on same-node hugetlb migration
  mm/mempolicy: fix sleeping allocation in alloc_pages_bulk_weighted_interleave()
  mm/huge_memory: transfer the pmd dirty bit to the folio on zap
  MAINTAINERS: add Lance Yang as a hung task detector co-maintainer
  userfaultfd: reset err to be 0 when move_pages_ptes succeeded
  mm: fix incorrect vm_flags usage when checking allowable orders for tmpfs
  mm/hugetlb: keep max_huge_pages when dissolving surplus folios
  mm/migrate_device: avoid out-of-bounds writes for compound folios
  mm/hugetlb_cgroup: call page_counter_set_max() outside VM_BUG_ON()
  memcg: make the v1 soft limit knob inert
  mm/hugetlb_cma: fix null nodemask dereference in hugetlb_cma_alloc_frozen_folio
2026-09-03 17:59:19 -07:00
Randy Dunlap
fd9beb8870 nvme-tcp.h: drop kernel-doc comments, fix a few descriptions
Expand @fei into @feil and @feih because the field was split due to it
not being 32-bit aligned.

Struct member @hdr was described twice in struct nvme_tcp_rsp_pdu, so
drop one of them.

These structs are defined in a spec outside of the kernel, so kernel-doc
comments for them aren't needed here as well.

This avoids kernel-doc warnings:

Warning: include/linux/nvme-tcp.h:95 struct member 'rsvd2' not described in 'nvme_tcp_icreq_pdu'
Warning: include/linux/nvme-tcp.h:113 struct member 'rsvd' not described in 'nvme_tcp_icresp_pdu'
Warning: include/linux/nvme-tcp.h:128 struct member 'feil' not described in 'nvme_tcp_term_pdu'
Warning: include/linux/nvme-tcp.h:128 struct member 'feiu' not described in 'nvme_tcp_term_pdu'
Warning: include/linux/nvme-tcp.h:128 struct member 'rsvd' not described in 'nvme_tcp_term_pdu'
Warning: include/linux/nvme-tcp.h:169 struct member 'rsvd' not described in 'nvme_tcp_r2t_pdu'
Warning: include/linux/nvme-tcp.h:187 struct member 'rsvd' not described in 'nvme_tcp_data_pdu'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-09-03 14:15:11 -07:00
Niklas Cassel
56e6279266 nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails
nvmf_create_ctrl() owns the fabrics options and frees them whenever
->create_ctrl() returns an error, so a transport must not free them on
its own error paths.  nvme-fc tracks this by testing ctrl->ctrl.opts in
nvme_fc_ctrl_free(), which requires nvme_fc_init_ctrl() to clear that
pointer on every error exit.

The coupling is implicit, and commit 1a9e218195 ("nvme: split device
add from initialization") broke it by adding a second error exit.  When
nvme_add_ctrl() fails, nvme_fc_init_ctrl() jumps to out_put_ctrl:, past
the "ctrl->ctrl.opts = NULL" that only sits on the fail_ctrl: path, so
nvme_fc_ctrl_free() frees the options and nvmf_create_ctrl() frees them
a second time:

  BUG: KASAN: slab-use-after-free in nvmf_free_options+0x30/0x190
   nvmf_free_options+0x30/0x190 drivers/nvme/host/fabrics.c:1284
   nvmf_create_ctrl drivers/nvme/host/fabrics.c:1374 [inline]
  Freed by task 5534:
   nvme_fc_ctrl_free drivers/nvme/host/fc.c:2374 [inline]
   nvme_fc_init_ctrl+0xe17/0x1450 drivers/nvme/host/fc.c:3605

nvme_add_ctrl() fails when dev_set_name() cannot allocate, so this is
reachable under memory pressure or fault injection.  Without KASAN the
options are freed twice.

Rather than clear the pointer on the second exit as well, derive
ownership the way nvme-tcp, nvme-rdma and nvme-loop do, from list
membership: their free_ctrl leaves the options alone unless the
controller made it onto the transport list.

The list cannot simply be populated on the success path as it is there.
nvme-fc runs the initial connect synchronously via flush_delayed_work(),
and the controller has to be reachable on rport->ctrl_list for the whole
of it: nvme_fc_unregister_remoteport() needs to find it to signal
connectivity loss, nvme_fc_match_disconn_ls() matches an incoming
Disconnect Association LS against ctrl->association_id, which is only
assigned during that window, nvme_fc_resume_controller() needs it on
remoteport re-registration, and nvme_fc_existing_controller() uses it to
reject a duplicate connect racing the one in flight.

Keep the insertion where it is and add a fail_unlist: label, falling
into fail_ctrl:, for the error paths that run after it.  The earlier
error paths never reach the insertion and keep using fail_ctrl:
directly, so the list is only touched where the controller is actually
on it.

nvme_fc_ctrl_free() cannot use the plain "goto free_ctrl" the other
transports use, because it still has to put_device(), release the rport
reference and free the ida entry for resources taken before the
insertion.  Sample list_empty() under rport->lock instead.

ctrl->ctrl.opts also stays valid for the whole teardown now.  That is
not the bug being fixed, but it removes some fragility around the old
idiom: nvme_free_ctrl() calls nvme_auth_free() before ->free_ctrl(), and
ctrl_max_dhchaps() dereferences ctrl->opts without a NULL check when
ctrl->dhchap_ctxs is set, which nvme-fc permits since NVMF_ALLOWED_OPTS
allows the dhchap options.  The nvme sysfs attributes that dereference
ctrl->opts, such as hostnqn and address, evaluate their is_visible()
test once at device_add() time and stay readable until
cdev_device_del().

Fixes: 1a9e218195 ("nvme: split device add from initialization")
Cc: stable@vger.kernel.org
Reported-by: syzbot+f58e57380a6083c4041d@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=f58e57380a6083c4041d
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Tested-by: Rihyeon Kim <rihyeon8648@gmail.com>
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-09-03 14:15:11 -07:00
Seokgyu Choi
09d0c07bd9 nvmet: reject namespace enable without device path
A newly allocated namespace has a NULL device_path until userspace
configures the device_path attribute.

If buffered_io is enabled before device_path is configured,
nvmet_bdev_ns_enable() returns -ENOTBLK and nvmet_ns_enable() falls
back to nvmet_file_ns_enable(). The latter passes the NULL
device_path to filp_open(), causing a NULL pointer dereference in
getname_kernel().

Reject namespace enable when device_path has not been configured.

Reported-by: syzbot+f613f9f010ec98eb9d86@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=f613f9f010ec98eb9d86
Signed-off-by: Seokgyu Choi <tjrrb0313@gmail.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-09-03 14:15:11 -07:00
Kazuki Hanai
eaa948c0e1 nvmet-auth: Synchronize timeout work during SQ teardown
nvmet_auth_sq_free() cancels auth_expired_work with
cancel_delayed_work(). If the work has already started, cancellation does
not wait for the callback. Transport teardown can consequently free or
reuse the queue containing struct nvmet_sq while
nvmet_auth_expired_work() still accesses that SQ.

Add a teardown-specific helper that synchronously drains the delayed work
before freeing authentication state, and use it from nvmet_sq_destroy().
Keep the non-synchronous helper for in-band authentication state cleanup,
where the SQ owner remains alive.

Fixes: 1a70200f40 ("nvmet-auth: expire authentication sessions")
Cc: stable@vger.kernel.org
Signed-off-by: Kazuki Hanai <hnkz.64@gmail.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-09-03 14:15:11 -07:00
Keith Busch
5cdd07a688 MAINTAINERS: update nvme entry
Update Jens' entry to match the mail address of his other entries.

Acked-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-09-03 14:15:10 -07:00
Shivam Kumar
db62b35cbc nvmet-tcp: reject unsolicited H2CData PDUs
nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking
that its TTAG is a valid in-range command index and that the command's
data buffers are mapped. It never checks that the target has actually
solicited that data by sending an R2T for the command.

A remote host can abuse this. It submits a write command that takes the
R2T path and, before the target transmits the R2T, sends an H2CData PDU
for that command's tag. The data completes the command early, and when
the command then fails synchronously (e.g. a length mismatch caught by
nvmet_check_transfer_len()), it is completed a second time. Each
completion calls nvmet_tcp_queue_response(), so the same command is added
to queue->resp_list twice while it is still linked; the second llist_add()
makes the node point to itself (lentry->next == lentry).

nvmet_tcp_process_resp_list() then walks that self-referential node and
adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this
trips the "list_add double add" check (kernel BUG); without it the loop
never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is
remotely triggerable and needs no authentication on an allow_any_host
subsystem.

Track whether an R2T has been transmitted for a command and reject an
H2CData PDU that arrives before it. The flag is cleared on command reuse
(nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple
H2CData PDUs of a single solicited transfer.

Fixes: 872d26a391 ("nvmet-tcp: add NVMe over TCP target driver")
Cc: stable@vger.kernel.org
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Shivam Kumar <kumar.shivam43666@gmail.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-09-03 14:15:10 -07:00
Xixin Liu
08acb54b06 nvme-tcp: defer TLS inline send to io_work
blk_mq holds set->srcu while queuing and running requests.  The kTLS
software send path takes ctx->tx_lock.  lockdep knows that tx_lock
nests under elevator_lock which then waits on srcu, so an inline
send from that path under TLS triggers circular locking.

Skip the inline send optimization for TLS queues so the send runs
from the workqueue instead.  The same workqueue already retries TLS
sends on write-space notifications.  Plain TCP keeps the inline path.

Fixes: be8e82caa6 ("nvme-tcp: enable TLS handshake upcall")
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Signed-off-by: Xixin Liu <liuxixin@kylinos.cn>
Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-09-03 14:15:10 -07:00
Shivam Kumar
14cc5a7e77 nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU
nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte
queue->pdu union, then computes the remaining payload length as

	queue->left = hdr->hlen - queue->offset + hdgst;

and reads that many more bytes into &queue->pdu + queue->offset, without
ever bounding the result against sizeof(queue->pdu).

A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the
union. Once a header digest has been negotiated (hdgst = 4), a second
ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields
queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the
128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and
queue->data_digest. Those bytes are attacker-controlled (an ICReq
carries no digest), and the duplicate ICReq is only rejected later,
after the overflow. A remote unauthenticated host can thus corrupt
kernel memory adjacent to the receive buffer.

Reject any PDU whose declared length would read past the end of
queue->pdu before the second recv.

Fixes: 872d26a391 ("nvmet-tcp: add NVMe over TCP target driver")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Shivam Kumar <kumar.shivam43666@gmail.com>
Cc: stable@vger.kernel.org
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-09-03 14:15:10 -07:00
Yehyeong Lee
df7197ebc7 nvme-tcp: return -EPROTO for a C2HData on a write
The direction check in nvme_tcp_handle_c2h_data() returns -EIO.  A
C2HData PDU naming a command that did not ask for data is a protocol
violation, and the check that rejects a PDU on those grounds a few
lines below it - SUCCESS set without LAST - returns -EPROTO.

No caller distinguishes the two, so this changes the error code alone.

Suggested-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-09-03 14:15:10 -07:00