Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validate dimensionality #43

Merged
merged 3 commits into from
Feb 17, 2019
Merged

Validate dimensionality #43

merged 3 commits into from
Feb 17, 2019

Conversation

Enet4
Copy link
Owner

@Enet4 Enet4 commented Feb 12, 2019

I found a problem while fuzzing the crate. If dim[0] contains an inappropriate value, attempting to read a volume would panic. This PR makes some changes to accommodate the fix.

  • new error variant for inconsistent dim field values (must be positive, and dim[0] must not be higher than 7).
  • raise this error if dim[0] is incorrect.
  • as a bonus, I added public methods to NiftiHeader, which validate the values in the process.

- crash-1.nii generated through fuzz testing
- add error variant InconsistentHeader
- add public methods to NiftiHeader `dim` and `dimensionality`
- raise an error if dimensionality is inconsistent
Copy link
Collaborator

@nilgoyette nilgoyette left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A git grep "+ 1" tells me that we have this same pattern in impl NiftiVolume for InMemNiftiVolume, in dim and dimensionality. I understand that it didn't crash the application when you tested, but, I wonder, should the same pattern have the same error management?

src/header.rs Outdated
///
/// `NiftiError::` if `dim[0]` does not represent a valid dimensionality.
pub fn dimensionality(&self) -> Result <usize> {
if self.dim[0] > 7 {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is 0 a valid dimensionality?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great question, I don't know. Might be worth looking into this.

@@ -47,6 +47,7 @@
//!
#![deny(missing_debug_implementations)]
#![warn(missing_docs, unused_extern_crates, trivial_casts, unused_results)]
#![recursion_limit = "128"]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please tell me why we need a recursion limit? I don't remember any use of recursion in this lib.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the compiler's recursive operation limit. Recursion is used internally by the quick_error! macro. Once a significant number of variants are declared, which is the case here, we need to push this value a bit higher.

@Enet4
Copy link
Owner Author

Enet4 commented Feb 14, 2019

Thanks for reviewing, @nilgoyette. I can double-check those patterns and replace occurrences where reasonable the next few days. But from what I noticed, the circumstances in the volume structs are different, since dim is already validated on construction.

More comments inline.

- replace InconsistentHeader with InconsistentDim in NiftiHeader
- dim[0] == 0 is invalid
- check all dimensions in NiftiHeader::dim() for no zeroes
@nilgoyette
Copy link
Collaborator

LGTM.

@Enet4 Enet4 merged commit 6d7c909 into master Feb 17, 2019
@Enet4 Enet4 deleted the fix/dim_0 branch February 17, 2019 12:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants