sentry: use cryptographic PRNG for security-sensitive randomization by KevinZhao · Pull Request #12695 · google/gvisor

KevinZhao · 2026-03-08T22:51:33Z

Replace math/rand with gvisor.dev/gvisor/pkg/rand (backed by crypto/rand
or getrandom(2)) in 5 security-sensitive code paths that currently use the
non-cryptographic math/rand:

File	Usage	Risk
`mm/syscalls.go`	Stack ASLR	Stack address prediction aids ROP
`systrap/stub_unsafe.go`	Stub code layout	Sentry code location prediction
`systrap/usertrap/usertrap_amd64.go`	Trap table layout	Syscall dispatch hijacking
`netlink/port/port.go`	Port allocation	Port collision/hijacking
`inet/abstract_socket_namespace.go`	Socket autobind	Socket name prediction

math/rand is not cryptographically secure — its output is deterministic given
the internal state, which can be recovered from observed outputs (e.g., by
observing one's own stack address via /proc/self/maps and deducing future
randomization outputs for other processes in the same sandbox).

gvisor.dev/gvisor/pkg/rand already provides matching API (Uint32, Uint64,
Int63n) backed by getrandom(2) / crypto/rand.Reader.

Related: CVE-2024-10026 and CVE-2024-10603 fixed the same class of weakness
(math/rand for network identifiers) in the TCP/IP stack. These 5 files were
not addressed by those fixes.

EtiennePerot

cc @nixprime

EtiennePerot · 2026-03-09T18:35:21Z

+	// cryptoFloat64 returns a cryptographically random float64 in [0, 1).
+	cryptoFloat64 := func() float64 {
+		var b [8]byte
+		crand.Read(b[:])
+		return float64(binary.NativeEndian.Uint64(b[:])>>11) / (1 << 53)
+	}


These are just randomly-generated syslog messages for fun. They do not need cryptographic randomness.

Please revert these changes here and in other places that do not need randomness to state as such, to ensure future agent-based PRs do not get tempted again to change this in the future.

EtiennePerot · 2026-03-09T21:03:36Z

 	}

-	c.cid = fmt.Sprintf("runsc-%06d", rand.Int31n(1000000))
+	c.cid = fmt.Sprintf("runsc-%06d", rand.Int63n(1000000))


runsc do is just for a debug command, so cryptographic randomness is not needed here. (Also, 1000000 fits in 31 bits, so this is consuming 2x the entropy that it actually needs to consume)

EtiennePerot · 2026-03-09T21:04:42Z

+	// Fisher-Yates shuffle using cryptographic PRNG.
+	perm := make([]int, len(loadedSandboxes))
+	for i := range perm {
+		perm[i] = i
+	}
+	for i := len(perm) - 1; i > 0; i-- {
+		j := int(crand.Int63n(int64(i + 1)))
+		perm[i], perm[j] = perm[j], perm[i]
+	}
+	for _, sandboxIndex := range perm {


This is just a best-effort way to avoid slow sandboxes across metric fetches. It does not need cryptographic randomness, especially if that comes at the complexity cost of an inline Fisher-Yates implementation.

EtiennePerot · 2026-03-09T21:06:17Z

 				panic("failed to map stub code")
 			}
-			r := regions[rand.Int()%n]
+			r := regions[int(rand.Uint64())%n]


Apply modulo before casting

KevinZhao · 2026-03-10T01:36:51Z

Thanks for the detailed review @EtiennePerot. Updated per your feedback:

Reverted syslog.go, do.go, metricserver.go, and lisafs/sample_message.go — none of these need cryptographic randomness
Fixed modulo-before-cast in stub_unsafe.go (rand.Uint64()%uint64(n) instead of int() cast first)
Kept only 5 genuinely security-sensitive files: mm/syscalls.go (ASLR), stub_unsafe.go (stub ASLR), usertrap_amd64.go (trap table), netlink/port.go (port allocation), abstract_socket_namespace.go (autobind — matches kernel get_random_u32() behavior)

