summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-08-15perf dso: Guard against cache underflow on short reads in dso_cache__memcpy()Arnaldo Carvalho de Melo
dso_cache__memcpy() computes cache_offset = offset - cache->offset, then cache_size = min(cache->size - cache_offset, size). The RB tree lookup in __dso_cache__find() matches using the full DSO__DATA_CACHE_SIZE window, but cache->size reflects the actual pread return value from dso_cache__populate(). A short pread (e.g. near end-of-file) makes cache->size smaller than DSO__DATA_CACHE_SIZE. If a subsequent access targets an offset past cache->offset + cache->size but within the DSO__DATA_CACHE_SIZE window, the cache entry is found but cache_offset exceeds cache->size. Since both are u64, the subtraction cache->size - cache_offset wraps to a large value, min() selects the caller's size, and memcpy reads out of bounds. Return 0 for an offset past the valid cached data. For a regular file a short pread only happens at end-of-file, so 0 is what a direct pread() at that offset would return: cached_io() stops its read loop as on EOF. Re-reading from the backing file would not help — a second pread at the same offset returns the same short count. Fixes: 366df72657e0 ("perf dso: Refactor dso_cache__read()") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Reviewed-by: Ian Rogers <irogers@google.com> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2026-08-15perf dso: Use stored fd error instead of stale errno in file_read() and ↵Arnaldo Carvalho de Melo
file_size() file_read() and file_size() use ret = -errno when dso__data(dso)->fd is negative after try_to_open_dso() fails. By this point errno has been through mutex_lock(), nsinfo__mountns_enter(), and multiple open() attempts inside try_to_open_dso() — it no longer reflects the actual open failure. If errno happens to be 0, ret = 0 looks like EOF rather than an error, and file_size() callers like dso__data_size() would then report a zero-sized file instead of failing. dso__data(dso)->fd is always negative on failure — -errno from __open_dso() when no filename could be built (e.g. -EINVAL, -ENOENT), or -1 when do_open() itself failed — and never 0, so use it directly instead of reading the stale global errno. No assert() or comment is needed after the assignment: the enclosing if (dso__data(dso)->fd < 0) already guarantees ret < 0 [Namhyung Kim review]. Fixes: 33bdedcea2d7 ("perf tools: Protect dso cache fd with a mutex") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Reviewed-by: Ian Rogers <irogers@google.com> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2026-08-15perf dso: Guard close() against invalid fd in dso__decompress_kmodule_path()Arnaldo Carvalho de Melo
dso__decompress_kmodule_path() unconditionally calls close(fd) on the return value of decompress_kmodule(). When decompression fails or the DSO is not compressed, decompress_kmodule() returns -1. close(-1) fails with EBADF and clobbers errno, which callers up the chain (dso__get_filename → __open_dso) depend on for error propagation. Guard the close() call with fd >= 0 so only valid file descriptors are closed. Fixes: 42b3fa670825 ("perf tools: Introduce dso__decompress_kmodule_{fd,path}") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Reviewed-by: Ian Rogers <irogers@google.com> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2026-08-15perf dso: Guard against errno==0 when dso__get_filename() returns NULLArnaldo Carvalho de Melo
__open_dso() computes fd = -errno when dso__get_filename() returns NULL. Some failure paths in dso__get_filename() (e.g. binary type mismatch) return NULL without making a syscall, leaving errno at 0 from a prior successful call. fd = -0 = 0, which is stdin — subsequent code treats it as a valid file descriptor. Fall back to ENOENT when errno is 0, ensuring fd is always negative on failure. The forced ENOENT stays in errno for the callers that check it after a negative fd. It must not misdirect the try_to_open_dso() fallback loop, though: dso__get_filename()'s chroot fallback used to accept a stale ENOENT even when stat() succeeded on a non-regular file (e.g. a directory). Re-stat() there and only take the chroot path when stat() actually failed with ENOENT [sashiko-bot review of PATCH 1/5]. Fixes: eba5102d2f0b ("perf tools: Add global list of opened dso objects") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Reviewed-by: Ian Rogers <irogers@google.com> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2026-08-15sched_ext: Rename balance-era identifiers to dispatch termsTejun Heo
sched_class->balance() is gone from sched_ext and what balance_one() does is run dispatch to produce something pickable. Update the balance-era names to dispatch terms: - balance_one() -> dispatch_one() - SCX_RQ_IN_BALANCE -> SCX_RQ_IN_DISPATCH No BPF scheduler reads the flag. The enum autogen headers gain the new name with the old entry retained like other removed enumerators, zero-filling at load time. No functional changes. Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-15sched_ext: Drop the stale keep_prev fixup in dispatch_pick()Tejun Heo
The fixup demoting a keep verdict when @prev is not on ext_sched_class guarded against the rq-level SCX_RQ_BAL_KEEP flag going stale back when balancing and picking were separate operations. The verdict now travels in the return value, created and consumed in one invocation against the @prev it evaluated, and every keep decision tests SCX_TASK_QUEUED under the rq lock, which implies ext_sched_class as a class switch dequeues first. Drop the fixup along with dispatch_core_pick()'s copy. Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-15sched_ext: Keep kick_sync waiting on the rq's own CPUTejun Heo
kick_sync_wait_bal_cb() assumes it runs on the rq's CPU from the __schedule() tail: the snapshots it compares against live in that CPU's percpu area and the busy-wait runs with the rq lock dropped and IRQs enabled. However, dispatch can now drop the rq lock while the callback sits queued, and rq lock takers in that window (the sched class change paths, the scx task iterator) flush pending balance callbacks on release, running the callback on a foreign CPU. Such a run compares against unrelated snapshots and can deadlock when the executing CPU is itself a wait target. Bail on a foreign CPU and leave the wait state alone. The wait only observes progress that the resched kicks already guarantee and the rq's next wait picks up the stale cpus_to_sync bits. Fixes: 4c95380701f5 ("sched/ext: Fold balance_scx() into pick_task_scx()") Cc: stable@vger.kernel.org # v6.19+ Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-14sched_ext: Make SCHED_CLASS_EXT select GENERIC_ALLOCATORTejun Heo
kernel/sched/ext/arena.c uses the gen_pool allocator, which is built only when GENERIC_ALLOCATOR is set. SCHED_CLASS_EXT doesn't select it, so on configs where nothing else does, the build fails to link: build_policy.o: undefined reference to `gen_pool_create' build_policy.o: undefined reference to `gen_pool_for_each_chunk' build_policy.o: undefined reference to `gen_pool_destroy' Fixes: 9eca087deb0b ("sched_ext: Sub-allocator over kernel-claimed BPF arena pages") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202608151315.tvN3X0Oq-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202608151632.3p91bTQj-lkp@intel.com/ Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-14sched_ext/scx_flatcg: Fix cvtime true-up on slice expiryTao Cui
fcg_dispatch() true-ups the current cgroup's cvtime when its slice expires or its DSQ runs empty while the slice is still active: __sync_fetch_and_add(&cgc->cvtime_delta, (cpuc->cur_at + cgrp_slice_ns - now) * FCG_HWEIGHT_ONE / (cgc->hweight ?: 1)); The true-up should be actual minus charged: on CNS_EXPIRE, the overrun (now - cur_at - cgrp_slice_ns) should be added; on CNS_EMPTY, the unused portion of the slice should be subtracted. The expression above has the sign inverted, and in the CNS_EXPIRE case now is already past cur_at + cgrp_slice_ns, so the u64 subtraction wraps. The multiplication preserves the two's complement encoding but the unsigned division by hweight destroys it, adding roughly 2^64/hweight per expiry instead of a small correction. Under saturation the hweight budget clamp in cgrp_cap_budget() masks most of the garbage, so the weight distribution barely moves, but the accounting is broken all the same. Compute the delta as a signed value and use fetch_and_add()/fetch_and_sub() so that the dividends stay positive, as BPF division is unsigned. Instrumented the true-up and ran a saturated three-leaf cgroup tree on a 4-CPU VM: without the fix, each expiry added ~5e15 (2^64/hweight territory) to cvtime_delta; with it, the corrections are back to slice scale, with the overrun added and the unused portion subtracted. Fixes: a4103eacc2ab ("sched_ext: Add a cgroup scheduler which uses flattened hierarchy") Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Tao Cui <cuitao@kylinos.cn> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-14sched_ext: Don't BUG_ON a destroyed DSQ in process_deferred_reenq_usersTao Cui
scx_bpf_dsq_reenq() queues a deferred reenq (dru) that runs from run_deferred(), not ops.dispatch(). If the DSQ is destroyed before the dru runs, process_deferred_reenq_users() sees dsq->id == SCX_DSQ_INVALID and hits the BUG_ON. destroy_dsq() doesn't flush pending drus, so just skip. tj: Read dsq->id once with READ_ONCE(). Reading it separately in the INVALID check and the BUG_ON would leave a window where destroy_dsq() can invalidate the id between the two reads and still trigger the BUG_ON. Fixes: 84b1a0ea0b7c ("sched_ext: Implement scx_bpf_dsq_reenq() for user DSQs") Cc: stable@vger.kernel.org # v7.1+ Signed-off-by: Tao Cui <cuitao@kylinos.cn> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-14sched_ext: Fix scx_bpf_dsq_move_to_local___v2 compat detectionfangqiurong
libbpf strips the last ___flavor suffix when resolving kfunc externs, so the bare ___v2 declaration resolves to scx_bpf_dsq_move_to_local, whose BTF proto lacks @enq_flags. The extern never matches, bpf_ksym_exists() returns false on every kernel that has the ___v2 kfunc, and the macro falls back to ___v1, silently dropping @enq_flags. Add the trailing ___compat suffix used by the other versioned externs in this file (scx_bpf_dsq_insert___v2, scx_bpf_reenqueue_local___v2). Any caller passing non-zero @enq_flags through the compat macro silently loses them. Fixes: 860683763ebf ("sched_ext: Add enq_flags to scx_bpf_dsq_move_to_local()") Cc: stable@vger.kernel.org # v7.1+ Assisted-by: Z.ai:glm-5.2 Signed-off-by: fangqiurong <fangqiurong@kylinos.cn> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-14sched_ext: Make scx_bpf_events() read the calling scheduler's countersTejun Heo
scx_bpf_events() always reads the root scheduler's event counters, so a sub-scheduler program querying its own events silently gets the root's instead and has no BPF-visible way to read its own (the per-scheduler sysfs "events" file is the only interface). Resolve the scheduler from the calling program with scx_prog_sched(). Unassociated programs follow the usual scx_prog_sched() resolution: the root scheduler under a pre-sub-attach compat root and zeroed counters otherwise. Also fix up the malformed comment into proper kerneldoc. Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-14sched_ext: Drop unlocked scx_rq_clock_invalidate() from scx_root_disable()Tejun Heo
scx_root_disable() invalidates each rq's clock before taking the rq lock. scx_rq_clock_invalidate() is a plain read-modify-write of rq->scx.flags and every other writer of the word runs under the rq lock, so the unlocked update can race a concurrent flags update and lose one side's bits. The invalidation doesn't matter in the first place. The cached clock is read only by scx_bpf_now() from a loaded scheduler's BPF programs, nothing can re-validate the clock while sched_ext is disabled as scx_rq_clock_update() is gated on scx_enabled() too, and the usual rq lock cycles under the next scheduler refresh or invalidate it before it's practically observable. Drop the invalidation instead of fixing the locking. v2: Description and comment updated - the invalidation is unnecessary rather than subsumed by the rq lock cycle below. Fixes: 3a9910b5904d ("sched_ext: Implement scx_bpf_now()") Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Changwoo Min <changwoo@igalia.com>
2026-08-15fbdev: atyfb: Convert to managed PCI and ioremap APIShixiong Ou
Fix missing pci_disable_device() in probe and remove. Use pcim_enable_device(), pcim_request_region(), devm_ioremap(), devm_ioremap_uc() and devm_ioremap_wc() for the PCI path. Convert aux_start to devm_request_mem_region(). Guard atyfb_remove() to only unmap/release for non-PCI (Atari) devices. Keep iounmap for sprite.addr outside the guard since it uses raw ioremap(). Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Signed-off-by: Helge Deller <deller@gmx.de>
2026-08-15fbdev: matrox: Convert to managed PCI and ioremap APIShixiong Ou
Fix missing pci_disable_device() in probe and remove. Use pcim_enable_device(), devm_request_mem_region(), devm_ioremap() and devm_ioremap_wc() to replace manual resource management. Remove all release_mem_region() and iounmap() calls. Use devm_request_mem_region() instead of pcim_request_region() because the requested sizes (16384 for MMIO, maxvram for FB) do not match the full PCI BAR sizes. Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Signed-off-by: Helge Deller <deller@gmx.de>
2026-08-15fbdev: savage: Convert to managed PCI and ioremap APIShixiong Ou
Fix missing pci_disable_device() in probe and remove. Use pcim_enable_device(), pcim_request_all_regions(), devm_ioremap() and devm_ioremap_wc() to replace manual resource management. Remove all pci_release_regions() and iounmap() calls. Merge failed_init label into failed_enable. Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Signed-off-by: Helge Deller <deller@gmx.de>
2026-08-15fbdev: nvidia: Convert to managed PCI and ioremap APIShixiong Ou
Fix missing pci_disable_device() in probe and remove. Use pcim_enable_device(), pcim_request_all_regions(), devm_ioremap() and devm_ioremap_wc() to replace manual resource management. Remove all pci_release_regions() and iounmap() calls. Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Signed-off-by: Helge Deller <deller@gmx.de>
2026-08-15fbdev: aty128fb: Convert to managed PCI and ioremap APIShixiong Ou
Fix missing pci_disable_device() in probe and remove. Use pcim_enable_device(), pcim_request_region(), devm_ioremap() and devm_ioremap_wc() to replace manual resource management. Remove all release_mem_region() and iounmap() calls. Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Signed-off-by: Helge Deller <deller@gmx.de>
2026-08-15samples/landlock: Add LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS to samplerJustin Suess
Add LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS to the default flag setting. Gate the flag on the ABI version, but do not expose any userspace control over this flag as it has no practical effect on the resulting sandbox. Signed-off-by: Justin Suess <utilityemal77@gmail.com> Link: https://patch.msgid.link/20260809154544.1253100-6-utilityemal77@gmail.com Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-08-15landlock: Document LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVSJustin Suess
Document setting no_new_privs with ruleset enforcement, following the same compatibility section style as previous ABI additions. Include a section explaining the tradeoffs of setting no_new_privs through any means for privileged users of Landlock. Signed-off-by: Justin Suess <utilityemal77@gmail.com> Link: https://patch.msgid.link/20260809154544.1253100-5-utilityemal77@gmail.com Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-08-15selftests/landlock: Test LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVSJustin Suess
Check that a successful landlock_restrict_self(2) call with LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS sets no_new_privs without a prior prctl(2) call nor CAP_SYS_ADMIN, that a failed call from both an invalid ruleset and hitting the layer maximum leaves the attribute unchanged, and that LANDLOCK_RESTRICT_SELF_TSYNC extends it to sibling threads. Also check that this flag requires a ruleset. Turn the multi_threaded_success test into a multi_threaded fixture with success, no_new_privs, and no_new_privs_max_layers variants to factor out the threading code. Finally, rename restrict_self_fd_logging_flags to restrict_self_fd_flags, and restrict_self_logging_flags to restrict_self_flags to indicate that non-logging flags are now tested. Test coverage for security/landlock is 91.8% of 2373 lines according to LLVM 22. Signed-off-by: Justin Suess <utilityemal77@gmail.com> Link: https://patch.msgid.link/20260809154544.1253100-4-utilityemal77@gmail.com Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-08-15landlock: Add LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVSJustin Suess
Add a landlock_restrict_self(2) flag to set the no_new_privs attribute of the calling thread only after enforcement of the ruleset: no_new_privs is set if and only if the call succeeds. This removes the need for a prior prctl(2) PR_SET_NO_NEW_PRIVS call and guarantees that a failed enforcement leaves the attribute unchanged. Because no_new_privs is set by the call itself, the no_new_privs / CAP_SYS_ADMIN requirement of landlock_restrict_self(2) is fulfilled by construction, and the related EPERM check is skipped. Unlike LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF, this flag always requires a valid ruleset: with a ruleset_fd of -1, such a call would be nothing more than a Landlock-flavored prctl(2) PR_SET_NO_NEW_PRIVS, and there is no valid use case for setting no_new_privs (possibly with LANDLOCK_RESTRICT_SELF_TSYNC) without also enforcing Landlock restrictions. Rejecting these calls also keeps the option of giving them a meaning later. The attribute is only set past the last point of failure, just before committing the new credentials. When combined with LANDLOCK_RESTRICT_SELF_TSYNC, no_new_privs is set on the sibling threads as well, in their commit phase, with the same ordering. Bump the Landlock ABI version to 11, and include the minimal related test changes to keep the tests bisectable. Cc: Mickaël Salaün <mic@digikod.net> Signed-off-by: Justin Suess <utilityemal77@gmail.com> Link: https://patch.msgid.link/20260809212459.2427878-1-utilityemal77@gmail.com Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-08-15landlock: Check landlock_restrict_self(2)'s flags before privilegesJustin Suess
landlock_restrict_self(2) currently checks the no_new_privs / CAP_SYS_ADMIN requirement before validating the flags argument. An unprivileged caller without no_new_privs thus gets EPERM even when the passed flags are invalid, hiding the EINVAL error. Move the no_new_privs / CAP_SYS_ADMIN check just after the flags check so that malformed calls consistently error out with EINVAL whatever the caller's privileges, the same way seccomp(2) validates its flags before checking no_new_privs. Update the restrict_self_checks_ordering test accordingly. Cc: Mickaël Salaün <mic@digikod.net> Signed-off-by: Justin Suess <utilityemal77@gmail.com> Link: https://patch.msgid.link/20260809154544.1253100-2-utilityemal77@gmail.com Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-08-15landlock: Link the erratum documentation for whiteout objectsGünther Noack
The documentation embeds the canonical erratum documentation from the header file, which is already a self-contained description of the issue. Signed-off-by: Günther Noack <gnoack@google.com> Link: https://patch.msgid.link/20260813093157.1436894-7-gnoack@google.com [mic: Update the documentation date] Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-08-15selftests/landlock: Test whiteout object behaviour in OverlayFS renamesGünther Noack
Even though OverlayFS uses vfs_rename() with RENAME_WHITEOUT on its backing directories, and even though RENAME_WHITEOUT requires LANDLOCK_ACCESS_FS_MAKE_REG, a process that renames non-regular files in an OverlayFS can do so without having the LANDLOCK_ACCESS_FS_MAKE_REG right in that location. This works, and is supposed to work, because the changes to the backing directories are done by OverlayFS, not by the originator task that did the original rename() on the OverlayFS mount. Therefore, the changes done to backing directories are not subject to the originator task's credentials. Test coverage for security/landlock is 91.8% of 2368 lines according to LLVM 22. Signed-off-by: Günther Noack <gnoack@google.com> Link: https://patch.msgid.link/20260813093157.1436894-6-gnoack@google.com [mic: Add test coverage, reflow commit message] Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-08-15selftests/landlock: Add audit test for whiteout object creationGünther Noack
Add audit_layout1.make_whiteout: This test looks similar to audit_layout1.make_char, but creates a whiteout object through mknod(). Since whiteout object creation is now guarded with LANDLOCK_ACCESS_FS_MAKE_REG rather than LANDLOCK_ACCESS_FS_MAKE_CHAR, it also needs to log the matching denial to audit. Signed-off-by: Günther Noack <gnoack@google.com> Link: https://patch.msgid.link/20260813093157.1436894-5-gnoack@google.com Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-08-15selftests/landlock: Add tests for whiteout object creationGünther Noack
Add tests to check that whiteout object creation is guarded by LANDLOCK_ACCESS_FS_MAKE_REG, in the cases where these are created from userspace: * Conventional creation with mknod() * Linking or renaming an existing whiteout object * renameat2() with RENAME_WHITEOUT, which creates a new whiteout object in the source location * renameat2() with RENAME_EXCHANGE, with one of the renamed objects being a whiteout object Signed-off-by: Günther Noack <gnoack@google.com> Link: https://patch.msgid.link/20260813093157.1436894-4-gnoack@google.com [mic: Update commit message as requested] Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-08-15landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creationGünther Noack
Whiteout objects are used in the upper layer of an OverlayFS to indicate that the file with this name does not exist in the unified view, even if it is present in one of the lower layer file systems. For the userspace implementations of OverlayFS (fuse-overlayfs), whiteout objects can be created from userspace as well: * mknod(2) with S_IFCHR and makedev(0, 0) * renameat2(2) with RENAME_WHITEOUT, creating the whiteout in the old place of the moved file. This commit guards whiteout creation in both of these cases with LANDLOCK_ACCESS_FS_MAKE_REG. Whiteout objects are *not* considered character devices and are not bound to a driver. LANDLOCK_ACCESS_FS_MAKE_REG describes the same permission class as a whiteout object: creating one is the only S_IFCHR creation that the VFS exempts from CAP_MKNOD, so it is as unprivileged as creating a regular file, while LANDLOCK_ACCESS_FS_MAKE_CHAR and LANDLOCK_ACCESS_FS_MAKE_BLOCK keep meaning the creation of devices that expose a kernel interface [1]. For the mknod(2) case, introduce a Landlock erratum. The creation of whiteout objects through mknod(2) was previously guarded using LANDLOCK_ACCESS_FS_MAKE_CHAR, and it is now guarded using LANDLOCK_ACCESS_FS_MAKE_REG. For the renameat2(2) case, fix a bug: Before this commit, renameat2(2) with RENAME_WHITEOUT would create a directory entry even when all LANDLOCK_ACCESS_FS_MAKE_* rights were denied. This does not affect normal renames within layered OverlayFS mounts: When doing a regular rename() on a mounted fuse-overlayfs, it is the fuse-overlayfs daemon that exercises renameat2() with RENAME_WHITEOUT, and only the Landlock domain of that daemon is checked there. Suggested-by: Christian Brauner <brauner@kernel.org> Suggested-by: Mickaël Salaün <mic@digikod.net> Cc: stable@vger.kernel.org Fixes: cb2c7d1a1776 ("landlock: Support filesystem access-control") Depends-on: 49c9e09d9610 ("landlock: Fix handling of disconnected directories") Depends-on: fe72ce6710cb ("landlock: Add errata documentation section") Signed-off-by: Günther Noack <gnoack@google.com> Link: https://patch.msgid.link/20260720.chow9ohYie5b@digikod.net [1] Link: https://patch.msgid.link/20260813093157.1436894-3-gnoack@google.com [mic: Record why LANDLOCK_ACCESS_FS_MAKE_REG is the matching right, and add link(2) to the user doc] Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-08-15selftests/landlock: Use an actual chardev for MAKE_CHAR audit testGünther Noack
By passing a (0, 0) device number, the audit test for LANDLOCK_ACCESS_FS_MAKE_CHAR was accidentally creating a whiteout object rather than a char device. In preparation to treating whiteout objects differently, use an actual character device instead. Signed-off-by: Günther Noack <gnoack@google.com> Link: https://patch.msgid.link/20260813093157.1436894-2-gnoack@google.com Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-08-14Merge branch 'bpf-x86-fix-per-cpu-address-resolution-into-an-extended-register'Eduard Zingerman
Vineet Gupta says: ==================== bpf, x86: fix per-CPU address resolution into an extended register The JIT resolves a per-CPU address with add <dst>, gs:[this_cpu_off] but builds the REX prefix with add_1mod(), which sets REX.B. The destination is encoded in ModRM.reg, which REX.R extends, and the memory operand is disp32 with no base, so REX.B does nothing and the high register bit is dropped. Every extended destination therefore resolves into whichever register shares the low three bits: R5 -> RAX R7 -> RBP R8 -> RSI R9 -> RDI The address is left unadjusted and an unrelated register is clobbered. Patch 1 switches to add_2mod() so the bit goes through REX.R. Clang reloads the address into R1 before each per-CPU access, so the destination is never an extended register and the bug has been dormant since v6.10. GCC keeps several per-CPU addresses live at once, which is how it turned up: test_progs-bpf_gcc panics the kernel in global_percpu_data/init, with the address of a .percpu variable in R5. Patch 2 covers every register. A functional test only catches this if the address happens to land in an extended register, so the test matches the JITed add instead. Changes in v3: - Fold the five per-register programs into one that loads every register, and drop the comment explaining the register choice (Eduard Zingerman). - Move the percpu_data declaration inside the arch guard, so other targets no longer carry a .percpu section and an unused map (bpf-ci). - Match the movabsq of each address as well as the add, so the matchers stay on consecutive lines and the pair is checked to use the same register. - Restore the Reviewed-by on patch 1, dropped by mistake in v2. Changes in v2: - Add the selftest, patch 2/2 (Eduard Zingerman). It uses __jited() rather than __xlated(): the xlated stream is identical for every register, and the wrong prefix is only visible in the native encoding. - No functional change to patch 1. ==================== Link: https://patch.msgid.link/20260814220254.3797467-1-vineet.gupta@linux.dev Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-08-14selftests/bpf: Check per-CPU address resolution per registerVineet Gupta
An ld_imm64 of a per-CPU map value is followed by a mov_percpu_addr that reuses the same register, so which register the address lands in decides how the JIT encodes the add. Getting the REX prefix wrong there is invisible to a functional test unless the address happens to land in an extended register, which is why this went unnoticed. Load a .percpu variable into every register in one program and match the JITed add against the register each one must resolve into. Signed-off-by: Vineet Gupta <vineet.gupta@linux.dev> Link: https://patch.msgid.link/20260814220254.3797467-3-vineet.gupta@linux.dev Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-08-14bpf, x86: Fix per-CPU address resolution into an extended registerVineet Gupta
The destination of the per-CPU address MOV is encoded in ModRM.reg, which is extended by REX.R, but the REX prefix is built with add_1mod(), which sets REX.B. REX.B extends ModRM.rm and SIB.base, and this instruction addresses memory as disp32 with no base, so the bit has no effect at all and the high register bit is simply lost. Every is_ereg() destination therefore resolves to the wrong register, picking whichever one shares the low three bits: R5 -> RAX R7 -> RBP R8 -> RSI R9 -> RDI With BPF_REG_5, whose reg2hex is 0, the emitted 65 49 03 04 25 <off> add %gs:<off>,%rax adds the per-CPU offset to RAX rather than R8. The destination keeps the unadjusted address and RAX is clobbered, so the program goes on to dereference a pointer that was never made per-CPU: BUG: unable to handle page fault for address: 0000607e386a8894 RIP: bpf_prog_707837aafd2aa9ae_update_percpu_data+0x93/0xc9 Call Trace: __bpf_prog_test_run_raw_tp+0x2dc/0x7d0 __flush_smp_call_function_queue+0x1e9/0xc80 Kernel panic - not syncing: Fatal exception in interrupt R5 is the mildest of the four, aliasing a scratch register and faulting at the store. R7 aliases RBP and would corrupt the frame pointer, R8 and R9 alias the argument registers. Use add_2mod() so the register goes through REX.R, matching how add_2reg() places it in ModRM.reg and how emit_priv_frame_ptr() hardcodes 0x4c for the same instruction with R9. Encodings for the non-extended registers are unchanged. Problem showed up when trying to resurrect BPF_GCC CI (selftests built with BPF_GCC). This has gone unnoticed because clang reloads the address into R1 before each per-CPU access, so the destination is never an extended register. GCC keeps several per-CPU addresses live at once, and test_progs-bpf_gcc panics the kernel in global_percpu_data/init, where the address of a .percpu variable ends up in R5. Fixes: 7bdbf7446305 ("bpf: add special internal-only MOV instruction to resolve per-CPU addrs") Signed-off-by: Vineet Gupta <vineet.gupta@linux.dev> Reviewed-by: Eduard Zingerman <eddyz87@gmail.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260814220254.3797467-2-vineet.gupta@linux.dev Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-08-15openrisc: drop unneeded semicolonJulia Lawall
When a function-like macro expands to an expression, that expression doesn't need a semicolon after it. All uses have been verified to have their own semicolons. This was found using the following Coccinelle semantic patch: @r@ identifier i : script:ocaml() { String.lowercase_ascii i = i }; expression e; @@ *#define i(...) e; Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by: Stafford Horne <shorne@gmail.com>
2026-08-15openrisc: signal: do not restore privileged SR bits on sigreturnAli Ahmet Memis
restore_sigcontext() copies the whole supervision register (SR) from the signal frame and only clears SPR_SR_SM before the value is reloaded into the hardware SR (through ESR and l.rfe) on the return to user space. All other SR bits are left under user control. An unprivileged task can thus return from a signal handler through a crafted sigframe that clears SPR_SR_DME. With the data MMU disabled the CPU performs no translation or protection on data accesses, so the task gains read and write access to arbitrary physical memory, a local privilege escalation. SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH and the cache-enable bits are exposed the same way. The ptrace GPR regset already refuses any change to SR for exactly this reason. Restore only the arithmetic flag bits (F, CY, OV) from the signal frame and take every privileged control bit from the SR the kernel saved on signal entry. Verified with qemu-system-or1k -M or1k-sim: before this change an unprivileged PoC clears SPR_SR_DME in rt_sigreturn and writes a marker to physical address 0x03000000 (beyond the kernel's mem=32M); afterwards the same PoC receives SIGSEGV and physical memory is unchanged. Fixes: ac689eb7f9d4 ("OpenRISC: Signal handling") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis <ali@iusegentoo.com> Signed-off-by: Stafford Horne <shorne@gmail.com>
2026-08-14Merge tag 'input-for-v7.2-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input fixes from Dmitry Torokhov: - A couple of fixes to the sur40 touchscreen driver to correct registration and teardown ordering, and to fix error path unwinding when video device registration fails. * tag 'input-for-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: sur40 - fix V4L error path cleanup Input: sur40 - fix input device registration ordering
2026-08-14Merge branch 'next' into for-linusDmitry Torokhov
Prepare input updates for 7.3 merge window.
2026-08-15crypto: lskcipher - propagate errors from unaligned cryptKarl Mehltretter
The while loop declares a second err variable that shadows the outer one. When the crypt callback fails, the goto out path returns the outer err, which still holds the -ENOMEM value assigned before the successful allocation check. The real error from the cipher is discarded and the caller sees -ENOMEM instead. Drop the inner declaration so the callback error reaches the caller. Verified with a test module that registers an lskcipher whose encrypt callback fails with -EIO and calls it through a misaligned buffer. An unpatched kernel returns -ENOMEM, a patched kernel returns -EIO. Found with Clang's -Wshadow. Fixes: 31865c4c4db2b ("crypto: skcipher - Add lskcipher") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-08-15crypto: keembay - use crypto_memneq() to compare CCM AEAD tagsDavid C.C.M. Gall
Use crypto_memneq() for constant-time comparison. The CCM path in ocs-aes.c verifes the received authentication tag with memcmp(), which returns early on the first mismatched byte. This leaks valid-prefix length and allows for valid tag forgery which violates the INT-CTXT guarantee of AEAD. Assisted-by: gregkh_clanker_t1000 Signed-off-by: David C.C.M. Gall <david.ccm.gall@googlemail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-08-15crypto: keembay - use crypto_memneq() to compare GCM AEAD tagsDavid C.C.M. Gall
Use crypto_memneq() for constant-time comparison. The GCM path in keembay-ocs-aes-core.c verifes the received authentication tag with memcmp(), which returns early on the first mismatched byte. This leaks valid-prefix length and allows for valid tag forgery which violates the INT-CTXT guarantee of AEAD. Assisted-by: gregkh_clanker_t1000 Signed-off-by: David C.C.M. Gall <david.ccm.gall@googlemail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-08-15crypto: sa2ul - use crypto_memneq() to compare AEAD tagDavid C.C.M. Gall
Use crypto_memneq() for a constant-time comparison. sa_aead_dma_in_callback() compares the computed authentication tag against the received tag with memcmp(), which short-circuits on the first differing byte. An attacker who can submit decrypt requests and observe completion latency could recover the expected tag byte by byte. Valid tag forgery for AEAD breaks the INT-CTXT guarantee. Assisted-by: gregkh_clanker_t1000 Signed-off-by: David C.C.M. Gall <david.ccm.gall@googlemail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-08-15hwrng: drivers - use named initializers for acpi_device_idPawel Zalewski (The Capable Hub)
Use a named initializer for the acpi_device_id fields which makes the code more readable and consistent with how lists are initialized in the rest of the kernel code base. Also drop explicitly setting fields to 0 where it is redundant. Signed-off-by: Pawel Zalewski (The Capable Hub) <pzalewski@thegoodpenguin.co.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-08-15crypto: qce - fix CCM AAD buffer underallocationMd Sadre Alam
The AAD buffer allocated in qce_aead_ccm_prepare_buf_assoclen() can be smaller than the length later programmed into the DMA scatterlist. The allocation size is currently calculated as: ALIGN(assoclen, 16) + MAX_CCM_ADATA_HEADER_LEN while the DMA length is set to: ALIGN(assoclen + adata_header_len, 16) Since ALIGN() does not distribute over addition, the allocation can be smaller than the DMA length. For example, when assoclen = 32 and adata_header_len = 2: allocation = ALIGN(32, 16) + 6 = 38 DMA length = ALIGN(32 + 2, 16) = 48 As a result, the QCE hardware can read beyond the allocated buffer while computing the CBC-MAC over the associated data. The extra bytes are folded into the authentication tag, resulting in an incorrect tag and causing CCM self-test failures such as: alg: aead: ccm-aes-qce encryption test failed (wrong result) on test vector 8 Fix the allocation by adding the maximum possible AAD header length before alignment: ALIGN(assoclen + MAX_CCM_ADATA_HEADER_LEN, 16) This guarantees that the allocated buffer is large enough for the fully padded AAD data for all supported header sizes. Cc: stable@vger.kernel.org Fixes: 9363efb4181c ("crypto: qce - Add support for AEAD algorithms") Signed-off-by: Md Sadre Alam <md.alam@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-08-15crypto: iaa - unmap dst before software fallback on decompressVinicius Costa Gomes
On a hardware analytics error, decompress retries through the software fallback, which writes req->dst with the CPU while it is still mapped DMA_FROM_DEVICE. With SWIOTLB active the later dma_unmap_sg() copies the stale bounce buffer over req->dst, corrupting the result. Unmap before the fallback runs. The async path unmaps inline; the sync path signals the retry with -EAGAIN so iaa_comp_adecompress() runs the fallback after unmapping. Fixes: 2ec6761df889 ("crypto: iaa - Add support for deflate-iaa compression algorithm") Cc: stable@vger.kernel.org Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-08-15crypto: iaa - use bounce buffer for multi-sg decompress inputGiovanni Cabiddu
Since commit e2c3b6b21c77 ("mm: zswap: use SG list decompression APIs from zsmalloc"), zswap passes the raw zsmalloc SG list directly to crypto drivers, so a compressed object spanning multiple pages reaches IAA as a multi-entry source. Such requests currently fall back to software decompression. As IAA hardware requires a single DMA source buffer, linearize small multi-entry sources into a pre-allocated bounce page and submit that to the hardware instead of falling back to software. Keep the software fallback only for multi-entry destinations. This recovers most of the performance lost by using the software fallback. Store the bounce-page state in the acomp request context alongside the existing compression CRC, free it through a shared source-unmap helper, and back the pages with a small module-wide mempool so the path remains available in reclaim-driven callers. Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-08-15crypto: iaa - avoid counting fallback decompression bytesGiovanni Cabiddu
When decompression falls back to deflate-generic after an analytics error, the request no longer completes through IAA. Move decompression byte accounting into the successful IAA completion path in both the synchronous and asynchronous flows so decomp_bytes only reflects bytes actually processed by IAA. Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-08-15crypto: iaa - fall back to software for multi-entry scatterlistsGiovanni Cabiddu
IAA cannot process source or destination scatterlists with more than one entry directly. Instead of failing these requests, route them through a separate deflate acomp transform and keep the request alive in software. The IAA driver has never handled multi-entry scatterlists, but the limitation was latent until commit e2c3b6b21c77 ("mm: zswap: use SG list decompression APIs from zsmalloc") made zswap pass the raw zsmalloc SG list directly to crypto drivers, so objects spanning multiple pages now reach IAA as multi-entry sources and would otherwise fail decompression. Fallback to the generic DEFLATE implementation for scatterlists with more than one entry. After the multi-entry cases fall back early, simplify the DMA mapping path to a single scatterlist entry and fall back on mapping failure as well. Add counters to track the number of requests processed by the software implementation on the compression direction. Fixes: 2ec6761df889 ("crypto: iaa - Add support for deflate-iaa compression algorithm") Fixes: e2c3b6b21c77 ("mm: zswap: use SG list decompression APIs from zsmalloc") Cc: stable@vger.kernel.org Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-08-15hwrng: core - Stop/start hwrng_fillfn() kthread before/after suspend-resumeThomas Richard (TI)
The hwrng_fillfn() kernel thread accesses the RNG device directly. During suspend and resume sequences, hwrng_fillfn() may attempt to access the RNG device while it is suspended. To address this, the hwrng_fillfn() kernel thread is stopped before suspend, and restarted after resume. This is done using the pm_notifier mechanism. Issue was found while doing suspend-to-ram on J721S2 EVM board with omap-rng driver. echo mem > /sys/power/state [ 27.922259] PM: suspend entry (deep) [ 27.927191] Filesystems sync: 0.000 seconds [ 27.933858] Freezing user space processes [ 27.939119] Freezing user space processes completed (elapsed 0.001 seconds) [ 27.946090] OOM killer disabled. [ 27.949315] Freezing remaining freezable tasks [ 27.954887] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 27.963337] GFP mask restricted [ 27.967069] omap_rng 4e10000.rng: PM: calling platform_pm_suspend @ 195, parent: 4e00000.crypto [ 27.967072] mmcblk mmc1:9fb0: PM: calling mmc_bus_suspend @ 122, parent: mmc1 [ 27.968636] mmcblk mmc1:9fb0: PM: mmc_bus_suspend returned 0 after 1546 usecs [ 27.975778] omap_rng 4e10000.rng: PM: platform_pm_suspend returned 0 after 3 usecs ... [ 33.510667] ti-sci 44083000.system-controller: PM: ti_sci_suspend_noirq returned 0 after 0 usecs [ 33.510671] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError [ 33.510681] CPU: 0 UID: 0 PID: 132 Comm: hwrng Tainted: G M W 7.0.0-12695-g8923b7a6e11d #19 PREEMPT [ 33.510690] Tainted: [M]=MACHINE_CHECK, [W]=WARN [ 33.510693] Hardware name: Texas Instruments J721S2 EVM (DT) [ 33.510697] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 33.510701] pc : omap_rng_do_read+0x3c/0xe0 [ 33.510709] lr : omap_rng_do_read+0x58/0xe0 [ 33.510712] sp : ffff80008942be00 [ 33.510713] x29: ffff80008942be00 x28: 0000000000000000 x27: 0000000000000000 [ 33.510719] x26: 0000000000000010 x25: 0000000000000010 x24: ffff0008065644e8 [ 33.510724] x23: ffff8000878b3370 x22: ffff00080148b2c0 x21: 0000000000000000 [ 33.510728] x20: ffff000806564480 x19: 0000000000000064 x18: 0000000000000000 [ 33.510732] x17: 6573752031207265 x16: 7466612030206465 x15: 6e72757465722071 [ 33.510737] x14: ffff0008062c8080 x13: 000031702bc0da42 x12: 0000000000000001 [ 33.510741] x11: 00000000000000c0 x10: 0000000000000b30 x9 : ffff80008942bc80 [ 33.510745] x8 : ffff0008062c8b90 x7 : ffff000b7dfa34c0 x6 : 0000000805ca16c1 [ 33.510749] x5 : 0000000000000000 x4 : ffff800080e17bfc x3 : ffff800087389c68 [ 33.510753] x2 : 0000000000000000 x1 : 0000000000000010 x0 : 000000000000a7c6 [ 33.510759] Kernel panic - not syncing: Asynchronous SError Interrupt [ 33.510762] CPU: 0 UID: 0 PID: 132 Comm: hwrng Tainted: G M W 7.0.0-12695-g8923b7a6e11d #19 PREEMPT [ 33.510767] Tainted: [M]=MACHINE_CHECK, [W]=WARN [ 33.510768] Hardware name: Texas Instruments J721S2 EVM (DT) [ 33.510770] Call trace: [ 33.510772] show_stack+0x18/0x24 (C) [ 33.510780] dump_stack_lvl+0x34/0x8c [ 33.510788] dump_stack+0x18/0x24 [ 33.510792] vpanic+0x47c/0x4dc [ 33.510799] do_panic_on_target_cpu+0x0/0x1c [ 33.510803] add_taint+0x0/0xbc [ 33.510807] arm64_serror_panic+0x70/0x80 [ 33.510812] do_serror+0x3c/0x70 [ 33.510815] el1h_64_error_handler+0x34/0x50 [ 33.510823] el1h_64_error+0x6c/0x70 [ 33.510827] omap_rng_do_read+0x3c/0xe0 (P) [ 33.510831] hwrng_fillfn+0x98/0x330 [ 33.510834] kthread+0x130/0x13c [ 33.510845] ret_from_fork+0x10/0x20 [ 33.510850] SMP: stopping secondary CPUs [ 33.519442] Kernel Offset: disabled [ 33.519444] CPU features: 0x04000000,800a0008,00040001,0400421b [ 33.519448] Memory Limit: none [ 33.732904] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]--- Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-08-15crypto: hisilicon/sec2 - fix CCM algorithm long packet failureZhushuai Yin
In the CCM B0 block the message-length field Q spans L bytes, where L (cl in the driver) is derived from the cipher IV flags byte as c_ivin[0] + 1. set_aead_auth_iv() hardcoded writing only the last 2 bytes of a_ivin with cryptlen, implicitly assuming cl = 2. When cl = 3 (a shorter nonce yielding a 3-byte length field) and the packet is longer than 65535 bytes, cryptlen no longer fits in 2 bytes. The dropped high byte made the auth IV built by the driver differ from the one consumed by the hardware, so the software/hardware comparison failed and the CCM request errored out. Write the last cl bytes of a_ivin in a loop driven by the IV's CL value, so the length-field width always matches the algorithm configuration instead of assuming a fixed 2-byte field. Fixes: c16a70c1f253 ("crypto: hisilicon/sec - add new algorithm mode for AEAD") Signed-off-by: Zhushuai Yin <yinzhushuai@huawei.com> Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-08-15crypto: eip93 - use struct_size() and flexible array for ring allocationRosen Penev
Embed the single ring as a flexible array member in eip93_device instead of allocating it separately. This simplifies the probe path and uses struct_size() for a single allocation. Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-08-15crypto: krb5 - use kfree_sensitive() for derived key buffersJan Sebastian Götte
crypto_krb5_prepare_encryption() and crypto_krb5_prepare_checksum() free the buffer holding the freshly derived keys with plain kfree(), leaving the key material behind in the freed slab object. Fixes: 3936f02bf2d3 ("crypto/krb5: Implement Kerberos crypto core") Cc: stable@vger.kernel.org Signed-off-by: Jan Sebastian Götte <linux@jaseg.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>