linux-ext4 - Re: [PATCH] e2fslibs: fix llseek on i386

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 Jan 2013 14:51:58 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Phillip Susi <psusi@...ntu.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH] e2fslibs: fix llseek on i386

On Thu, Jan 24, 2013 at 11:21:56AM -0500, Phillip Susi wrote:
> ext2fs_llseek() was using lseek instead of lseek64.  The
> only time it would use lseek64 is if passed an offset that
> overflowed 32 bits.  This works for SEEK_SET, but not
> SEEK_CUR, which can apply a small offset to move the file
> pointer past the 32 bit limit.
> 
> The code has been changed to instead try lseek64 first, and
> fall back to lseek if that fails.  It also was doing a
> runtime check of the size of off_t.  This has been moved to
> compile time.
> 
> Signed-off-by: Phillip Susi <psusi@...ntu.com>

How did you find this?  I've done a quick search for SEEK_CUR, and it
looks like only place where this could cause a problem is with
e2image.  And a quick test of a i386 version of e2image with a large
file system is that it does indeed blow up with an "Inappropriate
ioctl for device" error.

Is there any other potential problems that are caused by this bug?  I
like to explain the impacts of bug fixes in libext2fs for folks who
are doing bug fix / code archeology.

Thanks,

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html