Bug Report: Invalid Input Handling in `Scanner::slice` Method

[lwz23]

Bug Report: Invalid Input Handling in Scanner::slice Method

Description

When using the Scanner::slice method, passing an out-of-bounds argument causes the program to panic. This behavior indicates a potential design flaw, as it fails to handle invalid input properly, impacting the stability of the application.

PoC

consider the following code:

extern crate n2;

use n2::scanner::Scanner;

fn main() {
    // Prepare a valid UTF-8 byte array, null-terminated
    let valid_utf8_bytes: &[u8] = b"Hello, world!\0";

    // Create Scanner instance
    let scanner = Scanner::new(valid_utf8_bytes);

    // Attempt to slice with an unsafe range (beyond the size of buf)
    let start = 0;
    let end = 100; // Explicitly set out of bounds size

    // Call the slice method
    let result = scanner.slice(start, end);
    println!("Slice result: {}", result);
}

In my platform, it shows the following result.

 Compiling ne-test v0.1.0 (/home/lwz/github/ne-test)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.28s
     Running `target/debug/ne-test`
thread 'main' panicked at core/src/panicking.rs:221:5:
unsafe precondition(s) violated: slice::get_unchecked requires that the range is within the slice
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread caused non-unwinding panic. aborting.
已中止 (核心已转储)
lwz@lwz-ThinkStation-P3-Tower:~/github/ne-test$ 

Expected Outcome It is expected that the method handles input errors gracefully instead of panicking. For instance, the function could return a Result type or some other form of error handling.

I notice this PoC causes program aborting without 'unsafe' block, so I think maybe it is a Bug. This panic behavior could lead to program crashes in real applications, Sorry for if I am wrong.

[evmar]

Thanks for filing this bug, but I am confused why you are looking. Has this impacted you in some way? This is some unreleased hobby code of mine.

[lwz23]

Our group is scanning for bugs arising from unsafe API usage in real-world programs. I have noticed that these three functions may have soundness issues. Given that this is an unsound problem, I intend to report it to RustSec for future Rust safety research.

---- Replied Message ---- From Evan @.> Date 11/12/2024 04:34 To @.> Cc @.>@.> Subject Re: [evmar/n2] Bug Report: Invalid Input Handling in Scanner::slice Method (Issue #121)

Thanks for filing this bug, but I am confused why you are looking. Has this impacted you in some way? This is some unreleased hobby code of mine. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[evmar]

It seems like you could probably just grep for 'unsafe' and find a lot of this, hah! In case it helps any I view Rust as a language with nice safety defaults, which means I get safety when I'm writing code without thinking about it. But in my hobby code I am not bothered by writing code that is clearly unsafe, as that's only as bad as the C I might have otherwise used. I think in a professional context I would think about it differently.