BaldDemian opened a new issue, #3480:
URL: https://github.com/apache/fory/issues/3480

   ### Search before asking
   
   - [x] I had searched in the [issues](https://github.com/apache/fory/issues) 
and found no similar issues.
   
   
   ### Version
   
   Fory: latest
   OS: Ubuntu 24.04.3
   GCC: 11.5.0
   
   ### Component(s)
   
   Rust
   
   ### Minimal reproduce step
   
   Clone https://github.com/BaldDemian/fory and change to the `cargo-fuzz` 
branch.
   Change to `rust` dir and run
   ```shell
   cargo +nightly fuzz run meta_string -- \                                     
                                
       -max_total_time=30 -max_len=4096 \
       -fork=1 -ignore_crashes=1 -ignore_ooms=1 -ignore_timeouts=1
   ```
   and 
   ```shell
   cargo +nightly fuzz run field_info -- \                                      
                               
       -max_total_time=30 -max_len=4096 \
       -fork=1 -ignore_crashes=1 -ignore_ooms=1 -ignore_timeouts=1
   ```
   
   All following panics should be observed within 30 seconds fuzzing.
   
   ### What did you expect to see?
   
   To my understanding, all input to a deserialization tool should be 
considered untrusted in case of 
[DoS](https://blog.trailofbits.com/2025/02/21/dont-recurse-on-untrusted-input/).
 Therefore, related code should return Err when encountering invalid or even 
**malicious** inputs, rather than directly panicking. However, by running cargo 
fuzz, I indeed found that some code paths panic under certain inputs.
   
   ### What did you see instead?
   
   1. 
https://github.com/apache/fory/blob/8df6bc3db7c5b2e9584b8a4be743727c7025bd6d/rust/fory-core/src/meta/type_meta.rs#L279-L281
     Line 280 will panic if i16 add overflows.
   
   2. 
https://github.com/apache/fory/blob/8df6bc3db7c5b2e9584b8a4be743727c7025bd6d/rust/fory-core/src/meta/type_meta.rs#L305-L307
     `decode` may return `Error` but line 307 doesn't propagate the error. It 
will panic if `unwrap` on `Error`.
   
   3. 
https://github.com/apache/fory/blob/8df6bc3db7c5b2e9584b8a4be743727c7025bd6d/rust/fory-core/src/resolver/meta_string_resolver.rs#L41-L50
      This method will panic when matching the default case. Maybe we should 
change the return value type of this method from `Encoding` to 
`Result<Encoding, Error>`?
   
   4. 
https://github.com/apache/fory/blob/8df6bc3db7c5b2e9584b8a4be743727c7025bd6d/rust/fory-core/src/resolver/meta_string_resolver.rs#L246
      If `len` is zero then this method will panic.
   
   5. 
https://github.com/apache/fory/blob/8df6bc3db7c5b2e9584b8a4be743727c7025bd6d/rust/fory-core/src/resolver/meta_string_resolver.rs#L366-L368
      Similar to 2, the `Error` is not properly handled in line 368
   
   ### Anything Else?
   
   Currently, testing of the Rust module in Fory mainly relies on manually 
constructed test cases. However, in serialization/deserialization-related 
projects, fuzzing is commonly used to test code robustness. I also noticed this:
   
https://github.com/apache/fory/blob/8df6bc3db7c5b2e9584b8a4be743727c7025bd6d/rust/Cargo.toml#L26-L28
   Perhaps Fory previously had plans to integrate cargo-fuzz?
   
   At the moment, I have only made a simple attempt to integrate cargo-fuzz and 
tested two modules. If fuzzing integration is indeed desired, we may also need 
to consider more advanced fuzzing features, such as more structured fuzzing 
supported by [arbitrary](https://github.com/rust-fuzz/cargo-fuzz), or 
integrating [OSS-fuzz](https://github.com/google/oss-fuzz).
   
   In addition, other modules such as the C++ implementation could also 
consider integrating fuzzing.
   
   ### Are you willing to submit a PR?
   
   - [x] I'm willing to submit a PR!


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to