kernel/git/stable/linux.git/arch/x86/entry, branch master

Merge tag 'x86_entry_for_7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-08-19T00:38:30+00:00

Pull x86 entry update from Dave Hansen: "Fix frame pointer unwinder when it encounters FRED stack frames" * tag 'x86_entry_for_7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/entry/fred: Encode frame pointer on entry

Merge tag 'timers-vdso-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-08-18T23:56:25+00:00

Pull VDSO updates from Thomas Gleixner: - Consolidate the VDSO datastore further and provide support for mlock_all() and prefaulting. - Provide 32-bit legacy time related functionality only if CONFIG_COMPAT_32BIT_TIME is enabled. The config switch exists, but architecture code still exposes the legacy functionality even disabled. Clean this up by adding the missing guards and validating at build time that the VDSO is legacy free if disabled. - Consolidate the VDSO related config options in core and drivers, which removes some non-sensical dependencies and quite an amount of #ifdeffery. - Clean up the PAGE_SIZE definition maze * tag 'timers-vdso-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (30 commits) random: vDSO: Drop custom PAGE_SIZE definitions LoongArch: Remove CONFIG_GENERIC_GETTIMEOFDAY ifdeffery clocksource/drivers/timer-riscv: Remove CONFIG_GENERIC_GETTIMEOFDAY ifdeffery clocksource/drivers/arm_arch_timer: Remove CONFIG_GENERIC_GETTIMEOFDAY ifdeffery clocksource/drivers/mips-gic-timer: Remove CONFIG_GENERIC_GETTIMEOFDAY ifdeffery MIPS: csrc-r4k: Remove CONFIG_GENERIC_GETTIMEOFDAY ifdeffery vDSO: Make clockmode constants available without CONFIG_GENERIC_GETTIMEOFDAY kbuild: Support generated asm-headers in subdirectories vdso: Rename HAVE_GENERIC_VDSO to VDSO_DATASTORE vdso: Drop HAVE_GENERIC_VDSO from architecture kconfig files vdso: Automatically select HAVE_GENERIC_VDSO if necessary MIPS: vdso: Stop using CONFIG_HAVE_GENERIC_VDSO vdso: Remove the dependency on HAVE_GENERIC_VDSO from ARCH_HAS_VDSO_ARCH_DATA futex: Remove dependency on HAVE_GENERIC_VDSO from FUTEX_ROBUST_UNLOCK vdso/gettimeofday: Verify COMPAT_32BIT_TIME interactions sparc: vdso: Respect COMPAT_32BIT_TIME MIPS: VDSO: Respect COMPAT_32BIT_TIME powerpc/vdso: Respect COMPAT_32BIT_TIME ARM: VDSO: Respect COMPAT_32BIT_TIME arm64: vdso32: Respect COMPAT_32BIT_TIME ...

Merge tag 'core-entry-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-08-18T22:00:56+00:00

Pull generic entry code updates from Thomas Gleixner: - Make syscall user dispatching configurable Not all architectures can makes use of syscall user dispatching. Allow them to disable the feature completely. - Consolidate stack randomization for the generic entry code and the architectures using it. Stack randomization on syscall entry was sprinkled throughout the architecture specific low level entry code and in some cases at the wrong points, e.g. before establishing state, which violates the non-instrumentable constraints of that code. Clean this up by integrating stack randomization into the generic entry code helpers so that it is invoked at the earliest possible point right after establishing state and converting all generic entry code using architecture over. - Clean up the syscall number handling in the generic entry code. It works correctly for architectures which have a separate return value storage in pt_regs, but fails to distinguish the case where user space handed in -1 as syscall number from the case where the entry code rejects it by returning -1 to the callers. Aside of that the return value functionality of those interfaces is not really intuitive. Fix this by separating the decision to reject a syscall (user dispatch, ptrace, seccomp ...) from the potential modification of the syscall number through these mechanisms. This solves most of the problems for architectures which do not have a separate return value storage in pt_regs except for the case where a tracepoint has a BPF script or a probe attached which overwrite both the syscall number and the return value. But that's a problem which cannot be solved in the generic code, that only can be addressed by separating the storage model in the affected architectures. * tag 'core-entry-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (23 commits) entry, treewide: Make syscall_enter_from_user_mode[_work]() indicate syscall execution entry: Make return type of syscall_trace_enter() bool entry: Rework trace_syscall_enter() entry: Rework syscall_audit_enter() syscall_user_dispatch: Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCH entry: Fix seccomp bypass after ptrace with TSYNC x86/entry: Simplify the syscall number logic x86/entry: Get rid of the sys_ni_syscall() indirection x86/entry: Make syscall functions static ptrace, treewide: Rename ptrace_report_syscall_entry() to ptrace_report_syscall_permit_entry() seccomp, treewide: Rename and convert __secure_computing() to return boolean entry: Use syscall number instead of rereading it entry: Remove syscall_enter_from_user_mode() x86/syscall: Use [syscall_]enter_from_user_mode_randomize_stack() s390/syscall: Use enter_from_user_mode_randomize_stack() riscv/syscall: Use syscall_enter_from_user_mode_randomize_stack() powerpc/syscall: Use syscall_enter_from_user_mode_randomize_stack() loongarch/syscall: Use syscall_enter_from_user_mode_randomize_stack() entry: Provide [syscall_]enter_from_user_mode_randomize_stack() randomize_kstack: Provide add_random_kstack_offset_irqsoff() ...

