linux-kernel - Re: [RFC v3 36/45] NFSv4: Fix GETATTR bitmap verification

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: <CAHpGcMLJ0R5fKMnrFV5HsJ5Pi7evc057uN2RBuNMcYO+szwWeA@mail.gmail.com>
Date:	Thu, 28 May 2015 23:15:29 +0200
From:	Andreas Grünbacher <andreas.gruenbacher@...il.com>
To:	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-nfs@...r.kernel.org
Subject: Re: [RFC v3 36/45] NFSv4: Fix GETATTR bitmap verification

2015-05-28 22:33 GMT+02:00 J. Bruce Fields <bfields@...ldses.org>:
> On Fri, Apr 24, 2015 at 01:04:33PM +0200, Andreas Gruenbacher wrote:
>> The client fails to detect when unexpected attributes are sent after the last
>> expected attribute in each word in the bitmap.
>
> Is it important that the client catch that?

Yes if there are more attributes in the next word that the client cares about;
probably no otherwise.

>> Fix this by checking the entire bitmap for unexpected attributes first.  The
>> server can still send attributes which the client understands but which it
>> didn't request; this doesn't cause any harm.
>
> I don't understand that last sentence.  On a skim it looks like after
> this patch we *will* still error out if a server does that, right?  (As
> we should, that would be a server bug.)

We don't actually verify the request bitmap against the reply bitmap;
we don't keep
the request bitmap around long enough. Some decode functions understand a set
of attributes. Currently, we happily accept any of the attributes the
decode function
in question accepts, even ones that were not requested. That could be fixed by
checking the request bitmap against the reply bitmap as well of course.

Andreas
--
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/