Report information
The Basics
Id:
22033
Status:
resolved
Worked:
2.58 hours (155 minutes)
Users:
sar: 2.42 hours (145 minutes)
Priority:
Medium/Medium
Queue:

People
Owner:
Nobody in particular
Cc:
AdminCc:

BugTracker
Version Fixed:
(no value)
Version Found:
4.2.0
Versions Affected:
4.2
Versions Planned:
(no value)
Priority:
(no value)
Severity:
S2 Normal
CVSS Score:
(no value)
CVE ID:
(no value)
Component:
(no value)
Area:
(no value)

Attachments
Dates
Created:Fri, 03 Sep 2010 13:16:21 -0400
Updated:Wed, 21 Mar 2018 14:23:38 -0400
Closed:Thu, 30 Dec 2010 17:51:40 -0500



This bug tracker is no longer active.

Please go to our Gitlab to submit issues (both feature requests and bug reports) for active projects maintained by Internet Systems Consortium (ISC).

Due to security and confidentiality requirements, full access is limited to the primary maintainers.

Subject: dhcp-4.2.0 uses int for handling time values
Date: Fri, 03 Sep 2010 19:16:09 +0200
To: dhcp-bugs@isc.org
From: Jiri Popelka <jpopelka@redhat.com>
Hello there in ISC, There can be one small improvement in the newly (dhcp-4.2.0) added code. In common/dispatch.c the add_timeout() function was slightly modified. Problem is that the newly added code uses int sec, usec; for manipulating with time values, e.g. sec = when->tv_sec - cur_tv.tv_sec This can cause problems on 64bit machines when some crazy server sends huge values of lease-time/renewal-time/rebinding-time. For real example see https://bugzilla.redhat.com/show_bug.cgi?id=628258 Attached is patch that fixes it. Regards Jiri Popelka Red Hat, inc.

Message body is not shown because sender requested not to inline it.

