tcpm_update_sink_capabilities: place port->ignore_alt_modes write inside port->lock critical region - #19
Open
rdevshp wants to merge 79 commits into
Open
tcpm_update_sink_capabilities: place port->ignore_alt_modes write inside port->lock critical region#19rdevshp wants to merge 79 commits into
rdevshp wants to merge 79 commits into
Conversation
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>
…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>
…ide port->lock critical region
thestinger
force-pushed
the
17
branch
2 times, most recently
from
July 12, 2026 20:36
30b8188 to
d1e8b8c
Compare
thestinger
force-pushed
the
17
branch
2 times, most recently
from
July 23, 2026 19:14
346080f to
b8e91c8
Compare
thestinger
force-pushed
the
17
branch
2 times, most recently
from
August 8, 2026 06:54
92a9892 to
e83d225
Compare
thestinger
force-pushed
the
17
branch
2 times, most recently
from
August 27, 2026 16:33
1e86bdf to
05369a3
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
(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.