Skip to content
This repository has been archived by the owner on Aug 6, 2023. It is now read-only.

Some arithmetic overflow bugs found by afl.rs #446

Closed
StevenJiang1110 opened this issue Jan 9, 2021 · 2 comments
Closed

Some arithmetic overflow bugs found by afl.rs #446

StevenJiang1110 opened this issue Jan 9, 2021 · 2 comments
Labels

Comments

@StevenJiang1110
Copy link

I've using afl.rs to fuzz this crate. And I've found several API may panic due to arithmetic overflow.

There are four APIs we find may panic. We just download tui.rs from this respository and add it as a dependency to our fuzzing target. The codes to replay this panics are

let rect1 = tui::layout::Rect::new(12336 ,12336 ,12336 ,12336);
let rect2 = tui::layout::Rect::new(58928 ,12336 ,12336 ,0);
let _ = tui::layout::Rect::union(rect1 ,rect2);
let rect1 = tui::layout::Rect::new(12336 ,12336 ,12336 ,12336);
let rect2 = tui::layout::Rect::new(12336 ,65328 ,12336 ,12336);
let _ = tui::layout::Rect::intersection(rect1 ,rect2);
let rect1 = tui::layout::Rect::new(12336 ,12336 ,12336 ,12336);
let rect2 = tui::layout::Rect::new(57648 ,12336 ,65328 ,48);
let _ = tui::layout::Rect::intersects(rect1 ,rect2);
let rect1 = tui::layout::Rect::new(12336 ,12336 ,12336 ,12336);
let mut buf1 = tui::buffer::Buffer::empty(rect1);
let rect2 = tui::layout::Rect::new(12336 ,12336 ,12336 ,12336);
let buf2 = tui::buffer::Buffer::empty(rect2);
let _ = tui::buffer::Buffer::merge(&mut buf1 ,&buf2);

we also put these code on first, second, third, fourth.

The bug report is
截屏2021-01-09 下午10 10 58

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

@tpoliaw
Copy link

tpoliaw commented Aug 27, 2021

Just come across the second of these in 'normal', non-fuzzing usage trying to find the intersection of two rectangles that don't intersect. I'm happy to submit a PR for this but unsure of preferred approach.

Could either use saturating_sub and return an intersection with 0 height/width, or make the return type an Option<Rect>. The second option feels more correct as there is no intersection to return but it is a public API so would be a breaking change. It currently has no references within the library but there's no way of knowing how widely this is used.

@DarrienG
Copy link
Contributor

DarrienG commented Mar 5, 2022

I haven't worked on the project in a bit, but as a point of reference, when we hit a similar problem a long while ago we used saturating adds and subtracts #283

@fdehau fdehau closed this as completed Aug 6, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants