Bug 13743 - Logical "off by one" issue in loop counts up to IOV_MAX
Summary: Logical "off by one" issue in loop counts up to IOV_MAX
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
Depends on:
Reported: 2019-01-14 23:32 UTC by Jura Sasek
Modified: 2019-01-15 06:47 UTC (History)
0 users

See Also:

IOV_MAX "off by one" issue fix in lib/tsocket/tsocket.c (853 bytes, patch)
2019-01-14 23:32 UTC, Jura Sasek
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jura Sasek 2019-01-14 23:32:25 UTC
Created attachment 14771 [details]
IOV_MAX "off by one" issue fix in lib/tsocket/tsocket.c

As the POSIX says in:
the "iovcnt" (3rd arg. of writev/readv) should be in:
 0 <= iovcnt <= {IOV_MAX}
so the loop counts the index into the field should count up to IOV_MAX - 1

note: 0 means "no vector" -> nothing to transfer
Comment 1 Jura Sasek 2019-01-15 00:00:08 UTC
I apologize for the following mistakes:
 - comment about difference in Solaris man is wrong - both are the same
 - 0 < iovcnt <= IOV_MAX so 0 <= field_index <= {IOV_MAX - 1}
Comment 2 Volker Lendecke 2019-01-15 06:47:29 UTC
Hmm. IOV_MAX on Solaris is 16, right? To be honest, I fail to see how tsocket passes "17" down to writev/readv. I think the ">" condition in current master is correct. Posix says "less than or equal to {IOV_MAX}".

There are other calls to writev/readv in the code that might not check this correctly. Can you check the precise call stack with dtrace or something? Or explain how tsocket violates the "or equal to {IOV_MAX}" condition?