Bug 1293249

Summary: [virtio-win][vioser] IOCTL_GET_INFORMATION does not return required buffer size
Product: Red Hat Enterprise Linux 7 Reporter: Ladi Prosek <lprosek>
Component: virtio-winAssignee: Ladi Prosek <lprosek>
virtio-win sub component: distribution QA Contact: Virtualization Bugs <virt-bugs>
Status: CLOSED ERRATA Docs Contact:
Severity: unspecified    
Priority: unspecified CC: jherrman, juzhang, lijin, lmiksik, michen, nat, phou, vrozenfe, wyu
Version: 7.4   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
The IOCTL_GET_INFORMATION virtio-serial device IO control call previously didn't return the actual size of the data in case a too small of a buffer was passed. This made it impossible for applications to query the size, often resorting to worst case guesses. This update introduces a new IOCTL_GET_INFORMATION IO control code with the same semantics as the old one, only with the bug fixes. The old IO control code is still supported for backward compatibility, now named IOCTL_GET_INFORMATION_BUFFERED in the source files.
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-04 08:49:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Ioctl failed with code 122_with build 102
none
Serial port information is printed_with build 115
none
Serial port information is normal with build 117 none

Description Ladi Prosek 2015-12-21 08:42:15 UTC
Description of problem:
The way IOCTL_GET_INFORMATION is handled suggests that if the supplied output buffer is too small, the required size would be passed back to the caller. This doesn't work because we use STATUS_BUFFER_TOO_SMALL (error) as opposed to STATUS_BUFFER_OVERFLOW (warning) and the IO manager will not propagate anything back if the ioctl failed with an error. Switching to the warning code still wouldn't work because we use METHOD_BUFFERED and the IO manager would actually attempt to copy that many bytes back to the userspace buffer and corrupt it.

Interesting read about the topic
http://blogs.msdn.com/b/doronh/archive/2006/12/12/how-to-return-the-number-of-bytes-required-for-a-subsequent-operation.aspx

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Run the vioser-test app (vioserial/app)
2. Type 'i' for info

Actual results:
Serial port information is printed

Expected results:
IOCTL fails

Additional info:

Comment 3 Peixiu Hou 2016-03-24 07:11:39 UTC
Created attachment 1139850 [details]
Ioctl failed with code 122_with build 102

Hi Ladi,

I tried this issue with build 102 and a newer build 115.

With the build 102, run vioser-test.exe, type "i", error massage "Ioctl failed with code 122" shown, detail please refer to the attachment1 [details].

With the build 115, run vioser-test.exe, type "i", Serial port information is printed, detail please refer to the attachment2 [details].

According to the comment 0, actual result is "Serial port information is printed", Expected results is "IOCTL fails". But I verified results seem not match the comment 0. So please help to confirm if the actual result and expected result of comment 0 were written reversed? Thanks so much~~


Best Regards!
Peixiu Hou

Comment 4 Peixiu Hou 2016-03-24 07:13:48 UTC
Created attachment 1139851 [details]
Serial port information is printed_with build 115

Comment 5 Ladi Prosek 2016-03-28 15:05:51 UTC
Hi Peixiu Hou,

Yes, the actual and expected result in comment 0 are reversed. "Serial port information is printed" is the expected result. Sorry about that!

Thanks,
Ladi

Comment 6 Nat Meo 2016-05-11 19:08:54 UTC
I have encountered a problem with the latest 117 drivers when using IOCTL_GET_INFORMATION. Here is the specific code snippet I have:

BYTE buffer[512];
ULONG length = 0;
BOOL success = DeviceIoControl(handle,
                               IOCTL_GET_INFORMATION,
                               NULL,
                               0,
                               buffer,
                               sizeof(buffer),
                               &length,
                               NULL);

When using the 102 drivers, this works successfully. But when I use the latest 117 drivers the DeviceIoControl call returns false and GetLastError() returns 1 with a message of "Incorrect function". Not sure if the changes discussed here somehow broke this.

Comment 7 Ladi Prosek 2016-05-11 19:36:26 UTC
(In reply to Nat Meo from comment #6)
> I have encountered a problem with the latest 117 drivers when using
> IOCTL_GET_INFORMATION. Here is the specific code snippet I have:
> 
> BYTE buffer[512];
> ULONG length = 0;
> BOOL success = DeviceIoControl(handle,
>                                IOCTL_GET_INFORMATION,
>                                NULL,
>                                0,
>                                buffer,
>                                sizeof(buffer),
>                                &length,
>                                NULL);
> 
> When using the 102 drivers, this works successfully. But when I use the
> latest 117 drivers the DeviceIoControl call returns false and GetLastError()
> returns 1 with a message of "Incorrect function". Not sure if the changes
> discussed here somehow broke this.

Yes, they did. The IOCTL code changed (intentionally) but the driver was also supposed to keep responding to the old one for compatibility. The second part somehow didn't make it into the tree.

A huge thank you for the report. If you know that you'll always query driver 117 or later, the workaround is to rebuild the code against the current sources where the code is defined like so:

#define IOCTL_GET_INFORMATION    CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_OUT_DIRECT, FILE_ANY_ACCESS)

Thanks again,
Ladi

Comment 9 Peixiu Hou 2016-06-08 02:56:57 UTC
Created attachment 1165801 [details]
Serial port information is normal with build 117

I retested this issue with build 117 driver, step as comment#0, the output serial port information is normal, detail please refer to the attachment, thanks~

Best Regards~
Peixiu Hou

Comment 11 Yu Wang 2016-06-12 09:49:09 UTC
change status to Verified according to comment#9

Thanks
Yu Wang

Comment 14 errata-xmlrpc 2016-11-04 08:49:43 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2609.html