MySQL Bugs: #67956: The range of a transport-layer port" is [0, 65535] (unsigned short)

Bug #67956	The range of a transport-layer port" is [0, 65535] (unsigned short)
Submitted:	20 Dec 2012 18:14	Modified:	4 Mar 2013 15:03
Reporter:	Tianyin Xu	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Options	Severity:	S3 (Non-critical)
Version:	mysql-5.5.28	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
The range of a transport-layer port is defined as "unsigned short" with the numeric range [0, 65535]. Currently, the server does not check the range, which silently truncated a large user input to a "unsigned short" (integer overflow)

The symptom is that myslqd listens to the truncated port without warning or error.

I suggest to strict the range. It's really simple but helps typos and misunderstandings.

-       VALID_RANGE(0, UINT_MAX32), DEFAULT(0), BLOCK_SIZE(1));
+       VALID_RANGE(0, 65535), DEFAULT(0), BLOCK_SIZE(1));
 

How to repeat:
In my.cnf, set the following misconfiguration:

port = 9999999

start mysqld and it prints "Version: '5.5.28'  socket: '/home/tianyin/mysql-5.5.28/mysql/var/run/mysqld/mysqld.sock'  port: 9999999  Source distribution"

Use "netstat -nap" to check the port, in this case, it listens to 25362.

Suggested fix:
--- /home/tianyin/source/mysql-5.5.28/sql/sys_vars.cc	2012-12-19 22:23:04.156818131 -0800
+++ sql/sys_vars.cc	2012-12-19 22:15:29.466798875 -0800
@@ -1556,7 +1556,7 @@
 #endif
        "built-in default (" STRINGIFY_ARG(MYSQL_PORT) "), whatever comes first",
        READ_ONLY GLOBAL_VAR(mysqld_port), CMD_LINE(REQUIRED_ARG, 'P'),
-       VALID_RANGE(0, UINT_MAX32), DEFAULT(0), BLOCK_SIZE(1));
+       VALID_RANGE(0, 65535), DEFAULT(0), BLOCK_SIZE(1));
 
 static Sys_var_ulong Sys_preload_buff_size(
        "preload_buffer_size",

Thank you, verified as described on 5.5.29, 5.6.9

Hi, Shane,

Thanks for the confirmation.

I checked the reference manual, and there're three port directive that is configurable: "port", "report_port", and "master-port".

"master-port" is obsolete, and it simply get the value of "port" (see #769 in storage/ndb/test/run-test/setup.cpp). So the previous patch fixed it. 

For "report_port", the exact same thing applies (see the patch below):

--- mysql-5.5.28/sql/sys_vars.cc        2012-12-23 14:13:36.031139989 -0800
+++ ../Downloads/mysql-5.5.28/sql/sys_vars.cc   2012-12-23 14:13:14.051128375 -0800
@@ -1556,7 +1556,7 @@
 #endif
        "built-in default (" STRINGIFY_ARG(MYSQL_PORT) "), whatever comes first",
        READ_ONLY GLOBAL_VAR(mysqld_port), CMD_LINE(REQUIRED_ARG, 'P'),
-       VALID_RANGE(0, UINT_MAX32), DEFAULT(0), BLOCK_SIZE(1));
+       VALID_RANGE(0, 65535), DEFAULT(0), BLOCK_SIZE(1));
 
 static Sys_var_ulong Sys_preload_buff_size(
        "preload_buffer_size",
@@ -2777,7 +2777,7 @@
        "port or if you have a special tunnel from the master or other clients "
        "to the slave. If not sure, leave this option unset",
        READ_ONLY GLOBAL_VAR(report_port), CMD_LINE(REQUIRED_ARG),
-       VALID_RANGE(0, UINT_MAX), DEFAULT(0), BLOCK_SIZE(1));
+       VALID_RANGE(0, 65535), DEFAULT(0), BLOCK_SIZE(1));
 #endif
 
 static Sys_var_mybool Sys_keep_files_on_create(

Thanks! & Merry Xmas! 
Tianyin

Noted in 5.7.1 changelog.

The server did not enforce the port or report_port upper limit of
65,535 and truncated larger values.

The problem at hand is related to the range of a transport-layer port, which is defined as an "unsigned short" with a numeric span of [0, 65535]. However, the server currently fails to validate this range, resulting in a scenario where a hefty user input is silently truncated to an "unsigned short," leading to an overflow of integers.

Based on the described symptoms, it seems that mysqld continues to listen on the truncated port without issuing any warnings or errors. To tackle this issue, it would be highly advantageous to impose strict adherence to the range of the transport-layer port. This simple modification will prove instrumental in thwarting typos and misunderstandings in the future.

For more in-depth information, feel free to check out this source: https://networkustad.com/2023/05/16/energy-and-transportation/ 
It's remarkable to witness the proposed fix detailed in the bug report, which involves tweaking the sys_vars.cc file to specify the valid range for the port.

Let's remain hopeful that this solution will be swiftly implemented to avert similar complications down the line. And hey, if any of you have additional insights or suggestions, feel free to share them with the community!