Skip to content

fix: reject auto-generated gateways outside subnets#1447

Open
immanuwell wants to merge 1 commit into
containers:mainfrom
immanuwell:fix/create-singleton-subnet-gateway
Open

fix: reject auto-generated gateways outside subnets#1447
immanuwell wants to merge 1 commit into
containers:mainfrom
immanuwell:fix/create-singleton-subnet-gateway

Conversation

@immanuwell
Copy link
Copy Markdown

Small fix for create validation.

Before this, /32 and /128 subnets with no gateway slipped thru. Netavark generated network + 1, which is outside the subnet. Tiny footgun, tbh.

Repro:

  1. keep the new regression tests, but drop the code change
  2. run PROTOC=/tmp/netavark-protoc/bin/protoc cargo test validate_subnet_rejects_ --lib
  3. both tests fail because validate_subnet() returns Ok(()) for 10.100.0.1/32 and fd00::1/128

Now first_ip_in_subnet() checks the generated gateway is still inside the subnet and errors cleanly when it is not.

Tests:

  • PROTOC=/tmp/netavark-protoc/bin/protoc cargo test --lib

Signed-off-by: immanuwell <pchpr.00@list.ru>
Comment on lines +161 to 166
if !network.contains(&first_ip) {
return Err(NetavarkError::msg(format!(
"could not create gateway for subnet {}",
network
)));
}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

instead of adding another check here could you not just swap the order in validate_subnet() which already checks that as well.

Then again if we do not work with /32 or /128 then we might as well produce an actual error saying that explicitly at least.

@mheon
Copy link
Copy Markdown
Member

mheon commented May 11, 2026

LGTM

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.

3 participants