Closed Bug 1508072 Opened 5 years ago Closed 4 months ago

Fix our sandbox rules for mremap

Categories

(Core :: Security: Process Sandboxing, enhancement, P2)

Unspecified
Linux
enhancement

Tracking

()

RESOLVED FIXED
122 Branch
Tracking Status
firefox122 --- fixed

People

(Reporter: jld, Assigned: jld)

References

Details

Attachments

(1 file)

Currently we're allowing mremap unconditionally in content processes and only content processes.  But there are two reasons we need to care about it:

1. glibc's realloc() uses it, with MREMAP_MAYMOVE, for large allocations; see bug 1286119.  This should be relevant only when #ifndef MOZ_MEMORY, but it could apply to any process type.

2. Our wasm runtime uses it, with no flags (in-place resize only), on 32-bit platforms; this one does apply only to content processes.

3. Also SQLite will use it to resize file mappings, but it has a runtime fallback and I don't think we're using SQLite outside the parent process in any case.

I noticed this while refactoring the file- and memory-related sandbox rules for bug 1500297 / bug 1506291, but the fix will tighten the sandbox and could cause regressions, so I'd prefer to land it as a separate commit.
Priority: -- → P2
No longer blocks: 1506291
Depends on: 1511560
Summary: FIx our sandbox rules for mremap → Fix our sandbox rules for mremap
Severity: normal → S3
See Also: → 1860267

Note that mremap calls from libc realloc implementations are now
handled in SandboxPolicyCommon (for all process types), while
ContentSandboxPolicy now handles only the wasm-specific use case.

Pushed by jedavis@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9a95c6831ed2
Restrict the sandbox rule for mremap as used for wasm array buffers. r=gcp
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 122 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: