linux-kernel - [PATCH 0/1] udf: Fix null-ptr-deref in udf_write

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-next>] [day] [month] [year] [list]

Date:   Sat,  7 Jan 2023 22:50:15 +0300
From:   Fedor Pchelkin <pchelkin@...ras.ru>
To:     Jan Kara <jack@...e.com>
Cc:     Fedor Pchelkin <pchelkin@...ras.ru>, linux-kernel@...r.kernel.org,
        Alexey Khoroshilov <khoroshilov@...ras.ru>,
        lvc-project@...uxtesting.org
Subject: [PATCH 0/1] udf: Fix null-ptr-deref in udf_write_fi()

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