Bug 2264

Summary:	RekeyLimit option does not allow '4G' value when UINT_MAX is 0xffffffff
Product:	Portable OpenSSH	Reporter:	Garrett Lee <glee>
Component:	sshd	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	CLOSED FIXED
Severity:	normal	CC:	djm, dtucker
Priority:	P5
Version:	6.6p1
Hardware:	Other
OS:	Linux
Bug Depends on:
Bug Blocks:	2451

Description Garrett Lee 2014-08-26 00:52:00 AEST

When value '4G' is used to specify the RekeyLimit value, the configuration file parsing function, scan_scaled(), converts the 4G into value 4294967296 (in readconf.c and in servconf.c alike).

On systems where UINT_MAX is 0xffffffff, we are not able to configure value '4G' due to the 4294967296 being greater than 4294967295.  This appears to be a bug since one would expect a value of 4G to be able to be specified on a 32-bit OS.  The way in which the function set_newkeys() sets the value of max_blocks, it seems like openssh should be able to allow value 4G and perform the math to determine number of blocks before rekey takes place.

Comment 1 Damien Miller 2015-05-22 15:49:18 AEST

rekey_limit is actually an int64_t, so this could probably be increased. That being said, 4G is a bit long between rekeys...

Comment 2 Damien Miller 2015-08-11 22:59:09 AEST

Retarget pending bugs to openssh-7.1

Comment 3 Darren Tucker 2016-02-05 13:54:29 AEDT

This has been fixed, you can now specify RekeyLimits up to 2**63.

https://anongit.mindrot.org/openssh.git/commit/?id=921ff00b0ac429666fb361d2d6cb1c8fff0006cb

upstream commit
Allow RekeyLimits in excess of 4G up to 2**63 bits
 (limited by the return type of scan_scaled).  Part of bz#2521, ok djm.

Upstream-ID: 13bea82be566b9704821b1ea05bf7804335c7979

Comment 4 Damien Miller 2016-08-02 10:42:00 AEST

Close all resolved bugs after 7.3p1 release