linux-kernel - Re: [BUG] jfs: possible uninitialized-variable access in xtSplitUp()

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]

Date:   Tue, 3 Aug 2021 10:46:28 +0800
From:   Li Tuo <islituo@...il.com>
To:     Dave Kleikamp <dave.kleikamp@...cle.com>
Cc:     jfs-discussion@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
        baijiaju1990@...il.com
Subject: Re: [BUG] jfs: possible uninitialized-variable access in xtSplitUp()

Thanks for your feedback, and any feedback about the further check would 
be appreciated!

Best wishes,
Tuo Li

On 2021/8/3 3:04, Dave Kleikamp wrote:
> On 7/31/21 1:31 AM, Li Tuo wrote:
>> Hello,
>>
>> Our static analysis tool finds a possible uninitialized-variable 
>> access in the jfs driver in Linux 5.14.0-rc3:
>>
>> At the beginning of the function xtSplitUp(), the variable rbn is not 
>> initialized.
>> If sp->header.flag & BT_ROOT is true,
>> 780:    rc = (sp->header.flag & BT_ROOT) ? xtSplitRoot(tid, ip, 
>> split, &rmp) : xtSplitPage(tid, ip, split, &rmp, &rbn);
>>
>> the varialbe rbn will remain uninitialized.
>> However, it is accessed through:
>> 814:    rcbn = rbn;
>>
>> I am not quite sure whether this possible uninitialized-variable 
>> access is real and how to fix it if it is real.
>> Any feedback would be appreciated, thanks!
>
> I think the logic that protects us is that in the case where rbn is 
> uninitialized, sp->header.flag & BT_ROOT, which means it SHOULD BE the 
> last entry in btstack, so we shouldn't enter the loop:
>     while ((parent = BT_POP(btstack)) != NULL) {
>
> It does seem that some type of sanity check is warranted. I'll take a 
> closer look and see if I can add some kind of error path if things are 
> out of sync.
>
>>
>> Reported-by: TOTE Robot <oslab@...nghua.edu.cn>
>>
>> Best wishes,
>> Tuo Li