Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sscanf type mismatch #679

Closed
setharnold opened this issue Mar 26, 2022 · 2 comments
Closed

sscanf type mismatch #679

setharnold opened this issue Mar 26, 2022 · 2 comments

Comments

@setharnold
Copy link

n = sscanf(&pos[1], "%u", tcp_port);

Hello, parse_tcp_optarg() takes an int *tcp_port parameter, and passes this to sscanf():

            n = sscanf(&pos[1], "%u", tcp_port);
            if (n != 1) {
                fprintf(stderr, "Invalid port '%s'\n", &pos[1]);
                return -1;
            }
            if (*tcp_port >= 65536) {
                fprintf(stderr, "Port '%s' outside valid range.\n",
                    &optarg[1]);
                return -1;
            }

My copy of sscanf(3) includes:

       u      Matches an unsigned decimal integer; the next pointer
              must be a pointer to unsigned int.

and fscanf(3posix) includes:

       u       Matches an optionally signed decimal integer, whose
               format is the same as expected for the subject
               sequence of strtoul() with the value 10 for the base
               argument. In the absence of a size modifier, the
               application shall ensure that the corresponding
               argument is a pointer to unsigned.

What happens if someone enters a number in the three billion range? Will it become vastly negative and easily pass the if (*tcp_port >= 65536) condition?

Does it matter?

Thanks

stefanberger added a commit that referenced this issue Mar 26, 2022
The port being parsed must be given as unsigned int so that the comparison
of *tcp_port >= 65536 also captures negative numbers passed via the
command line. Previously one could pass -1 and swtpm_ioctl would try to
connect to port 65535.

Resolves: #679
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
@stefanberger
Copy link
Owner

Passing --tcp :-1 would try to connect to port 65535, which was a bug.

stefanberger added a commit that referenced this issue Mar 26, 2022
…bers

The port being parsed must be given as unsigned int so that the comparison
of *tcp_port >= 65536 also captures negative numbers passed via the
command line. Previously one could pass -1 and swtpm_ioctl would try to
connect to port 65535.

Resolves: #679
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
@stefanberger
Copy link
Owner

Thanks for reporting this bug.

stefanberger added a commit that referenced this issue Mar 28, 2022
…mbers

The port being parsed must be given as unsigned int so that the comparison
of *tcp_port >= 65536 also filters out negative numbers passed via the
command line. Previously one could pass -1 and swtpm_ioctl would try to
connect to port 65535.

Resolves: #679
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants