laptop-kernel/security, branch master

Merge tag 'landlock-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux

2026-10-11T18:49:08Z

Pull Landlock fix from Mickaël Salaün: "This fixes a Clang bug by removing an annotation, which was introduced mostly for documentation" * tag 'landlock-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux: landlock: Drop __counted_by from landlock_domain.handled_masks

landlock: Drop __counted_by from landlock_domain.handled_masks

2026-10-11T15:54:21Z

With clang 22 and CONFIG_FORTIFY_SOURCE, the second landlock_restrict_self() call hits a bogus fortify report in inherit_ruleset(): memcpy: detected buffer overflow: 4 byte write of buffer size 0 Call Trace: __fortify_panic landlock_merge_ruleset __se_sys_landlock_restrict_self handled_masks[] lives in an anonymous struct inside the anonymous union that overlays work_free. For such a flexible array, clang computes the address of the __counted_by counter as the start of the array instead of &num_layers. The bound is then read from handled_masks[0], i.e. from the first layer's access masks, which is not a count. The same layout crashes clang itself in a standalone test. The annotation was added as documentation, so drop it rather than restructure the union. Keep the information in the member comment. Reported-by: syzbot+a0eecb22de4d821a9e5d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a0eecb22de4d821a9e5d Fixes: bd3a19800dd1 ("landlock: Add counted_by in landlock_domain") Signed-off-by: Nguyen Ngoc Thang Link: https://lore.kernel.org/r/20261010164450.194439-1-ngocthang2710.1999@gmail.com Reviewed-by: Günther Noack Reported-by: Konrad Dybcio Reported-by: Mike Bommarito Closes: https://lore.kernel.org/r/20261009115108.17819-1-michael.bommarito@gmail.com [mic: Rebased on master, where the array is handled_masks[], updated the fortify report, added the clang bug link and the other reports] Signed-off-by: Mickaël Salaün

Merge tag 'keys-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd

2026-10-06T02:51:54Z

Pull keys fixes from Jarkko Sakkinen: - key_get_persistent() created a new persistent keyring if one did not exist, but failed to set a timeout on it in an error path, preventing GC. Call key_set_timeout() regardless of key_link() result if a persistent keyring was created. - __key_create_or_update() made a copy of keyring->restrict_link before holding keyring->sem, which could cause add_key() to be executed against stale keyring restrictions. Fix it by copying the value only after taking keyring->sem * tag 'keys-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd: KEYS: Fix add_key() race with keyring restriction keys: finalize persistent keyring timeout after link attempt

Merge tag 'selinux-pr-20261005' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux

2026-10-05T14:36:06Z