Subject: Re: [ISC-Bugs #22033] dhcp-4.2.0 uses int for handling time values
Date: Fri, 3 Sep 2010 10:54:53 -0700
To: dhcp-bugs@isc.org
From: Larissa Shapiro <larissas@isc.org>
Hi Jiri, Thanks for the patch. Our guys will review and we will get back to you asap as to if we can include this in an upcoming release or not. Best Regards, Larissa ISC Product Manager On Sep 3, 2010, at 10:16 AM, Jiri Popelka via RT wrote: > > Fri Sep 03 17:16:21 2010: Request 22033 was acted upon. > Transaction: Ticket created by jpopelka@redhat.com > Queue: dhcp > Subject: dhcp-4.2.0 uses int for handling time values > Owner: Nobody > Requestors: jpopelka@redhat.com > Status: new > Ticket <URL: https://bugs.isc.org/Ticket/Display.html?id=22033 > > ----------------------------------------------------------------------- > > Hello there in ISC, > > There can be one small improvement in the newly (dhcp-4.2.0) added > code. > In common/dispatch.c the add_timeout() function was slightly modified. > Problem is that the newly added code uses > int sec, usec; > for manipulating with time values, e.g. > sec = when->tv_sec - cur_tv.tv_sec > > This can cause problems on 64bit machines when some crazy server sends > huge values of lease-time/renewal-time/rebinding-time. > For real example see > https://bugzilla.redhat.com/show_bug.cgi?id=628258 > > Attached is patch that fixes it. > Regards > > Jiri Popelka > Red Hat, inc. > > diff -up dhcp-4.2.0/common/dispatch.c.time dhcp-4.2.0/common/ > dispatch.c > --- dhcp-4.2.0/common/dispatch.c.time 2010-06-01 19:29:59.000000000 > +0200 > +++ dhcp-4.2.0/common/dispatch.c 2010-09-03 18:30:08.000000000 +0200 > @@ -185,7 +185,7 @@ void add_timeout (when, where, what, ref > struct timeout *t, *q; > int usereset = 0; > isc_result_t status; > - int sec, usec; > + struct timeval relative_time; > isc_interval_t interval; > isc_time_t expires; > > @@ -293,24 +293,24 @@ void add_timeout (when, where, what, ref > * about the usec value, if it's zero we assume the caller didn't > care. > */ > > - sec = when->tv_sec - cur_tv.tv_sec; > - usec = when->tv_usec - cur_tv.tv_usec; > + relative_time.tv_sec = when->tv_sec - cur_tv.tv_sec; > + relative_time.tv_usec = when->tv_usec - cur_tv.tv_usec; > > - if ((when->tv_usec != 0) && (usec < 0)) { > - sec--; > - usec += USEC_MAX; > + if ((when->tv_usec != 0) && (relative_time.tv_usec < 0)) { > + relative_time.tv_sec--; > + relative_time.tv_usec += USEC_MAX; > } > > - if (sec < 0) { > - sec = 0; > - usec = 0; > - } else if (usec < 0) { > - usec = 0; > - } else if (usec >= USEC_MAX) { > - usec = USEC_MAX - 1; > + if (relative_time.tv_sec < 0) { > + relative_time.tv_sec = 0; > + relative_time.tv_usec = 0; > + } else if (relative_time.tv_usec < 0) { > + relative_time.tv_usec = 0; > + } else if (relative_time.tv_usec >= USEC_MAX) { > + relative_time.tv_usec = USEC_MAX - 1; > } > > - isc_interval_set(&interval, sec, usec * 1000); > + isc_interval_set(&interval, relative_time.tv_sec, > relative_time.tv_usec * 1000); > status = isc_time_nowplusinterval(&expires, &interval); > if (status != ISC_R_SUCCESS) { > /*

Message body is not shown because it is too large.

Subject: Re: [ISC-Bugs #22033] dhcp-4.2.0 uses int for handling time values
Date: Thu, 25 Nov 2010 15:32:52 +0100
To: dhcp-bugs@isc.org
From: Jiri Popelka <jpopelka@redhat.com>
On 11/25/2010 12:38 AM, Shawn Routhier via RT wrote: > Thank you for the bug report. We've chose a different solution in order to > limit what gets passed into the isc_interval_set call. I'm attaching a copy of > the diff to the ticket. I would appreciate it if you can verify the fix > (assuming the testbed is still available). Hi, I verify that the diff you sent me fixes the problem. Jiri > Cut here for diff > > <snip>
Subject: Re: [ISC-Bugs #22033] dhcp-4.2.0 uses int for handling time values
Date: Mon, 13 Dec 2010 11:04:31 +0100
To: dhcp-bugs@isc.org
From: Jiri Popelka <jpopelka@redhat.com>
Hi Shawn, see my small remark lower in the code. Jiri On 11/25/2010 12:38 AM, Shawn Routhier via RT wrote: > Thank you for the bug report. We've chose a different solution in order to > limit what gets passed into the isc_interval_set call. I'm attaching a copy of > the diff to the ticket. I would appreciate it if you can verify the fix > (assuming the testbed is still available). > > Cut here for diff > > --- DHCP/RELNOTES:1.405 Thu Nov 18 19:47:36 2010 > +++ DHCP/RELNOTES Wed Nov 24 22:25:02 2010 > @@ -144,6 +144,9 @@ > a setsockopt() call. The signal is already being ignored as part > of the ISC library. [ISC-Bugs #22269] > > +- Limit the timeout period allowed in the dispatch code to 2^^32-1 seconds. > + Thanks to a report from Jiri Popelka at Red Hat. > + [ISC-Bugs #22033], [Red Hat Bug #628258] > > Changes since 4.2.0b2 > > Index: DHCP/common/dispatch.c > diff -u DHCP/common/dispatch.c:1.75 DHCP/common/dispatch.c:1.75.46.1 > --- DHCP/common/dispatch.c:1.75 Tue May 25 00:22:29 2010 > +++ DHCP/common/dispatch.c Wed Nov 24 22:25:02 2010 > @@ -174,6 +174,7 @@ > > /* maximum value for usec */ > #define USEC_MAX 1000000 > +#define DHCP_SEC_MAX 0xFFFFFFFF > > void add_timeout (when, where, what, ref, unref) > struct timeval *when; > @@ -185,7 +186,8 @@ > struct timeout *t, *q; > int usereset = 0; > isc_result_t status; > - int sec, usec; > + int64_t sec; > + int usec; > isc_interval_t interval; > isc_time_t expires; > > @@ -227,9 +229,49 @@ > q->what = what; > } > > - /* We don't really need this, but keep it for now */ > - q->when.tv_sec = when->tv_sec; > - q->when.tv_usec = when->tv_usec; > + /* > + * The value passed in is a time from an epoch but we need a relative > + * time so we need to do some math to try and recover the period. > + * This is complicated by the fact that not all of the calls cared > + * about the usec value, if it's zero we assume the caller didn't care. > + * > + * The ISC timer library doesn't seem to like negative values > + * and can't accept any values above 4G-1 seconds so we limit > + * the values to 0<= value< 4G-1. We do it before > + * checking the trace option so that both the trace code and > + * the working code use the same values. > + */ > + > + sec = when->tv_sec - cur_tv.tv_sec; > + usec = when->tv_usec - cur_tv.tv_usec; > + > + if ((when->tv_usec != 0)&& (usec< 0)) { > + sec--; > + usec += USEC_MAX; > + } > + > + if (sec< 0) { > + sec = 0; > + usec = 0; > + } else if (sec> DHCP_SEC_MAX) { > + log_error("Timeout requested too large %lld " > + "reducing to 2^^32-1", sec); > + sec = DHCP_SEC_MAX; > + usec = 0; > + } > + else if (usec< 0) { > + usec = 0; > + } else if (usec>= USEC_MAX) { > + usec = USEC_MAX - 1; > + } > + > + /* > + * This is necessary for the tracing code but we put it > + * here in case we want to compare timing information > + * for some reason, like debugging. > + */ > + q->when.tv_sec = cur_tv.tv_sec + (sec& DHCP_SEC_MAX); > + q->when.tv_usec = usec; > > #if defined (TRACING) > if (trace_playback()) { > @@ -279,38 +321,7 @@ > q->next = timeouts; > timeouts = q; > > - /* > - * Set up the interval values - The previous timers allowed > - * negative values to be set, the ISC timer library doesn't like > - * that so we make any negative values 0 which sould amount to > - * the same thing. > - */ > - > - /* > - * The value passed in is a time from an epoch but we need a relative > - * time so we need to do some math to try and recover the period. > - * This is complicated by the fact that not all of the calls cared > - * about the usec value, if it's zero we assume the caller didn't care. > - */ > - > - sec = when->tv_sec - cur_tv.tv_sec; > - usec = when->tv_usec - cur_tv.tv_usec; > - > - if ((when->tv_usec != 0)&& (usec< 0)) { > - sec--; > - usec += USEC_MAX; > - } > - > - if (sec< 0) { > - sec = 0; > - usec = 0; > - } else if (usec< 0) { > - usec = 0; > - } else if (usec>= USEC_MAX) { > - usec = USEC_MAX - 1; > - } > - > - isc_interval_set(&interval, sec, usec * 1000); > + isc_interval_set(&interval, sec& 0xFFFFFFFF, usec * 1000); Probably should be + isc_interval_set(&interval, sec& DHCP_SEC_MAX, usec * 1000); instead of + isc_interval_set(&interval, sec& 0xFFFFFFFF, usec * 1000); > status = isc_time_nowplusinterval(&expires,&interval); > if (status != ISC_R_SUCCESS) { > /* >
On Mon Dec 13 10:04:43 2010, jpopelka@redhat.com wrote:
> Hi Shawn,
>
> see my small remark lower in the code.
>
> Jiri

Yep, I had spotted that as well but only after
sending the mail to you.
Thank you for the careful review of the code.

Shawn


Thank you for the report.  The patch has been committed.
HEAD =>
4.2     => 4.2.1 next (likely 4.2.1b1)

The problem was added in 4.2 and so previous versions are not affected.