RE: Difference in buffer behaviour between 8.89 and 8.9?

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]


On Wednesday, September 6, 2023 11:49 PM, Damien Miller wrote:
>On Wed, 6 Sep 2023, rsbecker@xxxxxxxxxxxxx wrote:
>> On Thursday, May 19, 2022 5:21 PM, Scott Neugroschl wrote:
>> >Isn't that a consequence of the limits on the nonstop READX call?
>> Yes it is an OS limit. I have been able to partially get this to work
>> as
>> follows:
>> @@ -281,6 +281,10 @@ sshbuf_read(int fd, struct sshbuf *buf, size_t
>> maxlen, size_t *rlen)
>>         if (rlen != NULL)
>>                 *rlen = 0;
>> +#if defined (__TANDEM)
>> +       if (maxlen > SSIZE_MAX)
>> +               maxlen = SSIZE_MAX; // About 56Kb from limits.h #endif
>> But I cannot figure out the best way to deal with the writes or the
>> most acceptable way to the OpenSSH team. Any suggestions?
>Is this true for all read() calls or just particular ones? If it's for all
read() calls, then
>maybe wrapping/replacing the read() function more generally would be
>channels.c isn't the only place in OpenSSH that might do a large read...

This is only for sshbuf_read at the moment, which got through most issues. I
could attempt the following that another project did:

What the git project did was create a compatibility layer with procs xread
and xwrite, with the same arguments as read/write, that allowed platform
handling to be tweaked. Not a small change, though. It would be easier if
there were defines that would be in place to guard this.

openssh-unix-dev mailing list

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux