From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id BC6A21FF13F for ; Wed, 14 Jan 2026 19:18:50 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 8A3591A537; Wed, 14 Jan 2026 19:18:40 +0100 (CET) Message-ID: <07fabd35-0c12-43be-878d-14c8b4965e11@proxmox.com> Date: Wed, 14 Jan 2026 19:18:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Fiona Ebner , Proxmox VE development discussion References: <20251126154928.430607-1-s.hanreich@proxmox.com> <60906194-8403-49d3-a622-3ab344f56c23@proxmox.com> Content-Language: en-US From: Stefan Hanreich In-Reply-To: <60906194-8403-49d3-a622-3ab344f56c23@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.277 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment KAM_MAILER 2 Automated Mailer Tag Left in Email RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [thekelleys.org.uk, dnsmasq.pm] Subject: Re: [pve-devel] [PATCH pve-network 1/1] fix #5949: avoid dnsmasq segfault when subnet has no gateway X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On 1/14/26 3:48 PM, Fiona Ebner wrote: > Am 26.11.25 um 4:49 PM schrieb Stefan Hanreich: >> When trying to start a guest with a network device in a VNet in a >> simple zone that has DHCP enabled - but no gateway configured - a >> SIGSEGV is triggered in dnsmasq. This seems to be an error in the >> dnsmasq dbus handler that tries to allocate a lease, which fails >> because there is no dhcp-range configured, and then leads to a >> segfault. >> >> Avoid the situation completely by always configuring a dhcp-range, >> even if there is no gateway configured. Skip configuring the DHCP >> option that returns the router instead, which is the only place in the >> configure_subnet function that uses the gateway. >> >> Dnsmasq is configured to listen on an interface, so any DHCP messages >> that are received on this interface are dropped, because dnsmasq >> recognizes that there is no IP configured on this interface: >> >> Nov 26 16:35:49 ipam-test dnsmasq-dhcp[140272]: DHCP packet received on vnet1 which has no address >> Nov 26 16:35:57 ipam-test dnsmasq-dhcp[140272]: DHCP packet received on vnet1 which has no address >> >> An initial upstream patch to fix the segfault has been submitted here >> [1]. >> >> [1] https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2025q4/018342.html >> >> Signed-off-by: Stefan Hanreich >> --- >> src/PVE/Network/SDN/Dhcp/Dnsmasq.pm | 5 +---- >> 1 file changed, 1 insertion(+), 4 deletions(-) >> >> diff --git a/src/PVE/Network/SDN/Dhcp/Dnsmasq.pm b/src/PVE/Network/SDN/Dhcp/Dnsmasq.pm >> index db22e12..6a1e3b0 100644 >> --- a/src/PVE/Network/SDN/Dhcp/Dnsmasq.pm >> +++ b/src/PVE/Network/SDN/Dhcp/Dnsmasq.pm >> @@ -138,9 +138,6 @@ sub add_ip_mapping { >> sub configure_subnet { >> my ($class, $config, $dhcpid, $vnetid, $subnet_config) = @_; >> >> - die "No gateway defined for subnet $subnet_config->{id}" >> - if !$subnet_config->{gateway}; >> - >> my $tag = $subnet_config->{id}; >> >> my ($zone, $network, $mask) = split(/-/, $tag); > > 1. How "ugly" do you consider the workaround here? How much better than > the segfault from a user perspective? Would it be nicer to go back to > the old behavior with the clear error in the future once the dnsmasq fix > is in downstream? If yes, we should add a reminder comment to do so. from user pov better imo, since it only requires the user to configure a gateway when they run into the issue, whereas otherwise they'd need to restart the correct dnsmasq service as well. The unit file from upstream we're using sets `Restart=No`. Since it doesn't really make sense to have DHCP configured without a gateway for the VNet, I'd reintroduce the warning after the upstream fix has found its way to us. Will add a comment in a v2. > 2. What is the situation for IPv6 when there is no gateway? Would it be > worth to keep the early die with the explicit error in the IPv6 case? Yes, would make sense imo - since the segfault doesn't occur for the IPv6 case. I'll double-check tomorrow to make sure, only did some cursory checks now. >> @@ -155,7 +152,7 @@ sub configure_subnet { >> my $option_string; >> if (ip_is_ipv6($subnet_config->{network})) { >> $option_string = 'option6'; >> - } else { >> + } elsif ($subnet_config->{gateway}) { >> $option_string = 'option'; >> push @{$config}, "dhcp-option=tag:$tag,$option_string:router,$subnet_config->{gateway}"; >> } > _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel