Fix integer overflow in gz_compress_mmap#2110
Conversation
WalkthroughReworked mmap-based compression paths in Changes
Possibly related issues
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #2110 +/- ##
===========================================
- Coverage 84.31% 83.29% -1.03%
===========================================
Files 158 158
Lines 13085 13089 +4
Branches 3222 3225 +3
===========================================
- Hits 11033 10902 -131
- Misses 989 1129 +140
+ Partials 1063 1058 -5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Like I mentioned in the issue, gzip file format doesn't support files that are 2 GB or larger due to file systems using signed 32-bit integers for file size in
It's debatable if we should gracefully fail both when using mmap and when not using. CodeCov failure is due to not being in sync with current development tree, currently 19 commits behind. |
nmoinvaz
left a comment
There was a problem hiding this comment.
I think what we should be using is:
// Instead of:
len = PREFIX(gzwrite)(out, (char *)buf, (unsigned)buf_len);
// Use:
len = PREFIX(gzfwrite)((char *)buf, 1, buf_len, out);
f prefix doesn't imply FILE* rather it was part of a set of changes that utilized size_t.
Signed-off-by: Vladislav Shchapov <vladislav@shchapov.ru>
|
You're right. Code without MMAP is also susceptible to the gzip format issue. I changed the |
Fix for issue #2109
Added a 2GB (
INT_MAX) mmap I/O limit.