[PATCH] [NFS client] Respect 2^32 - 1 B NFSv2 maximum file size

[Nick Withers]

The RTEMS NFS(v2) client in at least 4.11 and master does not range check off_t values before assigning them into NFSv2's on-the-wire 32-bit unsigned file offset field.

Reads from and writes to an offset at or above 4 GiB will currently silently be remapped to the mod 2^{32 location (on two's complement machines at least).}

The attached patch checks for negative offsets [1] and out of [0 - UINT32_MAX)-range access in nfs_file_read(), nfs_file_write() and nfs_file_ftruncate(). It doesn't touch the lseek() implementation, so an lseek() past NFSv2 range will still "succeed" - a subsequent read or write there won't. I think this is POSIX-compliant [2], however.

[1] Perhaps unnecessary if it's impossible for a negative offset to be obtained without e.g., an application user twiddling things they shouldn't? lseek() at least does correctly error on obtaining negative offsets

[2] e.g., ​http://pubs.opengroup.org/onlinepubs/009695399/functions/lseek.html doesn't explicitly seem to require lseek() to fail for out-of range offsets that aren't negative, and it mustn't do a resize itself

[Nick Withers]

Slight change to patch - we've already converted iop->offset to a uint32_t

[Nick Withers <nick.withers@…>]

In 040ddd23b545cc88c8be7f2ca9acadd85562e445/rtems:

Respect 2^{32 - 1 B NFSv2 maximum file size}

closes #2384

[Nick Withers <nick.withers@…>]

In 7a0df6b947c3c1108f84892cb884564688ebf818/rtems:

Respect 2^{32 - 1 B NFSv2 maximum file size}

closes #2384