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]
Message-ID: <524f69650907220828r25321e4ej6364213a97f7b63b@mail.gmail.com>
Date:	Wed, 22 Jul 2009 10:28:12 -0500
From:	Steve French <smfrench@...il.com>
To:	Jeff Layton <jlayton@...hat.com>
Cc:	Johannes Weiner <hannes@...xchg.org>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, hch@...radead.org
Subject: Re: [PATCH] fix offset checks in do_sendfile to use unsigned values

On Wed, Jul 22, 2009 at 9:13 AM, Jeff Layton<jlayton@...hat.com> wrote:
> On Wed, 2009-07-22 at 15:51 +0200, Johannes Weiner wrote:
>
>> > Any of these patches will fix the immediate problem, but I think this
>> > code in do_sendfile should still account for the possibility that
>> > someone can set the value larger than MAX_LFS_FILESIZE. An alternative
>> > is to consider a WARN at mount time when filesystems set s_maxbytes
>> > larger than that value (that might help catch out of tree filesystems
>> > that get this wrong and prevent this sort of silent bug in the future).
>>
>> Isn't MAX_LFS_FILESIZE by definition the maximum sensible value for
>> s_maxbytes?
>>
>
> Pretty much, but nothing seems to enforce it or let you know when you've
> exceeded it. It sort of seems like s_maxbytes ought to be loff_t or
> something instead of an unsigned long long. A negative value there
> wouldn't make much sense, but no one would be as tempted to set it
> higher than MAX_LFS_FILESIZE.
>
>> > Either way, the patch I posted for this isn't sufficient since there are
>> > some checks that need to be done against the signed values (the
>> > (pos < 0) check, for instance). I'll post a respun patch in a bit that
>> > should fix up those problems.
>>
>> That is already handled in rw_verify_area(), I think, so we should be
>> able to drop it completely.
>
> If we get rid of those checks altogether, then "max" will become unused.
> Is that really OK here?
>
> For discussion purposes, I've attached a replacement patch that I'm
> working with now.

Looks fine to me


-- 
Thanks,

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