Pull selinux fixes from Paul Moore: - Preserve SECURITY_LSM_NATIVE_LABELS when reusing superblocks Similar to a previous fix (see the commit description of Stephen's fix) we need to check to see if we have already mounted/setup the superblock passed into the security_sb_set_mnt_opts() LSM hook so we don't mistakenly unset SECURITY_LSM_NATIVE_LABELS. - Fix a potential AVC sequence number data race * tag 'selinux-pr-20261005' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux: selinux: preserve NATIVE_LABELS on already-initialized sb in set_mnt_opts selinux: fix data race on AVC latest_notif

KEYS: Fix add_key() race with keyring restriction

2026-10-04T18:09:32Z

__key_create_or_update() snapshots keyring->restrict_link before taking the destination keyring's semaphore. keyring_restrict() installs a restriction while holding that semaphore. This allows a writer to observe no restriction, wait for the keyring owner to install a reject-all restriction and return successfully, and then link a key using the stale NULL snapshot. The writer only needs write permission on the destination keyring. Move the restrict_link read after __key_link_lock() and __key_link_begin(). The read and the subsequent restriction check are then serialized with restriction installation by keyring->sem. The race was reproduced on v7.2.8 in 19 executions where restriction installation returned before the link completed. All 19 linked the key despite the reject-all restriction. With this change, 312 executions reached the same ordering and every add_key() call failed with -EPERM. The issue was found by manual concurrency analysis assisted by AI-based analysis and independently verified with a QEMU reproducer and kernel instrumentation. Fixes: 5ac7eace2d00 ("KEYS: Add a facility to restrict new links into a keyring") Cc: stable@vger.kernel.org Signed-off-by: 성병찬 Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260930041802.6114-1-tjdqudcks0424@naver.com Signed-off-by: Jarkko Sakkinen

keys: finalize persistent keyring timeout after link attempt

2026-10-04T18:09:32Z

When no keyring exists for the requested UID, KEYCTL_GET_PERSISTENT creates and registers one before linking it to the requested destination. The configured timeout is set only after the destination link succeeds. A destination restricted with KEYCTL_RESTRICT_KEYRING makes that link fail with -EPERM. With persistent_keyring_expiry set to 60 seconds, /proc/keys still reports the registered keyring's expiry as "perm". The failed call therefore leaves a quota-exempt keyring in the namespace's hidden register, where it may remain until namespace teardown. Rename the write-locked helper to key_get_or_create_persistent() and return the key reference through a result parameter. Return 0 when it creates a keyring and 1 when the retry finds an existing one. Return a negative error on failure. Another caller may create the keyring between the initial read-locked lookup and the retry under the write lock. Set the timeout after permission checking and linking. Do this on success, or on failure if the call allocated the keyring. This leaves a new keyring collectible after failure without starting its timeout while linking is still in progress. Cc: stable@vger.kernel.org # v5.10+ Fixes: f36f8c75ae2e ("KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches") Assisted-by: LLM Signed-off-by: Karl Mehltretter Link: https://lore.kernel.org/r/20260912095440.79864-1-kmehltretter@gmail.com Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

selinux: preserve NATIVE_LABELS on already-initialized sb in set_mnt_opts

2026-09-30T19:10:41Z

When an NFSv4 filesystem exported with security_label is mounted a second time, sget_fc() returns the existing superblock and nfs_get_root() calls security_sb_set_mnt_opts() again on it. Since the superblock is already SB_INITIALIZED, selinux_set_mnt_opts() takes an early exit without setting SECURITY_LSM_NATIVE_LABELS in *set_kern_flags. nfs_get_root() then sees kflags without SECURITY_LSM_NATIVE_LABELS set and clears NFS_CAP_SECURITY_LABEL on the shared nfs_server, silently disabling per-file labeling for both the new and the original mount. Commit 3815a245b501 ("security/selinux: fix SECURITY_LSM_NATIVE_LABELS on reused superblock") fixed the same problem in selinux_sb_clone_mnt_opts(). The reused-superblock path for a plain second mount now goes through sb_set_mnt_opts rather than sb_clone_mnt_opts, so it needs the same treatment: on both SE_SBINITIALIZED early exits, set SECURITY_LSM_NATIVE_LABELS in *set_kern_flags when the superblock was already using SECURITY_FS_USE_NATVE. Cc: stable@vger.kernel.org Closes: https://github.com/SELinuxProject/selinux-kernel/issues/69 Closes: https://github.com/SELinuxProject/selinux-kernel/issues/70 Closes: https://github.com/SELinuxProject/selinux-testsuite/issues/91 Closes: https://github.com/SELinuxProject/selinux-testsuite/issues/92 Fixes: eb9ae686507b ("SELinux: Add new labeling type native labels") Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore

Merge tag 'ipe-pr-20260925' of git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe

2026-09-25T22:55:03Z

Pull IPE fixes from Fan Wu: "Two fixes for use-after-free issues found by recent LLM-assisted code analysis. - move successful policy load auditing under the new policy directory's inode lock, preventing a concurrent policy deletion from freeing the policy while it is still being audited - protect the dm-verity root hash with RCU, preventing policy evaluation from racing with root hash replacement during preresume" * tag 'ipe-pr-20260925' of git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe: ipe: protect the dm-verity root hash with RCU ipe: fix use-after-free when auditing a newly loaded policy

ipe: protect the dm-verity root hash with RCU

2026-09-25T20:30:27Z

ipe_bdev_setintegrity() frees the old root hash when dm-verity publishes a new one on ->preresume, while policy evaluation can still be dereferencing it. Protect the root hash with RCU. The evaluation path already runs under rcu_read_lock(). Fixes: e155858dd995 ("ipe: add support for dm-verity as a trust provider") Cc: stable@vger.kernel.org Assisted-by: LLM [FW: remove model name according to latest guideline] Signed-off-by: Fan Wu

ipe: fix use-after-free when auditing a newly loaded policy

2026-09-25T20:30:27Z

new_policy() audits the policy after ipe_new_policyfs_node() publishes it and drops the new directory's inode lock. A concurrent delete can free the policy while ipe_audit_policy_load() is still using it. Audit the successful load under that lock. Fixes: f44554b5067b ("audit,ipe: add IPE auditing support") Cc: stable@vger.kernel.org Assisted-by: LLM [FW: remove model name according to latest guideline] Signed-off-by: Fan Wu