linux-kernel - Re: [PATCH] nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free

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

Message-ID: <CAKFNMomd9j3o1iQN6kyUoDcEKGwh34CqAjAWeF5g_s8eSEVX5Q@mail.gmail.com>
Date:   Sat, 19 Nov 2022 10:02:05 +0900
From:   Ryusuke Konishi <konishi.ryusuke@...il.com>
To:     Peng Zhang <zhangpeng362@...wei.com>
Cc:     ye.xingchen@....com.cn, chi.minghao@....com.cn,
        vishal.moola@...il.com, linux-nilfs@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        syzbot+ebe05ee8e98f755f61d0@...kaller.appspotmail.com
Subject: Re: [PATCH] nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry()

On Sat, Nov 19, 2022 at 9:38 AM Ryusuke Konishi wrote:
> On Tue, Nov 15, 2022 at 3:39 AM Ryusuke Konishi  wrote:
> > On Mon, Nov 14, 2022 at 12:39 PM Peng Zhang wrote:
> What was happening here was complicated.
> There were two state inconsistencies in DAT:
> 1) A virtual block number (vblocknr == 6145) in the report, was used
> twice in a btree.
>     Because of this, nilfs_dat_commit_end() on that address was called twice.
> 2) For the virtual block number (vblocknr == 6145), the DAT bitmap
> status was free (second anomaly), and nilfs_dat_commit_alloc() was
> performed at the same time as the second nilfs_dat_commit_end() above.
>
> As I mentioned, when nilfs_dat_commit_end() frees a virtual block
> number in the bitmap of DAT, nilfs_dat_prepare_end() usually allocates
> buffer heads of the bitmap block and the descriptor block, and sets
> them to the request struct.  But, the above two anomalies overlap, as

> you pointed out, de_block is initialized to 0 by
> nilfs_dat_prepare_alloc() in the middle of "prepare" and "commit", and

I wrote it wrong, this should be ".., de_blocknr is initialized to 0
by nilfs_dat_commit_alloc() ..".

Ryusuke Konishi