Soundness Bug in this crate

[lewismosciski]

Hi there!

We scanned the most popular libraries on crates.io and found some memory safety bugs in this library.

FastFloat::parse_float_partial

PoC

use fast_float::FastFloat;

fn main() {
    // Any non-empty input reaches parse::parse_float; on big-endian targets with f32
    // (size == 4) it takes the UB branch that does *(&word as *const _ as *const f32).add(1).
    let inputs: [&[u8]; 3] = [b"1", b"0.5", b"3.14159e0"];

    for s in inputs {
        // Directly invoke the entry_call via the public trait method.
        let _ = <f32 as FastFloat>::parse_float_partial(s);
    }
}

Miri Output

error: Undefined Behavior: in-bounds pointer arithmetic failed: attempting to offset pointer by 8 bytes, but got alloc2+0x2 which is only 1 byte from the end of the allocation
  --> /home/ccuu/Desktop/llm-detector/experiments/cache/crates_src/fast-float/0.2.0/fast-float-0.2.0/src/common.rs:78:18
   |
78 |         unsafe { self.ptr.add(n) <= self.end }
   |                  ^^^^^^^^^^^^^^^ Undefined Behavior occurred here
   |
   = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
   = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
   = note: BACKTRACE:
   = note: inside `fast_float::common::AsciiStr::<'_>::check_len` at /home/ccuu/Desktop/llm-detector/experiments/cache/crates_src/fast-float/0.2.0/fast-float-0.2.0/src/common.rs:78:18: 78:33
   = note: inside `fast_float::common::AsciiStr::<'_>::try_read_u64` at /home/ccuu/Desktop/llm-detector/experiments/cache/crates_src/fast-float/0.2.0/fast-float-0.2.0/src/common.rs:83:12: 83:29
   = note: inside `fast_float::number::try_parse_8digits_le` at /home/ccuu/Desktop/llm-detector/experiments/cache/crates_src/fast-float/0.2.0/fast-float-0.2.0/src/number.rs:74:26: 74:42
   = note: inside `fast_float::number::parse_number` at /home/ccuu/Desktop/llm-detector/experiments/cache/crates_src/fast-float/0.2.0/fast-float-0.2.0/src/number.rs:153:9: 153:52
   = note: inside `fast_float::parse::parse_float::<f32>` at /home/ccuu/Desktop/llm-detector/experiments/cache/crates_src/fast-float/0.2.0/fast-float-0.2.0/src/parse.rs:14:29: 14:44
   = note: inside `<f32 as fast_float::FastFloat>::parse_float_partial::<&[u8]>` at /home/ccuu/Desktop/llm-detector/experiments/cache/crates_src/fast-float/0.2.0/fast-float-0.2.0/src/lib.rs:106:9: 106:39
note: inside `main`
  --> src/main.rs:14:17
   |
14 |         let _ = <f32 as FastFloat>::parse_float_partial(s);
   |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to 1 previous error

We appreciate your work on this crate and hope this report helps improve its safety.

[Alexhuszagh]

Hi there!

We scanned the most popular libraries on crates.io and found some memory safety bugs in this library.

FastFloat::parse_float_partial

PoC

use fast_float::FastFloat;

fn main() {
// Any non-empty input reaches parse::parse_float; on big-endian targets with f32
// (size == 4) it takes the UB branch that does *(&word as *const _ as *const f32).add(1).
let inputs: [&[u8]; 3] = [b"1", b"0.5", b"3.14159e0"];

for s in inputs {
    // Directly invoke the entry_call via the public trait method.
    let _ = <f32 as FastFloat>::parse_float_partial(s);
}

}

Miri Output

error: Undefined Behavior: in-bounds pointer arithmetic failed: attempting to offset pointer by 8 bytes, but got alloc2+0x2 which is only 1 byte from the end of the allocation
  --> /home/ccuu/Desktop/llm-detector/experiments/cache/crates_src/fast-float/0.2.0/fast-float-0.2.0/src/common.rs:78:18
   |
78 |         unsafe { self.ptr.add(n) <= self.end }
   |                  ^^^^^^^^^^^^^^^ Undefined Behavior occurred here
   |
   = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
   = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
   = note: BACKTRACE:
   = note: inside `fast_float::common::AsciiStr::<'_>::check_len` at /home/ccuu/Desktop/llm-detector/experiments/cache/crates_src/fast-float/0.2.0/fast-float-0.2.0/src/common.rs:78:18: 78:33
   = note: inside `fast_float::common::AsciiStr::<'_>::try_read_u64` at /home/ccuu/Desktop/llm-detector/experiments/cache/crates_src/fast-float/0.2.0/fast-float-0.2.0/src/common.rs:83:12: 83:29
   = note: inside `fast_float::number::try_parse_8digits_le` at /home/ccuu/Desktop/llm-detector/experiments/cache/crates_src/fast-float/0.2.0/fast-float-0.2.0/src/number.rs:74:26: 74:42
   = note: inside `fast_float::number::parse_number` at /home/ccuu/Desktop/llm-detector/experiments/cache/crates_src/fast-float/0.2.0/fast-float-0.2.0/src/number.rs:153:9: 153:52
   = note: inside `fast_float::parse::parse_float::<f32>` at /home/ccuu/Desktop/llm-detector/experiments/cache/crates_src/fast-float/0.2.0/fast-float-0.2.0/src/parse.rs:14:29: 14:44
   = note: inside `<f32 as fast_float::FastFloat>::parse_float_partial::<&[u8]>` at /home/ccuu/Desktop/llm-detector/experiments/cache/crates_src/fast-float/0.2.0/fast-float-0.2.0/src/lib.rs:106:9: 106:39
note: inside `main`
  --> src/main.rs:14:17
   |
14 |         let _ = <f32 as FastFloat>::parse_float_partial(s);
   |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to 1 previous error

We appreciate your work on this crate and hope this report helps improve its safety.

This crate is no longer maintained and I maintain a fork which has this fix, and this was already a reported security vulnerability. See #28, #29, and #37. I maintain a fork fast-float2 that implements these fixes as well as many other soundness changes. I highly recommend anyone who has not updated to do so.

See the security advisory.

UPDATE: It seems you're using LLMs to do security vulnerability scanning. This is a huge tax on the open source ecosystem because it offloads work to maintainers with no effort on your part and I'd highly recommend you stop doing so.