Skip to content

tcpm_update_sink_capabilities: place port->ignore_alt_modes write inside port->lock critical region - #19

Open
rdevshp wants to merge 79 commits into
GrapheneOS:17from
rdevshp:race_tcpm_sink_alt_modes_fix
Open

tcpm_update_sink_capabilities: place port->ignore_alt_modes write inside port->lock critical region#19
rdevshp wants to merge 79 commits into
GrapheneOS:17from
rdevshp:race_tcpm_sink_alt_modes_fix

Conversation

@rdevshp

@rdevshp rdevshp commented Jun 28, 2026

Copy link
Copy Markdown

(pasted from #16 )
There are potential race conditions for port->ignore_alt_modes. This PR protects the write to port->ignore_alt_modes with the port->lock critical region.

thestinger and others added 30 commits June 16, 2026 00:09
Based on the public grsecurity patches.

Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Signed-off-by: Daniel Micay <danielmicay@gmail.com>
Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Signed-off-by: Daniel Micay <danielmicay@gmail.com>
Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Stack mapping entropy is currently hard-wired to 11 bits of entropy on
32-bit and 18 bits of entropy on 64-bit. The stack itself gains an extra
8 bits of entropy from lower bit randomization within 16 byte alignment
constraints. The argument block could have all lower bits randomized but
it currently only gets the mapping randomization.

Rather than hard-wiring values this switches to using the mmap entropy
configuration like the mmap base and executable base, resulting in a
range of 8 to 16 bits on 32-bit and 18 to 24 bits on 64-bit (with 4k
pages and 3 level page tables) depending on kernel configuration and
overridable via the sysctl entries.

It's worth noting that since these kernel configuration options default
to the minimum supported entropy value, the entropy on 32-bit will drop
from 11 to 8 bits for builds using the defaults. However, following the
configuration seems like the right thing to do regardless. At the very
least, changing the defaults for COMPAT (32-bit processes on 64-bit)
should be considered due to the larger address space compared to real
32-bit.

Signed-off-by: Daniel Micay <danielmicay@gmail.com>
Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
This was based on the PaX RANDUSTACK feature in grsecurity, where all of
the lower bits are randomized. PaX keeps 16-byte alignment.

maade: as part of porting to 6.1, get_random_int() was replaced by get_random_u32()

Signed-off-by: Daniel Micay <danielmicay@gmail.com>
[levente@leventepolyak.net: do not randomize with ADDR_NO_RANDOMIZE personality]
Signed-off-by: Levente Polyak <levente@leventepolyak.net>
Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
This adds support for arch_randomize_brk implementations not performing
page alignment in order to randomize the lower bits of the brk heap.

This idea is taken from PaX but the approach is different. This reuses
the existing code and avoids forcing early creation of the heap mapping,
avoiding mapping it if it's not used which is the case with many modern
allocators based solely on mmap.

The malloc implementation can be relied upon to align this as needed to
the requirements it has, so using 16 byte alignment here is unnecessary.

Signed-off-by: Daniel Micay <danielmicay@gmail.com>
Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Per PaX, but for this alternate brk randomization approach.

As part of the v5.4 linux-hardened rebase, this commit was adapted from
the arm64 specific brk randomization to all arches that use the generic
topdown mmap layout functions, introduced in e7142bf ("arm64, mm:
make randomization selected by generic topdown mmap layout").

Signed-off-by: Daniel Micay <danielmicay@gmail.com>
Signed-off-by: Levente Polyak <levente@leventepolyak.net>
Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Per PaX, but for this alternate brk randomization approach.

As part of the v5.4 linux-hardened rebase, this commit was adapted from
the arm64 specific brk randomization to all arches that use the generic
topdown mmap layout functions, introduced in e7142bf ("arm64, mm:
make randomization selected by generic topdown mmap layout").

Signed-off-by: Daniel Micay <danielmicay@gmail.com>
Signed-off-by: Levente Polyak <levente@leventepolyak.net>
Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Most of this is extracted from the last publicly available version of
the PaX patches where it's part of KERNEXEC as __read_only. It has been
extended to a few more of these constants.

maade: hung_task_timeout_max was moved to kernel/hung_task.c

Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Change-Id: I51c602675f67db0ba5257c3f4460fdd29517a5f1
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Signed-off-by: Daniel Micay <danielmicay@gmail.com>
Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
This was extracted from the PaX patch where it's part of the KERNEXEC
feature as __read_only.

Signed-off-by: Daniel Micay <danielmicay@gmail.com>
Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Note: __cacheline_aligned_in_smp conflicts with __ro_after_init on x86.

Extracted from PaX.

Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Change-Id: I62166df621b46e9d5272fe456df156e73878c429
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Signed-off-by: randomhydrosol <randomhydrosol@glassrom.org>
Place canaries at the end of kernel slab allocations, sacrificing
some performance and memory usage for security.

Canaries can detect some forms of heap corruption when allocations
are freed and as part of the HARDENED_USERCOPY feature. It provides
basic use-after-free detection for HARDENED_USERCOPY.

Canaries absorb small overflows (rendering them harmless), mitigate
non-NUL terminated C string overflows on 64-bit via a guaranteed zero
byte and provide basic double-free detection.

Signed-off-by: Daniel Micay <danielmicay@gmail.com>
[levente@leventepolyak.net: make canaries work without SLUB_DEBUG]
[levente@leventepolyak.net: fix compatibility with KFENCE]
Signed-off-by: Levente Polyak <levente@leventepolyak.net>
thestinger and others added 19 commits June 16, 2026 00:09
…ng the linear region"

This reverts commit 9ed19a5.

There was a minor conflict from the CPU feature being renamed.
This is needed to enable forced module for signing with pKVM protected
modules, which are loaded at device_initcall_sync(), before the trusted
system keyring could be initialized and populated.
…t_on_free"

This reverts commit 7e1ae40 with the
hook definitions left intact for compatibility.
commit 48f6a5356a33dd78e7144ae1faef95ffc990aae0 upstream.

Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail
to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when
moving frags from source to destination.  __pskb_copy_fclone() defers
the rest of the shinfo metadata to skb_copy_header() after copying
frag descriptors, but that helper only carries over gso_{size,segs,
type} and never touches skb_shinfo()->flags; skb_shift() moves frag
descriptors directly and leaves flags untouched.  As a result, the
destination skb keeps a reference to the same externally-owned or
page-cache-backed pages while reporting skb_has_shared_frag() as
false.

The mismatch is harmful in any in-place writer that uses
skb_has_shared_frag() to decide whether shared pages must be detoured
through skb_cow_data().  ESP input is one such writer (esp4.c,
esp6.c), and a single nft 'dup to <local>' rule -- or any other
nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d
skb in esp_input() with the marker stripped, letting an unprivileged
user write into the page cache of a root-owned read-only file via
authencesn-ESN stray writes.

Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors
were actually moved from the source.  skb_copy() and skb_copy_expand()
share skb_copy_header() too but linearize all paged data into freshly
allocated head storage and emerge with nr_frags == 0, so
skb_has_shared_frag() returns false on its own; they need no change.

The same omission exists in skb_gro_receive() and skb_gro_receive_list().
The former moves the incoming skb's frag descriptors into the
accumulator's last sub-skb via two paths (a direct frag-move loop and
the head_frag + memcpy path); the latter chains the incoming skb whole
onto p's frag_list.  Downstream skb_segment() reads only
skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's
shinfo as the nskb -- both p and lp must carry the marker.

The same omission also exists in tcp_clone_payload(), which builds an
MTU probe skb by moving frag descriptors from skbs on sk_write_queue
into a freshly allocated nskb.  The helper falls into the same family
and warrants the same fix for consistency; no TCP TX-side in-place
writer is currently known to reach a user page through this gap, but
a future consumer depending on the marker would regress silently.

The same omission exists in skb_segment(): the per-iteration flag
merge takes only head_skb's flag, and the inner switch that rebinds
frag_skb to list_skb on head_skb-frags exhaustion does not fold the
new frag_skb's flag into nskb.  Fold frag_skb's flag at both sites
so segments drawing frags from frag_list members carry the marker.

Fixes: cef401d ("net: fix possible wrong checksum generation")
Fixes: f4c50a4034e6 ("xfrm: esp: avoid in-place decrypt on shared skb frags")
Suggested-by: Sabrina Dubroca <sd@queasysnail.net>
Suggested-by: Sultan Alsawaf <sultan@kerneltoast.com>
Suggested-by: Ben Hutchings <ben@decadent.org.uk>
Suggested-by: Lin Ma <malin89@huawei.com>
Suggested-by: Jingguo Tan <tanjingguo@huawei.com>
Suggested-by: Aaron Esau <aaron1esau@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
Tested-by: Rajat Gupta <rajat.gupta@oss.qualcomm.com>
Link: https://patch.msgid.link/ageeJfJHwgzmKXbh@v4bel
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
[bwh: Backported to 6.6: skb_gro_receive_list() is in
 net/ipv4/udp_offload.c here]
Signed-off-by: Ben Hutchings <benh@debian.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@rdevshp rdevshp changed the title Race tcpm sink alt modes fix tcpm_update_sink_capabilities: place port->ignore_alt_modes write inside port->lock critical region Jun 28, 2026
@thestinger
thestinger force-pushed the 17 branch 2 times, most recently from 30b8188 to d1e8b8c Compare July 12, 2026 20:36
@thestinger
thestinger force-pushed the 17 branch 2 times, most recently from 346080f to b8e91c8 Compare July 23, 2026 19:14
@thestinger
thestinger force-pushed the 17 branch 2 times, most recently from 92a9892 to e83d225 Compare August 8, 2026 06:54
@thestinger
thestinger force-pushed the 17 branch 2 times, most recently from 1e86bdf to 05369a3 Compare August 27, 2026 16:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants