linux-stable.git/security, branch v7.2-rc6

keys: make keyring key-chunk byte order agree with keyring_diff_objects()

2026-07-23T15:23:39+00:00

keyring_get_key_chunk() loads description bytes into the index chunk low
address first, while keyring_diff_objects() numbers the first differing
bit from the low end and folds the absolute byte index into the level
without removing the inline-prefix offset the level already carries.
The two disagree on byte order and bit position, so the array can be
told two keys first differ at a bit that does not differ in the chunk
the walker uses, letting crafted descriptions collide into one node.

Load the chunk in the order keyring_diff_objects() assumes and drop the
inline-prefix length when folding the byte index into the level.  This
only changes the in-memory ordering used to place keys within a keyring;
add, search and read of non-colliding keys are unaffected.

Fixes: f771fde82051 ("keys: Simplify key description management")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Michael Bommarito 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Jarkko Sakkinen 
Link: https://lore.kernel.org/r/20260719161505.2423935-3-michael.bommarito@gmail.com
Signed-off-by: Jarkko Sakkinen

keys: fix out-of-bounds read in keyring_get_key_chunk()

2026-07-23T15:23:32+00:00

For description-level chunks keyring_get_key_chunk() advances the read
pointer by level * sizeof(long) past the inline prefix but only
bounds-checks the prefix, so a long enough key description is read past
its kmemdup(desc, desc_len + 1) allocation.  Compute the full byte
offset and bounds-check the description against it before reading.

The walk only reaches a description-level chunk when two keys collide
through the hash, x, type and domain_tag chunks, so this is reached from
an unprivileged add_key(2) with a crafted pair of same-type keys whose
index hashes collide; KASAN reports a slab-out-of-bounds read.

Fixes: f771fde82051 ("keys: Simplify key description management")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Michael Bommarito 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Jarkko Sakkinen 
Link: https://lore.kernel.org/r/20260719161505.2423935-2-michael.bommarito@gmail.com
Signed-off-by: Jarkko Sakkinen

KEYS: trusted: dcp: fix key_len validation and calc_blob_len() return type

2026-07-23T15:23:23+00:00

Two correctness and type-hygiene issues exist in the DCP trusted keys
implementation.

First, trusted_dcp_unseal() reads p->key_len from a user-supplied blob
without checking if it exceeds MAX_KEY_SIZE.  If a crafted blob provides a
payload_len larger than 128, the subsequent do_aead_crypto() call writes
past the end of the p->key array into the adjacent p->blob buffer within
the same struct trusted_key_payload -- the caller's own input, not
unrelated kernel memory.  While not exploitable, this violates strict array
bounds and triggers static analyzers.  Fix this by adding a validation
check against MIN_KEY_SIZE and MAX_KEY_SIZE immediately after reading the
length, matching the checks already done in trusted_core.c.

Second, calc_blob_len() calculates a sum in size_t that truncates to
unsigned int on 64-bit platforms.  Because the DCP hardware is only present
on 32-bit i.MX SoC platforms, size_t and unsigned int are functionally
equivalent in production, making this truncation harmless in practice.
Nevertheless, updating the return type to size_t (and subsequently updating
'blen' in the seal/unseal paths) resolves type-narrowing warnings and
improves overall code hygiene.

Fixes: 2e8a0f40a39c ("KEYS: trusted: Introduce NXP DCP-backed trusted keys")
Signed-off-by: Fabrice Derepas 
Reviewed-by: David Gstir 
Reviewed-by: Richard Weinberger 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Jarkko Sakkinen 
Link: https://lore.kernel.org/r/20260719163939.3624767-1-fabrice.derepas@canonical.com
Signed-off-by: Jarkko Sakkinen

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

2026-07-17T18:04:46+00:00

Pull selinux fix from Paul Moore:
 "A single SELinux patch to correct a problem with the overlayfs mmap()
  and mprotect() fixes from earlier this year where we inadvertenly
  included an additional SELinux execmem permission check on some
  operations"

* tag 'selinux-pr-20260717' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux:
  selinux: fix incorrect execmem checks on overlayfs

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

2026-07-16T20:22:17+00:00

Pull landlock fix from Mickaël Salaün:
 "This fixes TCP Fast Open support, specific test environments, and doc
  warnings"

