-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CBG-3238 perform a length check on raw bytes #6438
Conversation
- refactor attachment compaction tests so we can make sure that it doesn't terminate
db/document.go
Outdated
@@ -515,6 +515,9 @@ func parseXattrStreamData(xattrName string, userXattrName string, data []byte) ( | |||
} | |||
|
|||
xattrsLen := binary.BigEndian.Uint32(data[0:4]) | |||
if int(xattrsLen) > len(data) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like it should check if int(xattrsLen+4) > len(data) to avoid all possible panics on line 518.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
@@ -515,6 +515,9 @@ func parseXattrStreamData(xattrName string, userXattrName string, data []byte) ( | |||
} | |||
|
|||
xattrsLen := binary.BigEndian.Uint32(data[0:4]) | |||
if int(xattrsLen) > len(data) { | |||
return nil, nil, nil, fmt.Errorf("%w (%d) from bytes %s", base.ErrXattrInvalidLen, xattrsLen, data) | |||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we able to write a test for what happens if data[0:4] doesn't represent xattrsLen (i.e. document doesn't have xattrs, it's just the body), but the Uint32 value of data[0:4] is less than len(data)? I'm assuming we'll return an error while trying to parse the xattr key/value pairs below, but would be good to verify there aren't any subsequent panics in that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a test for this.
db/attachment_compaction.go
Outdated
base.WarnfCtx(ctx, format, args...) | ||
return false | ||
// processAttachmentCompactSweepCallback(ctx context.Context, dataStore base.DataStore, db *Database, compactionID, compactionLoggingID string, dryRun bool, purgedAttachmentCount *base.AtomicInt, event sgbucket.FeedEvent) { | ||
func processAttachmentCompactMarkCallback(ctx context.Context, dataStore base.DataStore, compactionID, compactionLoggingID string, markedAttachmentCount *base.AtomicInt, event sgbucket.FeedEvent) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you provide some more context on the need for these attachment compaction changes? I don't see how they are strictly related to the length check enhancement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed offline, I removed these changes because they were bigger than was appropriate. I left a single change to treat a document with an invalid xattr as a document with xattrs.
- remove attachment compaction changes and leave only a change to avoid failure to mark changes if xattr length is invalid. Treat this as a document without xattrs in order to not fail attachment compaction test. - add code to prevent overflow if xattr len is a number between 1-4 which would cause a panic.
* CBG-3238 perform a length check on raw bytes - refactor attachment compaction tests so we can make sure that it doesn't terminate * Add comment * remove redundant returns * Move error handling into getAttachmentSyncData * PR fixup - remove attachment compaction changes and leave only a change to avoid failure to mark changes if xattr length is invalid. Treat this as a document without xattrs in order to not fail attachment compaction test. - add code to prevent overflow if xattr len is a number between 1-4 which would cause a panic. * Update tests * remove test tested in separate function
* CBG-3238 perform a length check on raw bytes - refactor attachment compaction tests so we can make sure that it doesn't terminate * Add comment * remove redundant returns * Move error handling into getAttachmentSyncData * PR fixup - remove attachment compaction changes and leave only a change to avoid failure to mark changes if xattr length is invalid. Treat this as a document without xattrs in order to not fail attachment compaction test. - add code to prevent overflow if xattr len is a number between 1-4 which would cause a panic. * Update tests * remove test tested in separate function
* CBG-3238 perform a length check on raw bytes - refactor attachment compaction tests so we can make sure that it doesn't terminate * Add comment * remove redundant returns * Move error handling into getAttachmentSyncData * PR fixup - remove attachment compaction changes and leave only a change to avoid failure to mark changes if xattr length is invalid. Treat this as a document without xattrs in order to not fail attachment compaction test. - add code to prevent overflow if xattr len is a number between 1-4 which would cause a panic. * Update tests * remove test tested in separate function
Pre-review checklist
fmt.Print
,log.Print
, ...)base.UD(docID)
,base.MD(dbName)
)docs/api
Integration Tests
GSI=true,xattrs=true
https://jenkins.sgwdev.com/job/SyncGateway-Integration/2025/