Net diff is now 5 files, 7 insertions, 7 deletions.

KevinZhao · 2026-03-15T07:58:20Z

Hi @EtiennePerot — I've addressed all the review feedback (reverted non-security files, fixed modulo-before-cast). The diff is now just 5 files with security-sensitive math/rand usage. Could you take another look when you have a moment?

Replace `math/rand` with `gvisor.dev/gvisor/pkg/rand` (backed by `crypto/rand` or `getrandom(2)`) in 5 security-sensitive code paths that currently use the non-cryptographic `math/rand`: | File | Usage | Risk | |------|-------|------| | `mm/syscalls.go` | Stack ASLR | Stack address prediction aids ROP | | `systrap/stub_unsafe.go` | Stub code layout | Sentry code location prediction | | `systrap/usertrap/usertrap_amd64.go` | Trap table layout | Syscall dispatch hijacking | | `netlink/port/port.go` | Port allocation | Port collision/hijacking | | `inet/abstract_socket_namespace.go` | Socket autobind | Socket name prediction | `math/rand` is not cryptographically secure — its output is deterministic given the internal state, which can be recovered from observed outputs (e.g., by observing one's own stack address via `/proc/self/maps` and deducing future randomization outputs for other processes in the same sandbox). `gvisor.dev/gvisor/pkg/rand` already provides matching API (`Uint32`, `Uint64`, `Int63n`) backed by `getrandom(2)` / `crypto/rand.Reader`. **Related**: CVE-2024-10026 and CVE-2024-10603 fixed the same class of weakness (`math/rand` for network identifiers) in the TCP/IP stack. These 5 files were not addressed by those fixes. FUTURE_COPYBARA_INTEGRATE_REVIEW=#12695 from KevinZhao:fix/weak-prng-security-sensitive d6428ea PiperOrigin-RevId: 891955457

Replace math/rand with gvisor.dev/gvisor/pkg/rand (backed by crypto/rand or getrandom(2)) in security-sensitive code paths: - mm/syscalls.go: Stack ASLR randomization. math/rand makes stack addresses more predictable than Linux's ASLR, aiding exploitation. - systrap/stub_unsafe.go: Sentry stub code layout randomization. Predictable stub locations enable ROP/JOP attacks against the sentry. - systrap/usertrap/usertrap_amd64.go: Trap table address randomization. Predictable trap table aids syscall dispatch hijacking. - netlink/port/port.go: Netlink port allocation start offset. - inet/abstract_socket_namespace.go: Unix abstract socket autobind. math/rand is not cryptographically secure — its output is deterministic given the internal state, which can be recovered from observed outputs. gVisor's secure rand package uses getrandom(2)/crypto.rand.Reader. Related: CVE-2024-10026 and CVE-2024-10603 fixed the same class of weakness (math/rand for network identifiers) in the TCP/IP stack.

Move gvisor.dev/gvisor/pkg/rand from stdlib group to gvisor package group, and fix alphabetical ordering within the group.

Replace math/rand with gvisor.dev/gvisor/pkg/rand (backed by crypto/rand or getrandom(2)) in four additional locations: - runsc/cmd/do.go: Container ID generation. Predictable IDs from math/rand could allow other processes to guess and race container names. - runsc/metricserver/metricserver.go: Sandbox iteration order shuffle. Replace rand.Perm with Fisher-Yates using cryptographic PRNG. - pkg/sentry/kernel/syslog.go: Dmesg message selection and timing. Eliminates math/rand from the sentry address space entirely. - pkg/lisafs/sample_message.go: Test message randomization. Ensures no math/rand import remains in the lisafs package. This is a follow-up to the previous commit that replaced math/rand in security-sensitive paths (ASLR, stub layout, trap table, netlink port, socket autobind). Together they eliminate math/rand from all production code paths in gVisor.

…t order Revert crypto PRNG changes in syslog.go (fun messages), do.go (debug command), and metricserver.go (best-effort shuffle) as these do not need cryptographic randomness. Fix stub_unsafe.go: apply modulo before int cast to avoid potential negative index from uint64-to-int conversion.

…t order - Revert syslog.go, do.go, metricserver.go (not security-sensitive) - Revert lisafs/sample_message.go (test utility, not security-sensitive) - Fix modulo-before-cast in stub_unsafe.go per reviewer feedback - Keep only 5 files with genuine security-sensitive randomization: mm/syscalls.go (ASLR), systrap/stub_unsafe.go (stub ASLR), usertrap_amd64.go (trap table), netlink/port.go (port alloc), abstract_socket_namespace.go (autobind)

ayushr2 · 2026-03-31T17:06:06Z

Please squash your commits. Also this PR does not build because the BUILD files have not been updated with the new import.

Replace `math/rand` with `gvisor.dev/gvisor/pkg/rand` (backed by `crypto/rand` or `getrandom(2)`) in 5 security-sensitive code paths that currently use the non-cryptographic `math/rand`: | File | Usage | Risk | |------|-------|------| | `mm/syscalls.go` | Stack ASLR | Stack address prediction aids ROP | | `systrap/stub_unsafe.go` | Stub code layout | Sentry code location prediction | | `systrap/usertrap/usertrap_amd64.go` | Trap table layout | Syscall dispatch hijacking | | `netlink/port/port.go` | Port allocation | Port collision/hijacking | | `inet/abstract_socket_namespace.go` | Socket autobind | Socket name prediction | `math/rand` is not cryptographically secure — its output is deterministic given the internal state, which can be recovered from observed outputs (e.g., by observing one's own stack address via `/proc/self/maps` and deducing future randomization outputs for other processes in the same sandbox). `gvisor.dev/gvisor/pkg/rand` already provides matching API (`Uint32`, `Uint64`, `Int63n`) backed by `getrandom(2)` / `crypto/rand.Reader`. **Related**: CVE-2024-10026 and CVE-2024-10603 fixed the same class of weakness (`math/rand` for network identifiers) in the TCP/IP stack. These 5 files were not addressed by those fixes. FUTURE_COPYBARA_INTEGRATE_REVIEW=#12695 from KevinZhao:fix/weak-prng-security-sensitive d6428ea PiperOrigin-RevId: 891955457

Replace `math/rand` with `gvisor.dev/gvisor/pkg/rand` (backed by `crypto/rand` or `getrandom(2)`) in 5 security-sensitive code paths that currently use the non-cryptographic `math/rand`: | File | Usage | Risk | |------|-------|------| | `mm/syscalls.go` | Stack ASLR | Stack address prediction aids ROP | | `systrap/stub_unsafe.go` | Stub code layout | Sentry code location prediction | | `systrap/usertrap/usertrap_amd64.go` | Trap table layout | Syscall dispatch hijacking | | `netlink/port/port.go` | Port allocation | Port collision/hijacking | | `inet/abstract_socket_namespace.go` | Socket autobind | Socket name prediction | `math/rand` is not cryptographically secure — its output is deterministic given the internal state, which can be recovered from observed outputs (e.g., by observing one's own stack address via `/proc/self/maps` and deducing future randomization outputs for other processes in the same sandbox). `gvisor.dev/gvisor/pkg/rand` already provides matching API (`Uint32`, `Uint64`, `Int63n`) backed by `getrandom(2)` / `crypto/rand.Reader`. **Related**: CVE-2024-10026 and CVE-2024-10603 fixed the same class of weakness (`math/rand` for network identifiers) in the TCP/IP stack. These 5 files were not addressed by those fixes. COPYBARA_INTEGRATE_REVIEW=#12695 from KevinZhao:fix/weak-prng-security-sensitive d6428ea PiperOrigin-RevId: 892755849

ayushr2 · 2026-04-01T15:09:10Z

I fixed this up and merged it in 3058187. Closing this.

Replace `math/rand` with `gvisor.dev/gvisor/pkg/rand` (backed by `crypto/rand` or `getrandom(2)`) in 5 security-sensitive code paths that currently use the non-cryptographic `math/rand`: | File | Usage | Risk | |------|-------|------| | `mm/syscalls.go` | Stack ASLR | Stack address prediction aids ROP | | `systrap/stub_unsafe.go` | Stub code layout | Sentry code location prediction | | `systrap/usertrap/usertrap_amd64.go` | Trap table layout | Syscall dispatch hijacking | | `netlink/port/port.go` | Port allocation | Port collision/hijacking | | `inet/abstract_socket_namespace.go` | Socket autobind | Socket name prediction | `math/rand` is not cryptographically secure — its output is deterministic given the internal state, which can be recovered from observed outputs (e.g., by observing one's own stack address via `/proc/self/maps` and deducing future randomization outputs for other processes in the same sandbox). `gvisor.dev/gvisor/pkg/rand` already provides matching API (`Uint32`, `Uint64`, `Int63n`) backed by `getrandom(2)` / `crypto/rand.Reader`. **Related**: CVE-2024-10026 and CVE-2024-10603 fixed the same class of weakness (`math/rand` for network identifiers) in the TCP/IP stack. These 5 files were not addressed by those fixes. COPYBARA_INTEGRATE_REVIEW=google#12695 from KevinZhao:fix/weak-prng-security-sensitive d6428ea PiperOrigin-RevId: 892755849

EtiennePerot requested changes Mar 9, 2026

View reviewed changes

EtiennePerot approved these changes Mar 18, 2026

View reviewed changes

EtiennePerot added the ready to pull label Mar 18, 2026

ayushr2 added ready to pull and removed ready to pull labels Mar 30, 2026

copybara-service Bot mentioned this pull request Mar 30, 2026

sentry: use cryptographic PRNG for security-sensitive randomization #12826

Merged

KevinZhao added 4 commits March 31, 2026 14:37

fixup: correct import ordering for gvisor.dev/gvisor/pkg/rand

4802af3

Move gvisor.dev/gvisor/pkg/rand from stdlib group to gvisor package group, and fix alphabetical ordering within the group.

KevinZhao force-pushed the fix/weak-prng-security-sensitive branch from d6428ea to 1e29f18 Compare March 31, 2026 14:38

KevinZhao force-pushed the fix/weak-prng-security-sensitive branch from 1e29f18 to 22c2e00 Compare March 31, 2026 14:54

ayushr2 closed this Apr 1, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

sentry: use cryptographic PRNG for security-sensitive randomization#12695

sentry: use cryptographic PRNG for security-sensitive randomization#12695
KevinZhao wants to merge 5 commits intogoogle:masterfrom
KevinZhao:fix/weak-prng-security-sensitive

KevinZhao commented Mar 8, 2026

Uh oh!

EtiennePerot left a comment

Uh oh!

EtiennePerot Mar 9, 2026 •

edited

Loading

Uh oh!

EtiennePerot Mar 9, 2026

Uh oh!

EtiennePerot Mar 9, 2026

Uh oh!

EtiennePerot Mar 9, 2026

Uh oh!

KevinZhao commented Mar 10, 2026

Uh oh!

KevinZhao commented Mar 15, 2026

Uh oh!

ayushr2 commented Mar 31, 2026

Uh oh!

ayushr2 commented Apr 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

KevinZhao commented Mar 8, 2026

Uh oh!

EtiennePerot left a comment

Choose a reason for hiding this comment

Uh oh!

EtiennePerot Mar 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

EtiennePerot Mar 9, 2026

Choose a reason for hiding this comment

Uh oh!

EtiennePerot Mar 9, 2026

Choose a reason for hiding this comment

Uh oh!

EtiennePerot Mar 9, 2026

Choose a reason for hiding this comment

Uh oh!

KevinZhao commented Mar 10, 2026

Uh oh!

KevinZhao commented Mar 15, 2026

Uh oh!

ayushr2 commented Mar 31, 2026

Uh oh!

ayushr2 commented Apr 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

EtiennePerot Mar 9, 2026 •

edited

Loading