Some panic cases found by afl.rs, involving 9 public API

[StevenJiang1110]

I have used afl.rs to fuzz all public API of thie crate. And I found several cases may cause panic. The version I fuzz on is 1.4.2, but I have checked that all the cases can be replayed on the newest version 1.4.3. These panics involve 9 APIs(some are similar). The code to replay these panics are as follows:

These 6 cases are about slicing error or out-of-bound error.

let regex_ = regex::bytes::Regex::new("0").unwrap();
let _ = regex::bytes::Regex::find_at(&regex_ ,&[48] ,3472328296227680304);

let regex_ = regex::Regex::new("0").unwrap();
let _local1 = regex::Regex::find_at(&regex_ ,"0" ,3472328296227680304);

let regex_ = regex::bytes::Regex::new("0").unwrap();
let _ = regex::bytes::Regex::shortest_match_at(&regex_ ,&[48] ,3472328296227680304);

let regex_ = regex::bytes::Regex::new("0").unwrap();
let _ = regex::bytes::Regex::is_match_at(&regex_ ,&[48] ,3472328296227680304);

let regex_ = regex::Regex::new("0").unwrap();
let _ = regex::Regex::shortest_match_at(&regex_ ,"0" ,3472328296227680304);

let regex_ = regex::Regex::new("0").unwrap();
let _ = regex::Regex::is_match_at(&regex_ ,"0" ,3472328296227680304);

These 2 cases are about arithmetic overflow.

let regex_ = regex::bytes::Regex::new("0").unwrap();
let capture_location = regex::bytes::Regex::capture_locations(&regex_);
let _ = regex::bytes::CaptureLocations::get(&capture_location ,18388250262078763056);

let regex_ = regex::Regex::new("0").unwrap();
let capture_location = regex::Regex::capture_locations(&regex_);
let _ = regex::CaptureLocations::get(&capture_location ,9236935819261915184);

This case is about unicode error(char boundary)

let regex_ = regex::Regex::new("(?-u)000|\\S000").unwrap();
let match_ = regex::Regex::find(&regex_ ,"詩00000000000").unwrap();
let _ = regex::Match::as_str(&match_);

I also put these replay codes and more data that may cause panic on replay_files.

I hope you can check if these are real bugs need to be fixed. Thanks a lot.

[BurntSushi]

None of the first 6 are bugs. You're providing an offset that is invalid for the slice given. Arguably this should be documented as a panic condition.

The second two cases do point to a bug. It should result in None being returned instead of a panic.

The last one is also a bug. Here is a smaller reproduction:

    let regex_ = regex::Regex::new(r"(?-u)\S").unwrap();
    let match_ = regex::Regex::find(&regex_ ,"詩").unwrap();
    let _ = regex::Match::as_str(&match_);

The problem is that the regex given should not be allowed to compile since \S could match invalid UTF-8, and a regex::Regex is never allowed to match invalid UTF-8. So there is something wrong with the logic in regex-syntax that allows such a regex to be constructed in the first place.

Nice finds!

[StevenJiang1110]

By fuzzing again, there's another unicode error found by afl.rs. The reason may be similar.

let regex_ = regex::Regex::new("(?-u)0|\\W").unwrap();
let capture_ = regex::Regex::captures(&regex_ ,"〧000000").unwrap();
let mut escape_ = regex::escape("000000000");
let _ = regex::Captures::expand(&capture_ ,"0$0000000" ,&mut escape_);