Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Fedor Pchelkin <pchelkin@ispras.ru>
To:     Jan Kara <jack@suse.com>
Cc:     Fedor Pchelkin <pchelkin@ispras.ru>, linux-kernel@vger.kernel.org,
        Alexey Khoroshilov <khoroshilov@ispras.ru>,
        lvc-project@linuxtesting.org
Subject: [PATCH 0/1] udf: Fix null-ptr-deref in udf_write_fi()
Date:   Sat,  7 Jan 2023 22:50:15 +0300
Message-Id: <20230107195016.290627-1-pchelkin@ispras.ru>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hello Jan,

Syzkaller reports the following problems [1].

null-ptr-deref is fixed by the following patch.

About out-of-bounds write: I suppose it is due to the similar issue which
caused null-ptr-deref bug - udf_find_entry() return value is not checked
and we can end up with an incorrect ocfi and ofibh structs. Actually,
padlen in udf_write_fi() becomes less than zero because the values it is
consisted of are invalid, then padlen is passed to memcpy and here is the
bug. Should I also add this to the patch description text (I'm not sure
about it as that is just a consequence of null-ptr-deref bug)?

With the applied patch reproducers on my machine do not trigger
null-ptr-deref and out-of-bounds anymore.

The only thing is that: does udf_rename() need to immediately return with
an error if udf_find_entry() fails here? If ofi is an error pointer
(especially -ENOMEM), udf_rename should return an error. But if ofi is
NULL, the entry has probably already been deleted, and we should just skip
udf_delete_entry() call.

[1] https://syzkaller.appspot.com/bug?id=ddfcda66fe98b595b0fe11d9dd64eb532478f04b

Fedor