linux-ext4 - Re: [PATCH 2/3] Fix panic with journal superblock flags printing.

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: <EC847396-EE31-4F96-B8A9-3457FD1AC9F5@gmail.com>
Date:   Thu, 22 Nov 2018 07:24:17 +0300
From:   Alexey Lyashkov <alexey.lyashkov@...il.com>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: [PATCH 2/3] Fix panic with journal superblock flags printing.

1024 is jbd superblock size, and this constant widely used over e2fsprogs code.
from this particular case it’s clear bug as jsb_buffer defined as.
>>
        char                    jsb_buffer[1024];
>>

> 22 нояб. 2018 г., в 2:54, Theodore Y. Ts'o <tytso@....edu> написал(а):
> 
> The summary really isn't right; "panic" is something that kernels do,
> not userspace programs.
> 
>> -	if (dump_super) {
>> +	if (dump_all || dump_super) {
>> 		e2p_list_journal_super(out_file, jsb_buffer,
>> -				       current_fs->blocksize, 0);
>> +				       1024, 0);
> 
> This makes no sense to me.  Why is hard-coding the expected blocksize
> to be 1024 a good thing to do here?
> 
> 					- Ted