Merge tag 'vfs-7.3-rc1.failfs' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

2026-08-17T16:15:52+00:00

Pull failfs filesystem from Christian Brauner: "Add failfs and expose a FD_FAILFS_ROOT sentinel. This allows userspace to shed their filesystem state completely. A process with its root or working directory in failfs must anchor every path lookup at an explicit file descriptor. Absolute paths, absolute symlinks and AT_FDCWD-relative lookups simply fail. Failfs is the counterpart to nullfs. nullfs says adds a permanently empty, immutable directory whose lookups fail with ENOENT but which can be opened, read, stat'd and mounted upon. Failfs on the other hand fails every operation. The root cannot be opened at all. A single instance is mounted during early boot via kern_mount(), which makes it logically distinct from every mount namespace. This is accompanied by a new fchroot() system call which makes chrooting via a file descriptor a first class concept. It's possible to chroot into failfs as an unprivileged user provided the task has no new privileges set" * tag 'vfs-7.3-rc1.failfs' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: Documentation: add failfs documentation selftests/filesystems: add failfs selftests arch: hookup fchroot() system call fs: support FD_FAILFS_ROOT in fchroot() fs: add fchroot() fs: support FD_FAILFS_ROOT in fchdir() fs: add failfs

arch: hookup fchroot() system call

2026-07-27T15:18:00+00:00

Wire up the fchroot() system call as number 472 on (nearly) all architectures and sync the mirrored copies of the syscall tables and the asm-generic unistd.h under tools/. Link: https://patch.msgid.link/20260724-work-failfs-v2-5-485dabbae185@kernel.org Signed-off-by: Christian Brauner (Amutable)

x86/bugs: Make Safe-RET robust against interrupt injection

2026-07-26T14:21:37+00:00

An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by "emulating" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt. Co-developed-by: David Kaplan Signed-off-by: David Kaplan Signed-off-by: Borislav Petkov (AMD)

entry, treewide: Make syscall_enter_from_user_mode[_work]() indicate syscall execution

2026-07-20T18:38:40+00:00

The return values of syscall_enter_from_user_mode[_work]() are non-intuitive. Both functions return the syscall number which should be invoked by the architecture specific syscall entry code. The returned number can be: - the unmodified syscall number which was handed in by the caller - a modified syscall number (ptrace, seccomp, trace/probe/bpf) That has an additional twist. If the return value is -1L then the caller is not allowed to modify the return value as that indicates that the modifying entity requests to abort the syscall and set the return value already. That can obviously not be differentiated from a syscall which handed in -1 as syscall number. The most trivial way to deal with that is: set_return_value(regs, -ENOSYS); nr = syscall_enter_from_user_mode(regs, nr); if (valid(nr)) handle_syscall(regs, nr); That's what LOONGARCH, RISCV, and X86 do. But PowerPC and S390 do not preset the return value, so when user space hands in -1 and there is nothing setting the return value in the entry work code, then the syscall is skipped but the return value is whatever random data has been in the return value register. Change the return values of syscall_enter_from_user_mode[_work]() to boolean and return false, when either ptrace or seccomp request to skip the syscall. If they return true, update the syscall number as it might have been changed. That results in slightly different behaviour of the architectures versus tracing. If the syscall tracepoint has probe/BPF attached, those might set the syscall number to -1 and also set the return value. PowerPC and S390 will then overwrite that value with -ENOSYS. The other architectures will just ignore it like any other invalid syscall and use the modified one. Originally-by: Michal Suchánek Signed-off-by: Thomas Gleixner Tested-by: Michal Suchánek Link: https://patch.msgid.link/20260712141346.772209074@kernel.org

x86/entry/fred: Encode frame pointer on entry

2026-07-14T18:08:12+00:00

Add missing ENCODE_FRAME_POINTER macro invocation into FRED_ENTER macro, to prevent the unwinder from encountering a NULL stack frame pointer when CONFIG_UNWINDER_FRAME_POINTER is enabled Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") Signed-off-by: David Stevens Signed-off-by: Dave Hansen Acked-by: H. Peter Anvin (Intel) Link: https://patch.msgid.link/20260424191456.2679717-12-stevensd@google.com

x86/entry: Simplify the syscall number logic

2026-07-12T10:38:02+00:00

Converting from int to long, back to int and then to unsigned int is confusing at best. None of this voodoo is required. Negative syscall numbers including -1 don't need any of this treatment and the low level ASM code already does the sign extension to 64-bit on a 64-bit kernel. The only point where signedness matters is the comparison against the maximum syscall number, but that can be simplified by just using a unsigned argument for the various syscall invocation functions. Signed-off-by: Thomas Gleixner Tested-by: Mukesh Kumar Chaurasiya (IBM) Link: https://patch.msgid.link/20260707190254.545214398@kernel.org

x86/entry: Get rid of the sys_ni_syscall() indirection

2026-07-12T10:38:02+00:00

Invoking sys_ni_syscall() from a code path, which already knows that the syscall number is invalid just to assign -ENOSYS to regs->ax is a pointless exercise. It's even redundant as the low level entry code already has set regs->ax to -ENOSYS on entry. Remove the extra conditionals and the function calls. Signed-off-by: Thomas Gleixner Tested-by: Mukesh Kumar Chaurasiya (IBM) Reviewed-by: Jinjie Ruan Link: https://patch.msgid.link/20260707190254.493733289@kernel.org