[PATCH v2] lseek: Correct order of offset arguments

Bernhard Reutner-Fischer rep.dot.nop at gmail.com
Mon Aug 18 10:03:08 UTC 2014


On Fri, Aug 01, 2014 at 10:18:47PM +0400, Anton Kolesov wrote:
> There was a runtime error in systems without large file support. Call
> fseek(fd, 4096, SEEK_SET) has been failing with EINVAL, though it was
> succeeding for offset = 4092. This has been happening because llseek system
> call accepts 64-bit value as an offset argument and lseek function has been
> ordering 32-bits words that form this offset value, according to the
> endianness. However this ordering to match endianness is not required,
> because llseek doesn't accept one 64-bit offset argument, it accepts two
> 32-bit offset argument, then stitches them into one following its
> endianness. As a result on little endian system, order of words has been
> swapped two time: in libc and in kernel. Thus call to fseek with offset 4096
> (0x1000) was doing a system call to llseek with offset 0x1000_0000_0000. I'm
> not entirely sure why then offset = 4092 hasn't been failing then.
> 
> This patch removes malicious swap of words when calling llseek.

Applied, thanks!


More information about the uClibc mailing list