Permalink
Show file tree
Hide file tree
8 comments
on commit
sign in to comment.
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
patch 8.0.0322: possible overflow with corrupted spell file
Problem: Possible overflow with spell file where the tree length is
corrupted.
Solution: Check for an invalid length (suggested by shqking)- Loading branch information
Showing
2 changed files
with
5 additions
and
0 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
399c297There 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.
The initial patch submitted by shqking (https://groups.google.com/forum/#!topic/vim_dev/t-3RSdEnrHY) used an upper bound of 0x3fffffff (note there are 7 'f's) while the upper bound that was commited is 0x3ffffff (6 'f's). Is this correct? Also, is there a #DEFINE or global that can be used instead of this seemingly arbitrary hardcoded number?
399c297There 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.
Hi asdofijanw,
Thanks for your comment.
I guess it is brammool's written error.
The upper bound should be 0x3fffffff( i.e. 7 'f's).
399c297There 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.
Yeah, it'd be better to do something based on the actual bounds of the data types, like
if (len >= (ULONG_MAX / sizeof(int)).399c297There 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.
Yes. I agree with you.
399c297There 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.
len > ULONG_MAX / sizeof(int)?399c297There 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.
#define UINT_MAX 0xffffffff // 2^32 - 1, the max value that UNSIGNED INT can represent.
len > UINT_MAX / sizeof(int)
399c297There 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.
Agree with @shqking. The type of
lenisint, soUINT_MAXshould be used.@brammool Why not include this?
399c297There 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.