linux-kernel - Re: [V9fs-developer] [PATCH] Integer underflow in pdu

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: <bc857171-8abb-765c-d722-908ab743cd6e@gmail.com>
Date:   Tue, 10 Jul 2018 00:14:21 +0200
From:   Tomas Bortoli <tomasbortoli@...il.com>
To:     Al Viro <viro@...IV.linux.org.uk>
Cc:     ericvh@...il.com, rminnich@...dia.gov, lucho@...kov.net,
        davem@...emloft.net, v9fs-developer@...ts.sourceforge.net,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        syzkaller@...glegroups.com
Subject: Re: [V9fs-developer] [PATCH] Integer underflow in pdu_read()

On 07/09/2018 09:31 PM, Al Viro wrote:
> On Mon, Jul 09, 2018 at 09:26:51PM +0200, Tomas Bortoli wrote:
>> The pdu_read() function suffers from an integer underflow.
>> When pdu->offset is greater than pdu->size, the length calculation will have
>> a wrong result, resulting in an out-of-bound read.
>> This patch modifies also pdu_write() in the same way to prevent the same
>> issue from happening there and for consistency.
> What does cause the calls of pdu_read() in such conditions and shouldn't *that*
> be dealt with?
Mmh I think that's caused by p9_parse_header(). That function reads the
first 7 bytes of a PDU regardless of the current offset. It then sets
the PDU length to the one read and then it restores the original offset.
Therefore, it's possible to set a size < offset here.
(to be 100% sure I'd need more debugging)

We can prevent it in p9_parse_header(), but if the invariant offset <
size gets broken elsewhere we fall back to the underflow. Enforcing it
in pdu_read() should be the safest thing to do as it would detect *any*
bad read.