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  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]
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

Powered by blists - more mailing lists