Bug 1860391

Summary:	dhclient runs out of all available addresses in the pool in case of abnormal script termination
Product:	Red Hat Enterprise Linux 7	Reporter:	shader
Component:	dhcp	Assignee:	Pavel Zhukov <pzhukov>
Status:	CLOSED WONTFIX	QA Contact:	qe-baseos-daemons
Severity:	medium	Docs Contact:
Priority:	low
Version:	7.8
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-09-22 06:50:49 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description shader 2020-07-24 12:49:07 UTC

Description of problem (copied from ISC BT):
===========================================

Some Linux distribution, eg. CentOS Linux 7.x or 8.x, use NetworkManager to configure network interfaces. The dhclient command started by NetworkManager looks like this:
/sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper \
    -pf /run/NetworkManager/dhclient-<iface_name>.pid \
    -lf /var/lib/NetworkManager/dhclient-<connection_uuid>-<iface_name>.lease \
    -cf /var/lib/NetworkManager/dhclient-<iface_name>.conf <iface_name>
When dhclient receive answer from server on lease renewal it use script or binary specified by -sf option for IP validity checking.
/* If the BOUND/RENEW code detects another machine using the
   offered address, it exits nonzero. We need to send a
   DHCPDECLINE and toss the lease. */
if (script_go(client)) {
    make_decline(client, client->new);
    send_decline(client);
    destroy_client_lease(client->new);
But the script_go function return non-zero result in the 2 cases:

Launched process exit status is non-zero. In this case script_go function return value > 0.
Launched process terminated by signal, eg. SIGTEM. In this case script_go function return value < 0.

Let's imagine the next situation. nm-dhcp-helper or other script or binary specified by -sf option starting at some time will always terminates by SIGSEGV due to filesystem damage or some dynamic library incompatibility. In this case the dhclient will send DECLINE and retry lease renewal after 10 seconds timeout. This will repeat infinitely until all available addresses in the DHCP pool will be marked as invalid and other clients will not be able to lease an IP address.

Solution:
=========

To eliminate the possibility of a repetition of such a situation, it is enough in the above code fragment to replace a line
if (script_go(client)) {
by
if (script_go(client) > 0) {


Version-Release number of selected component (if applicable): all


How reproducible: always


Steps to Reproduce:
===================

1. Create simple C-program that will always cause SIGSEGV:
--- example.c ---
int main ()
{
    char *p;
    memset(p, 0, 1000000);
}
--- cut here ---

2. Compile example with following command:
gcc -o nm-dhcp-helper example.c

3. Replace original /usr/libexec/nm-dhcp-helper by compiled example.

4. Wait for dhclient renew lease


Actual results: all available IP-addresses in th DHCP pool are exhausted and other clients can't receive lease


Expected results: one computer can fail, but the infrastructure should function normally

Comment 3 Pavel Zhukov 2020-07-31 11:56:11 UTC

Hello,

Thank you for reporting this issue.
While I agree that's the bug it's not a reason of exhausted dhcp pool. Crafted application may send dhcpdecline for each lease it offered but this should not lead to DoS situation.

Comment 4 Pavel Zhukov 2020-09-22 06:50:49 UTC

RHEL-7 is already in Maintenance Support 2 phase, which means that only Critical impact Security Advisories and selected Urgent Priority Bug Fix Advisories may be addressed. Please see https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_2_Phase for further information.

Since this bug does not meet the criteria, we'll close it as WONTFIX. Feel free to discuss this Bug with Support Representative, if this is a critical issue for you. Please provide business justification in such case.

This issue is being tracked upstream and Fedora.