* tag 'landlock-7.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux:
  selftests/landlock: Skip scoped_signal subtest with MSG_OOB if not available
  selftests/landlock: Fix screwed up pointers in the scoped_signal_test
  landlock: Update formatting
  landlock: Fix kernel-doc for the nested quiet layer flag
  selftests/landlock: Add test for TCP fast open
  landlock: Fix TCP Fast Open connection bypass

selinux: fix incorrect execmem checks on overlayfs

2026-07-14T22:10:20+00:00

The commit fixing the overlayfs mmap() and mprotect() access checks
failed to skip the execmem check in __file_map_prot_check() for the case
where the "mounter check" is being performed. This check should be
performed only against the credentials of the task that is calling
mmap()/mprotect(), since it doesn't pertain to the file itself, but
rather just gates the ability of the calling task to get an executable
memory mapping in general.

The purpose of the "mounter check" is to guard against using an
overlayfs mount to gain file access that would otherwise be denied to
the mounter. For execmem this is not relevant, as there is no further
file access granted based on it (notice that the file's context is not
used as the target in the check), so checking it also against the
mounter credentials would be incorrect.

Fix this by passing a boolean to [__]file_map_prot_check() and
selinux_mmap_file_common() that indicates if we are doing the "mounter
check" and skiping the execmem check in that case. Since this boolean
also indicates if we use current_cred() or the mounter cred as the
subject, also remove the "cred" argument from these functions and
determine it based on the boolean and the file struct.

Cc: stable@vger.kernel.org
Fixes: 82544d36b172 ("selinux: fix overlayfs mmap() and mprotect() access checks")
Signed-off-by: Ondrej Mosnacek 
Reviewed-by: Stephen Smalley 
Signed-off-by: Paul Moore

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

2026-07-11T01:59:29+00:00

Pull selinux fixes from Paul Moore:
 "Two small SELinux patches to fix a missing permission check for TCP
  Fast Open operations and fix a socket lookup issue with SCTP ASCONF
  operations"

* tag 'selinux-pr-20260710' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux:
  selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()
  selinux: check connect-related permissions on TCP Fast Open

landlock: Update formatting

2026-07-10T10:59:10+00:00

Following commit 99df2a8eba34 ("clang-format: fix formatting of guard()
and scoped_guard() statements"), update scoped_guard() formatting.
Also, see the related fix [1].

Cc: Günther Noack 
Cc: Miguel Ojeda 
Link: https://lore.kernel.org/r/20260708105713.2073335-1-mic@digikod.net [1]
Link: https://patch.msgid.link/20260708110635.2083515-1-mic@digikod.net
Reviewed-by: Günther Noack 
Signed-off-by: Mickaël Salaün

landlock: Fix kernel-doc for the nested quiet layer flag

2026-07-10T10:59:09+00:00

kernel-doc emits "Excess struct member 'quiet' description in
'landlock_layer'" because "quiet" is a bitfield inside the named nested
struct "flags", but its inline comment used the bare member name
"@quiet:", which kernel-doc attributes to the enclosing landlock_layer.

Use the canonical dotted notation "@flags.quiet:" so kernel-doc resolves
the nested member, and include it in the generated documentation.

Cc: Justin Suess 
Cc: Tingmao Wang 
Fixes: a260c0055665 ("landlock: Add a place for flags to layer rules")
Link: https://patch.msgid.link/20260703141711.2016964-1-mic@digikod.net
Signed-off-by: Mickaël Salaün

landlock: Fix TCP Fast Open connection bypass

2026-07-10T10:59:07+00:00

The documentation of the socket_connect() LSM hook states that it
controls connecting a socket to a remote address. It has not been the
case since the addition of TCP Fast Open (RFC 7413) support, which
allows opening a TCP connection (thus, setting a socket's destination
address) via the MSG_FASTOPEN flag passed to
sendto()/sendmsg()/sendmmsg(). The problem then got duplicated into
MPTCP.

Landlock did not take it into account when its TCP support was added,
leaving a bypass of TCP connect policy.

Ideally a call to the LSM hook would be added in the fastopen code path,
in order to fix this generically. But connect() hooks are designed to
run with the socket locked, unlike sendmsg() hooks.

Closes: https://github.com/landlock-lsm/linux/issues/41
Fixes: fff69fb03dde ("landlock: Support network rules with TCP bind and connect")
Signed-off-by: Matthieu Buffet 
Link: https://patch.msgid.link/20260701214628.33319-1-matthieu@buffet.re
Cc: stable@vger.kernel.org
[mic: Wrap commit message]
Signed-off-by: Mickaël Salaün