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

proto/rr: do not deserialize ClientSubnets with invalid prefixes #2057

Merged
merged 1 commit into from Oct 12, 2023

Conversation

00xc
Copy link
Contributor

@00xc 00xc commented Oct 11, 2023

When serializing a ClientSubnet, if the source prefix is larger than the address itself, we return an error. However, when deserializing the same type we will happily take an invalid prefix. Fix this consistency issue by rejecting invalid prefixes during deserialization.

Before, this would cause the following fuzzing harness to fail, given the appropriate input:

#![no_main]

use libfuzzer_sys::fuzz_target;
use trust_dns_proto::rr::rdata::opt::ClientSubnet;
use trust_dns_proto::serialize::binary::BinDecodable;
use trust_dns_proto::serialize::binary::BinEncodable;

fuzz_target!(|data: &[u8]| {
    if let Ok(net) = ClientSubnet::from_bytes(data) {
        net.to_bytes().unwrap();
    }
});

This would also impact (de)serialization of other types which embed ClientSubnets.

When serializing a ClientSubnet, if the source prefix is larger than
the address itself, we return an error. However, when deserializing
the same type we will happily take an invalid prefix. Fix this
consistency issue by rejecting invalid prefixes during
deserialization.
Copy link
Collaborator

@djc djc left a comment

Choose a reason for hiding this comment

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

Thanks!

@djc djc merged commit c9cc5c9 into hickory-dns:main Oct 12, 2023
17 checks passed
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.

None yet

2 participants