WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 3 years ago

#17725 closed defect (bug) (wontfix)

wp_convert_hr_to_bytes() fails on large numeric values

Reported by: hakre Owned by:
Milestone: Priority: normal
Severity: trivial Version: 2.3
Component: Formatting Keywords: needs-refresh
Focuses: Cc:

Description

The wp_convert_hr_to_bytes() function exists to convert values in form of a memory setting into it's value in bytes.

By doing so, the function modifies the input value in every case. This modification has an issue with integer limits.

Whenever a value of $size is passed to the function that is in it's numerical part larger than PHP_INT_MAX, the input value will be capped to PHP_INT_MAX.

This is an integer overflow.

This applies as well when size has a shorthand ending specifier and it's numerical part is greater than PHP_INT_MAX.

To illustrate the problem on a 32 bit system:

	$setting = '2147483648';
	echo "'$setting' are ", wp_convert_hr_to_bytes($setting), " bytes.\n";
	// '2147483648' are 2147483647 bytes.

It shows that the last byte is missing. Every other byte on top will be capped as well. The number of bytes given are a value equally to '2G'.

Solution: Input values should not be capped to int but to float which has allows higher values.

Attachments (3)

17725.diff (1.2 KB) - added by hakre 7 years ago.
Use float instad of int.
17725.2.diff (1.1 KB) - added by hakre 7 years ago.
Additional patch related to #14889
17725.3.diff (1.1 KB) - added by hakre 7 years ago.
Update of .2: substr(-1) issues a warning on empty string.

Download all attachments as: .zip

Change History (12)

@hakre
7 years ago

Use float instad of int.

#1 @hakre
7 years ago

Related: #14889

@hakre
7 years ago

Additional patch related to #14889

@hakre
7 years ago

Update of .2: substr(-1) issues a warning on empty string.

#2 @nacin
6 years ago

  • Version changed from 3.2 to 2.3

#3 @chriscct7
3 years ago

  • Keywords needs-refresh added; has-patch removed

Needs to refresh to update the comment block for the function as they've been updated in core since this patch was made

#4 @DrewAPicture
3 years ago

The docs were updated in [23437].

#5 @DrewAPicture
3 years ago

  • Component changed from General to Media

#6 @johnbillion
3 years ago

  • Component changed from Media to Formatting

#7 @miqrogroove
3 years ago

  • Severity changed from normal to trivial

I would be curious if 32-bit servers are even capable of receiving uploads larger than 2 GB. This strikes me as a very trivial issue.

#8 @miqrogroove
3 years ago

http://php.net/manual/en/ini.core.php

This even specifies a signed integer limit on post_max_size > upload_max_filesize, both of which are directly referenced in wp_max_upload_size().

The description, "It shows that the last byte is missing," is invalid considering PHP will limit the post payload to 2GB - 1 in that situation.

I vote wontfix. However, it might be helpful to update the docs to indicate this function is specifically tied to the INI syntax and corresponding limitations.

#9 @nacin
3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

The logic in the new patch is also var too obtuse (and fragile).

Hypothetically, this function should indeed work for any human-readable size value, based on what it is named and currently documented. This works fine for values using "K", "KB", or "KiB" etc. It should hypothetically be able to convert a 500GB hard drive to bytes. But in practice, if this fails on a 32-bit system, I don't really care.

Note: See TracTickets for help on using tickets.