Hi all,
recently, I've found a bug in regex that can lead to access violation.
std::string s(".*?");
boost::regex regEx(s.begin(), s.end()); // Potential AV here
basic_regex constructor creates a local variable of type traits::string_type and passes its the first element address and one-beyond-the-last element address to the assing() function.
template <class InputIterator>
basic_regex(InputIterator arg_first, InputIterator arg_last, flag_type f = regex_constants::normal)
{
typedef typename traits::string_type seq_type;
seq_type a(arg_first, arg_last);
if(a.size())
assign(&*a.begin(), &*a.begin() + a.size(), f);
else
assign(static_cast(0), static_cast(0), f);
}
Calling assign() eventually leads to creation of basic_regex_parser object and calling its parse_repeat() function. m_begin and m_end members are initialized with values passed to assign().
template
bool basic_regex_parser::parse_repeat(std::size_t low, std::size_t high)
{
...
// OK we have a perl or emacs regex, check for a '?':
if(this->m_traits.syntax_type(*m_position) == regex_constants::syntax_question)
{
greedy = false;
++m_position;
}
// for perl regexes only check for pocessive ++ repeats.
if((0 == (this->flags() & regbase::main_option_type))
&& (this->m_traits.syntax_type(*m_position) == regex_constants::syntax_plus))
{
pocessive = true;
++m_position;
}
...
}
In parse_repeat() the m_position, member points to '?' so condition in the first if is true and m_position is advanced by ++m_position. Now it is equal to m_end.
In the next if statement, *m_position is evaluated that may cause access violation.
Actually, it is unlikely that the sample code above will cause AV. It is because seq_type in basic_regex constructor is basic_string, and basic_string's underlying buffer is usually null-terminated. So m_end points to the null terminator. It always readable, no AV can happen.
The actual code I used is slightly different but the concept is the same:
boost::u32regex regEx = boost::make_u32regex(L".*?");
u32regex and make_u32regex are provided by the ICU library. That is a way to support unicode strings.
seq_type become std::vector. Some time the "a" object's underlying buffer was allocated right in the end of page, so basic_regex_parser::m_end pointed to the start of the next page that was not allocated. Dereferencing m_position caused access violation.
My environment is Visual VC++ 9.0, Boost 1.42.0 (as far I can see, the code in Boost 1.46.1 is the same).
By the way. When traits::string_type is basic_string, the code in basic_regex::basic_regex is not portable:
assign(&*a.begin(), &*a.begin() + a.size(), f);
If I remember correctly, standard does not guarantee that basic_string's controlling sequence is contiguous.
Just in case, the call stack when AV occured:
boost::re_detail::basic_regex_parser::parse_repeat+0x87
boost::re_detail::basic_regex_parser::parse_extended+0x182
boost::re_detail::basic_regex_parser::parse+0x133
boost::re_detail::basic_regex_implementation::assign+0x98
boost::basic_regex::do_assign+0x14c
boost::basic_regex::assign+0x16
boost::basic_regex::assign+0xa2
boost::basic_regex::basic_regex >+0xb8
boost::re_detail::do_make_u32regex+0x25
boost::make_u32regex+0x2c
Sergey
